Scale By The Bay 2018: Bryan Cantrill, Rust and Other Interesting Things

As a huge fan of Julia i got to fully agree. Although i would probably not "no longer recommend Julia" but "give huge caveats when mentioning Julia". Organisations (that includes those who maintain programming language) have values Bryan Cantrill has an excellent talk on this [this video] and i got to agree with the author that correctness (especially correctness under arbitary composability) is not a value that Julia teaches and instills in its users. Some Julia users care about this, some core maintainers do to (as the Pkg3 demonstrates). However there are many invocations (SafeTestSets vs Test) and stumbling blocks. I am aware of no efforts to do formal verification on Julia code. There are no good ways to move certain Run-Time to compile errors. Correctness is not a value of the Julia language. Here is the good thing though, as Bryan demonstrates in his talk, you can hire for values.

Bryan Cantrill explains a very interesting thought about that here: [this video] I'm sure there are many other factors that play into this (just look at Gary Bernhardt's "WAT" talk), but essentially, I agree that this has to be a big part of the problem. If you've been developing backend systems and asked to hold up robustness and stability guarantees for multiple years and then run into Javascript, you will likely run into situations where you have to make up for its deficiencies in that regard. That doesn't make it a bad language per se -- that's the case with any language in some aspects -- but since JS will be a new language to you, you're much less likely to accept that situation as a given.

There is sparsely little real “engineering” that goes on in the field of “software engineering”, industry wide, in terms of ensuring that our software is reliable and secure. Performance and development velocity seem to take the driver seat always, in a whole lot of software. See also this talk by Bryan Cantrill, “Scale by the Bay 2018: Rust and Other Interesting Things” [this video] where he talks about software platform values, in the sense of what different programming languages and other things focus on. He also touches on the fact that while higher level layers in the stack might value security it kind of falls apart when the very microcode in our CPUs sacrifices security for performance. This was in a period of time where Spectre [link] and Meltdown [link] had reared their ugly heads.

I can't help but feel like if you want static typing, you're better off recognizing that python is not the right tool for the job. Admittedly I've never done serious work with mypy (or typescript), so I'm approaching the value proposition of dynamic typing at face value rather than experience. However, it seems like the primary benefit of these languages was ease and flexibility, ableit at the cost of structure. Or said differently, adding mypy feels like trying to get out of a trade-off decision. This situation reminds me of a talk Bryan Cantrill gave on platform core values, and as examples he gave his interpretation of the platform core values of languages like C, Awk, and Scala: [this video] For me, platform core values that stick out for python would be Approachability, Simplicity, and Velocity. I understand the posited value mypy brings to the table, but it feels in contention with the original core values that made python appealing to begin with.

The struggle here is that in software, sometimes hedgehog thinking is correct. The discernment challenge isn't in spotting hedgehog thinking and choosing fox thinking instead. The challenge is in figuring out in what domains hedgehogs are right and in which domains foxes are right. Unlike in the arena of politics, in software hedgehogs reap the benefits of deep expertise. When are hedgehogs right? In the "obvious" stuff: - You should always use correct indentation in your code - Document your architecture decisions. Have conversations in your team to get feedback and buy in. - When practical, try and keep down the number of languages and databases you use. It'll make onboarding easier and it allow the team to build deeper expertise And so on. The "relational database advocate" usually isn't making an argument that relational databases are better all the time. They're making an argument that relational databases are the right default, and this particular use case isn't weird enough to justify the cost of learning and deploying something else. They might be right - its extremely difficult to know without taking into account the task at hand and the skills of the team. My personal take is to think about the values of a piece of software before writing it. How much should your project care about maintainability, or scalability, or accessibility (ie onboarding)? Then make your technology choices with that in mind. If actually, short term team velocity is the most important thing,