Spending my time in the Elixir/Erlang world has shifted my focus onto reliability as a central criteria in selecting tech. I had some such tendencies before, preferring Postgres to the NoSQL hype when that was a thing.
But now I’m thinking about the programming languages I look at for reliability where I feel like the language and ecosystem has priorities that align with mine.
I tend to lump the Elixir/Erlang/BEAM ecosystem in with some other languages. Specifically Rust which seems like the future for native extension in Elixir. And then we have Go which seems to be great for self-contained binaries and very popular for some types of devops infrastructure projects (such as the Rancher stuff, k3s, rio…). I don’t code in Rust or Go currently. But I sense a kind of kinship in aggregate from reading about and using software from those ecosystems.
Do you have another constellation you’d consider belong together? Do you feel like my estimation about these languages and their priorities are mostly right, mostly wrong?
Go is like a modern Python + a shell scripting language and it is quite good at that but do have in mind that complete reliability and type safety aren’t its first priorities. It was designed to be mostly easy to pick up by former C++ and Java engineers (source: unofficial testimonials from people who chatted with the creators long ago, shared on HN). This severely reduces its potential usefulness as a good native bridge from higher-level languages despite continuous heroic efforts like cgo.
This doesn’t detract from its usefulness in general. A lot of excellent programs have already been written in Go. I just get kind of nervous about when will the security researches start finding easy ways to pwn Go programs, but let’s see what the future brings.
As for Rust, I share your assessment – it’s indeed a very good native bridge and not only for Elixir. It has an amazing tool that allows it to parse existing C/C++ header files and generate Rust wrappers for almost any [well-written and following good practices] native C/C++ library. From then on it’s not much work to make a few hand adjustments and boom, you have a Rust wrapper towards insert-existing-well-known-native-library-here.
That makes it an excellent tool to both (1) provide a gradual migration path towards pure Rust should the original C/C++ authors choose to go down that path and (2) still give a Rust developer as close to the original library code as possible in the meantime. And that’s not even mentioning how amazingly good a language Rust is.
As for other such seemingly natural pairs as Elixir and Rust, I am not sure but I am curious myself.
Hmm, your notes on Go are interesting. I think what I’m appreciating from the Go side might not strictly be about reliability. It might be some of the other values that seem to come from the community, performant, portable, high performance and also, from what I hear, quite friendly as a community. Also, the idea of designing a simplistic language which I gather to be part of Go appeals to me.
Go is not really on my radar to learn but there seems to be a lot of software that comes written in Go that I’m happy to use. Simple static binaries, old school but modern if you put them next to C and NodeJS. I’m trying to capture some ineffable qualities here I realize.
I think Go is quite fine for a number of tasks. I just find myself worried that not enough care and future-thought put in it could severely hamper the ecosystem and put a hard ceiling on what it can achieve in the nearby future – as it eventually happened with Java and maybe C++.
In the meantime, Rust has all but solidified an amazing API for basically making asynchronous functions/workers akin to the BEAM’s “processes” (sadly without proper scheduling and rate-limiting like the BEAM does) and is marching ahead to a future where your program can run as series of smaller functions, each in a different deployment cloud container even (not a fan of these things but they are becoming a reality for the better or worse).
Go is pretty good. I just opted to invest mindshare in Rust because it seems more future-proof to me. And it’s completely fair to like the deliberate choice of a simple language (very small amount of keywords).
A lot of very serious work is done with Go every day.
Maybe I should have said was hampered, back in the crazy “Java enterprise” days, because I hear people mostly moved away from that these days.
I distinctly remember being unable to write Java code for two weeks once and only had to fight to get an XML configuration right, and I don’t even remember for which framework now (maybe the early Spring / Hibernate / dependency injection stuff).
In more general terms however, to me Java is still neutered by giving you the escape hatch of skipping types by just passing an Object reference. Java is technically strongly and statically typed compiled language but in reality it very often isn’t. This severely limited its potential in my eyes.
Yeah, I feel fortunate that I didn’t get sucked into the hype for Enterprise Java Beans, although I’m under the impression it’s been greatly overhauled in recent years.
Libraries that return Object references and expect the programmer to correctly type cast them are indeed annoying. I tend to abstract this away behind wrapper functions but I’d much rather not feel compelled to do so in the first place.
Probably all of the above. I recall hearing horror stories in the early days of Maven where developers would spend more time wrestling with pom.xml than writing code.
Many Java libraries now offer the option to configure via @annotations instead of XML, e.g. Spring, but XML is still very common in the Java ecosystem.
Yep, you’ve just met a dinosaur from that age. Nice to meet you!
If there’s something that I really miss from Java in all other languages that I used after it’s exactly the annotations. They are a very powerful mechanism to add behaviour and invariants to code without polluting it with boilerplate. Still like them to this day. Elixir’s module attributes are okay but are IMO not utilized enough for such purposes – and they should be.
Rust’s feature flags (which are extremely close to Java annotations / C conditional compilation directives) are the thing that comes the closest. It’s no wonder I quickly fell in love with the language… although to be fair I wasn’t aware of them at first; they came as a very nice bonus after I already started loving the language for other reasons.
I recall hearing horror stories in the early days of Maven where developers would spend more time wrestling with 