1. 1

      To be clear, I think @sridatta’s comment above nails the issue here.

    1. 2

      “A BMW comes with a curated set of features, like German engineering and leather seats”

      The author is using quite a curious definition of ‘curation’ here.

      1. 1

        Well said. It seems that perhaps “german engineering” shouldn’t be seen as a curated feature, but from the brand’s point-of-view, I believe “german engineering” is touted as one of the reasons a BMW is great. Not too different from “apple has the best industrial design”.

      1. 1

        One of the authors here. Very interested in feedback if anyone has any.

        We are inspired primarily by phrack and the economist

        1. 4

          This piece was very well balanced, to the point that I don’t know what its overall intention is. I suppose one interpretable aim could be seen as a balanced framing of technologies for those interested in upping their basic vocabulary. After reading this first issue, my impression is that Snowsuit is a largely unrefined ore of a potentially valuable material.

          I demand more depth, and exploration into chaos. Sometimes there are no good answers. Please bring this balanced approach to discussing actual problems.

          I think two root problems are that we suck at specification, and that we suck at risk assessment. The engineering consequences for these two things are innumerable. The technologies that are covered in this issue are valuable precisely because they reduce the effects of our poor ability to specify. Swift and Go are valuable because they provide underspecification mitigation to the masses, through languages that map the domain onto our mental capabilities slightly better than what came before. RPC’s are dangerous when underspecified. Raft isn’t completely broken because the discussion around RPC’s is framed around a specification that an RPC occurs in an asynchronous system which may arbitrarily drop and delay messages. RPC is quite painful when the environment is not properly specified and encoded into the tools.

          The other thing, risk analysis, is equally important, and has deep implications into what it is that we prioritize the construction of, or not. We are all using systems that governments and organized crime have already bought the keys for. How is this possible? An under-appreciation of risk, the inherent bugginess of C, and a failure to adequately specify what should not be possible. This is not a problem that Go or Swift will solve, but it is something that projects like Rust and Mirage are making headway with.

          So, I suggest that you continue to refine your ore and give it a point or two. The balance you bring is valuable, and needs to be applied to discussions of real problems that we face as a world of people that uses computers.

          1. 2

            Thank you for the feedback. The next few months should hopefully see some clear refinements as we get our voice.

          2. 3

            Very interested. Spent some time looking for some kind of subscription mechanism… ended up just adding it to my top sites…

            Over the past 8 years the majority of my professional development has been ObjC and Go, so this particular issue hits home. My personal description of Go is that it is second best at everything… which means it ends up being the most productive language I’ve ever used. The ease of refactoring is one of the languages greatest strengths. Also, I wish every language had a standard fmt tool. I really miss that when I have to go back to any other environment.

            1. 3

              A way to subscribe would be great! Hopefully RSS / Atom, but a newsletter signup is fine too.

              1. 1

                We should have these kinds of things ready by issue 2!