Selecting a programming language

A nice balanced article:

I’ve not delved into Rust yet, but continue to be very pleased using Go in Embedded Linux edge systems and in the cloud – it brings a reliability and productivity I’ve never experienced before. Could Rust do better – perhaps for some applications. If Rust binaries were significantly smaller than Go binaries, that could be a significant advantage when deploying updates over Cat-M cellular networks. However, there is likely a cost (language complexity, build times, difficulty cross compiling, etc). Some of the biggest challenges I’ve experienced on projects include:

  • getting the project done and shipped
  • scaling the project to multiple developers
  • getting the entire team on the same page and all pulling in the same direction
  • building a host of dependencies when we need to upgrade to a new version of OE
  • pulling in a dependency (like Gnuradio) that has a host of brittle dependencies that are very difficult to cross compile for an Embedded Linux system.

Thus, the simplicity of Go has provided a ton of value thus far.

Like any good craftsman, keep your toolbox full and use the right tool for the job!

Another good article:

Although I was able to beat the Go port eventually, I realized that unless you want total control of how your program runs, and you need to squeeze out every bit of performance you get, writing an application in Go will get you pretty far. Go tries to mitigate the null (nil) issue with zero values, and offers a simplistic syntax such that anyone with decent experience can read code and understand what the code is doing. Combine that with a fairly mature ecosystem of libraries that’s stabilized after the migration to modules, and Go will be the de facto choice for business applications that don’t have complex logic or rules and mostly just deal with data fetching and mangling. I would choose Rust for business applications that require absolute safety, performance, communication with C ABI (Go is not great for this), or where I would be forced to originally write C/C++. (This, of course, won’t stop me from trying to use Rust wherever I want for hobby projects :grinning:)

Rust continues to be on my radar, but this reinforces that Go is still a pragmatic choice for IoT, (cloud and embedded Linux) applications.

I think its not either or scenario, they both are fixing different parts of software ecosystem but bringing modern programming paradigms, e.g. managed modules, safety etc. So we should not pitch them against each other but rather see the wholesome picture and find their place and see where they are modernizing the ecosystem.

Agreed, the art of modern engineering is knowing what technology to use when and where. Thus, I have renamed this thread to: “When to use Rust or Go.” I might eventually change the topic to “selecting a programming language …” :slight_smile:

So I read this excellent article:

and decided to rename this thread from “Selecting Go or Rust” to “Selecting a programming language”. The point of all these discussions is not that one programming language is right and another is wrong, but rather that there are tradeoffs. The absolute safety of Rust is a benefit, but comes with the cost of complexity. A few quotes:

Using Zig for just a few hours has highlighted to me aspects of Rust that I’d never before considered. In particular, that much of the complexity I’d unconsciously attributed to the domain — “this is what systems programming is like” — was in fact a consequence of deliberate Rust design decisions.

For example, it’s now quite clear to me that Rust is a language which has a dedicated feature for everything. In addition to its famous borrow checker, Rust has modules, packages, generics, traits, two kinds of macros, attribute annotations, and a dozen other things.

A more complex language requires the compiler to do more work:

With Rust 1.50, a from-scratch debug build of my keyboard firmware takes 70 seconds (release, 90 seconds) and the target/ directory consumes 450MB of disk.

Zig 0.7.1, on the other hand, compiles my firmware from-scratch in release mode in about 5 seconds and its zig-cache/ consumes 1.4MB. Nice!

Lastly, some thoughts on small language simplicity:

“Small” is similarly easy; again, there’s basically one page of documentation. This value proposition is right at the top of the Zig Website:

Focus on debugging your application rather than debugging your programming language knowledge.

When I first started using Zig, I was dismayed that it was missing so many features that I liked from other languages. No syntax for ranges. No closures. No iterator syntax.

However, I ended up finding these absences liberating — this is where the “fun” comes in.

After two minutes of searching, I’d conclude “well, guess I’ll just have to suck it up and write a while loop” and then I’d get back to working on my problem.

I found myself more often in a state of creative flow, devising plans based on the limited capabilities of Zig and then executing them. This flow wasn’t constantly broken by stops for documentation or side-quests to investigate some feature/syntax/library.

This isn’t so much an observation of Zig alone as it is about my knowledge of Zig.

The language is so small and consistent that after a few hours of study I was able to load enough of it into my head to just do my work.

I have experienced the same feeling with Go and Elm – the languages are small with carefully chosen features. However, with advances in language design, even simple languages (like Go and Elm) can still be very reliable.

There is no perfect language – you must consider the strengths, weaknesses, and tradeoffs.

This year, Mozilla transferred stewardship of Rust to the Rust Foundation, a coalition founded by Amazon Web Services, Facebook, Google, Huawei, Microsoft, and Mozilla. It’s a sign that the industry’s biggest players are serious about the future of Rust.

Facebook, for example, now has more than 100 developers working with Rust, including some contributors to the core Rust programming language. Facebook isn’t abandoning other languages, but Rust is used for projects throughout the company, including the Diem blockchain, the Move programming language, and the next version of their Buck tool.

As with many other technology movements in the past, what succeeds and what does not comes partly down to industry momentum. Many of us probably have some Rust in our future …

When you are operating at the scale of the above companies, then language safety, speed, and stability matter a lot, and resources are not a constraint.