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.

Ah, gotcha; thanks for elaborating!

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.