This actually works for a lot of issues. The people who tend to write code negligently and without much care what gets passed to where don’t survive for long coding Rust, OCaml, Haskell, and the other compile-time typed languages.
Even outside that area, enforcing a simple pre-commit GIT hook – which is a tooling solution, not a programming language one – can do wonders for the productivity of the team.
I relate to the argument that not all social / economic / politic issues can be solved by tech. That’s true. But it’s a bit too extreme a view for my taste because my practice has shown that forcing people to “behave” with good tooling (or a strict programming language) works.
Strange example. I’d definitely leave the store and not return there anytime soon. There are acceptable and unacceptable ways of gathering metrics / analytics.
I’ve been in one such company last year. Rust’s async has been improving literally every week, for months. We ended up having one Kubernetes pod with 4 vCPUs and 8GB RAM with a NVMe SSD storage that peaked at about 150,000 parallel requests.
Rust’s async used to suck but the community is extremely dedicated and things are improving with an impressive speed.
I agree it’s not OTP, of course; nobody has beat that so far. But Rust is getting fairly close, trust me.
I’ve seen this but I’ve seen the other extreme as well. This can’t be generalized.
Agreed. Good devs find ways around the problems in their ecosystem and even make them work to their advantage. Example: we might not have compile-time typing guarantees in Elixir but between mocks and property tests you can gear your system with a very heavy anti-bug armor.
Bad devs will screw up no matter what they work with.
That one I fully agree with. Elixir is extremely productive. You can test your idea with just a few lines in iex and prototype a solution in minutes.
Rust’s iteration cycles are very punishing in terms of an up-front cost and this can be quite annoying.
