Selecting a programming language

Software
1

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!

1 Like
2

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.

3

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.

4

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:

5

So I read this excellent article:

https://kevinlynagh.com/rust-zig/

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.

6

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.

7

Excellent article on Go:

https://drewdevault.com/2021/04/02/Go-is-a-great-language.html#fn:1

This stands out:

Go is also notable for essentially inventing its own niche, and then helping that niche grow around it into an entirely new class of software design. I consider Go not to be a systems programming language — a title much better earned by languages like C and Rust. Rather, Go is the best-in-class for a new breed of software: an Internet programming language.
…
It took me a while to understand this. It was a mistake for Go to be marketed as a systems language. Any systems programmer would rightfully tell you that a language with a garbage collector and magic cooperative/pre-emptive threads is a non-starter for systems programming. But, what Go was really designed for, and is mainly used for, is not exactly systems programming. Internet-facing code has straddled the line between systems programming and high-level programming for a while: high-performance systems software would often be written in, say, C — which is definitely a systems programming language — but the vastness of the Internet’s problem space also affords for a large number of programs for which a higher-level programming languages are a better fit, such as Java, C#, etc — and these are definitely not systems programming languages. Go is probably the first language to specifically target this space in-between with this degree of success, and it kind of makes a new domain for itself in so doing: it is the first widely successful “Internet programming language”.

An “Internet programming language” – that is an excellent description, and why Go is an excellent choice for implementing IoT systems – both in the cloud and at the edge.

8

haven’t I been saying this forever :slight_smile:

9

Elixir is an interesting language – I’ve never used it but get the impression it is designed for implementing distributed systems. This article provides a nice comparison to Go:

Go is compiled to a native binary, while Elixir is compiled to bytecode and executed on the Erlang Virtual Machine (BEAM). As such, Go produces applications that run much faster than Elixir. As a rule, Go applications will run comparative to Java applications, but with a tiny memory footprint. Elixir, on the other hand, will typically run faster than platforms such as Ruby and Python, but cannot compete with the sheer speed of Go.

Performance is just one consideration – others include fault tolerance:

Erlang, the platform underlying Elixir, makes numerous sacrifices in runtime speed in order to provide memory safety, native distributed messaging (clustering), and fault tolerant process management.

This further illustrates there are always tradeoffs. You have to decide what is most important for your application. As we deploy SIOT to low end Embedded Linux edge devices, performance, runtime efficiency, memory use, binary size, etc are all very important for IoT systems.

10

Seems Elixir is good at somethings

1 Like
11

First I looked at the Redis protocol – pretty neat!

12

Good article on various garbage collection techniques:

13

Another nicely balanced Go vs Rust article:

14

I can write Rust as quickly as I can write Python, and other people can too. Time-to-market matters, and the gap between Rust and scripting languages is closing fast. Soon your solution won’t be faster to market, and will be more expensive to maintain to boot. And someone’s going to eat your lunch while you complain.

15

this is a good article, although I think writing rust as quick as python might be a bit of not true but I am impressed that rust can have fast edit-compile-debug cycle.

16

A quote from the article:

Go’s simplicity, performance, and developer productivity make Go an ideal language for creating user-facing applications and services. The fast iteration allows teams to quickly pivot to meet the changing needs of users, giving teams a way to focus their energies on flexibility.

Rust’s finer control allows for more precision, making Rust an ideal language for low-level operations that are less likely to change and that would benefit from the marginally improved performance over Go, especially if deployed at very large scales.

Rust’s strengths are at the most advantageous closest to the metal. Go’s strengths are at their most advantageous closer to the user. This isn’t to say that either can’t work in the other’s space, but it would have increased friction to doing so. As your requirements shift from flexibility to efficiency it makes a stronger case to rewrite libraries in Rust.

Based on this analysis, it seems Go is still an excellent choice for Simple IoT – performance is not a huge concern, but flexibility certainly is.

1 Like
17

Yes I have been saying same thing both address different aspects of system

18
19

https://kerkour.com/rust-is-minimalist

When I take a few steps back and start thinking about the bigger picture, I realize that, today, Rust is the first language that can reliably do everything well.

Rust vs Status Quo

20

A description of transitioning from Python to Go: