3 ms·
C and C++ are the most popular "systems programming languages", C is king in embedded, kernels, C++ is a king in everything else. Go is not strictly "systems pr
by lossolo 10y ago
C and C++ are the most popular "systems programming languages", C is king in embedded, kernels, C++ is a king in everything else. Go is not strictly "systems programming language", as to Rust popularity this is the most pragmatic answer I've seen lately:
"... Let's see Rust for what it is: the latest attempt at a C++ replacement. These have come and gone over the years, and it's by no means clear that Rust will succeed. As an example, Rust is currently 43rd of the 50 languages monitored in the Tiobe index. For comparison with languages of a similar vintage, Swift and Go are 10th and 17th respectively. C++ is 3rd. To put it bluntly: almost nobody is using Rust in the real world yet.
So please, ease up on the hype, Rust users. Have a little humility. You've got a nice little language with some really good ideas, and having a static analyser built into your compiler is cool. But there's a long way to go yet."[1]
[1] https://www.reddit.com/r/cpp/comments/611811/have_you_used_rust_do_you_prefer_it_over_modern_c/dfb924w/ https://www.reddit.com/r/cpp/comments/611811/have_you_used_r...
- abiox 10y agoi recall there being some whining over go and "systems programming", but this seemed to hinge on definitions. go may not be the right option for a kernel but it's great for servers, infrastructure, platforms and various related things.
- tmccrmck 10y agoSystems programming is a vague term but it usually refers to low latency software (e.g. kernels, browsers, OS's, embedded, databases, etc) which means anything with a garbage collector is out of the question.
- abiox 10y agothat's just the thing: "anything with a garbage collector is out of the question" seems limited to a particular camp.
- teamhappy 10y agoSystems programming is all about control. That usually means being able to control which instructions are emitted by the compiler and being able to control how things are laid out in memory, but it also means being able to control what happens when; and Go doesn't let you do that. If you can't guarantee that the function that's supposed to turn the reactor of when the temperature is too high finishes in time then that's a deal breaker. I think some people define systems programming as "interacting with the OS all the time"; which is something that Go is really good at.
- whyever 10y agoTiobe as your main argument is not very convincing.
- lossolo 10y agoThen look at stackoverflow survey from 2017: C++ = 22.3% C = 19% Swift = 6.5% Go = 4.3% Rust is not even on the list which means it's usage is less than 1.8%.
- kem 10y agoI have nothing against C++, Rust, or Go--I like all of them for different reasons and see them serving different goals, and see room for all sorts of languages. I also agree that there's a discrepancy between how Rust is discussed and how it is used, and don't see C++ going anywhere for a long time. However, I think that post from Reddit was a bit misleading in its own way. Go has been much more mature from the beginning, given its authors and origins, and in some ways had an easier target, in being a slower but simpler, safer version of C, or a faster version of Python (as far as new users of the language are concerned). It's also in many ways sort of a modern version of C, so very familiar to potential users. Finally, it had its 1.0 release in 2012. Rust, in contrast, had less of a head start. It is newer in a lot of ways in terms of its characteristics and features, and had a more difficult target, at the lower level and with the performance characteristics of C++. Finally, its 1.0 release wasn't until [less than] 2 years ago, in 2015. Go has been post-1.0 for over twice as long as Rust, which is a significant length of time in IT.