Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go?
Note that Go does not entirely compete in the same space, and Rust is only starting to gain traction.
Note that Go does not entirely compete in the same space, and Rust is only starting to gain traction.
I've seen people consider "systems" programming as relating to building web services. Traditionally systems programming would be more kernel level and utilities/daemons.
Rust might be OK to start using for the latter, but its very much not yet where I'd start using it for new things for either of the traditional setup.
I know everyone is gung-ho about rust, but for the traditional systems programming crowd, its very new. Given how much it changes I would NOT want to bet on using it for at least 5 years. You don't switch just because something is better on memory safety. That is a nice to have thing. But changing 40ish years of things isn't something that you do without planning.
Also, in my opinion Rust doesn't go far enough. I'd rather we move to things like Idris where I can prove much more than just memory safety. Rust is basically Ada/Oberon/Modula for the modern age. Nice, but ultimately not the first time this has happened.
Idris is closer to ocaml in that regard.
I cough may have already tried using idris in a kernel module. (for fun, not for serious)
From there I'll let you know, I'm still learning Idris and dependent types so I'm a fairly boring test case. This was more of a: lets try it and see what goes kaboom test.
This is not to say I doubt the ultimate approach of Idris: with dependent types you can do everything Rust is doing, and more. It's just a matter of project focus and ergonomics.
Not to misrepresent the work the Rust guys are doing, it is great what they are doing and I have lots of fun dabbling on it.
But new system programming programming languages tend to be adopted when an OS vendor tells devs, either use it or go code elsewhere.
On OSes that have significant market share, devs tend to learn the new language instead of waving it away.
Rust may be changing, but it's almost entirely _additions_. We've been stable for roughly 18 months now.
Don't take any of my criticism too harshly either, I do like and use Rust for side projects. But it is about 3 years away from where I'd consider using it for anything. I'm a bit more conservative than most here seem to be. Funny part is I'm the maverick in using new stuff compared to the people I work with.
Keep on trying to improve things either way!
Obviously, if one defines "systems programming" more strictly than that, and only mean code that directly interacts with hardware or has hard realtime requirements (which also probably means it must interact directly with hardware), then Go does not make sense in that category. But, C has given up a lot of territory over the past several decades. When I first started programming, C was the language you used for writing almost any real application...if you weren't using assembly. That has changed a lot in the intervening years, and almost no one would think to use C for GUI apps today, for example.
Go seems to be, IMO, taking the things Java is best at and trying to make something better. Basically, how would you build Java today if you could do it again?
Take Modula-3 (1986), change the keywords to lowercase and re-brand it as "Cool Language X".
Still better Go than C.
Your comment seems to imply that java hasn't been successful for db development. HBase, Cassandra and ElasticSearch would all disagree.
Yes, there are situations where GC is not appropriate. But I think those situations aren't as common as they are made out to be.
HBase and ElasticSearch, and even Cassandra can be seen as somewhat niche today. This doesn't mean they aren't doing something of value; and it doesn't mean using the same platform for OLTP and OLAP is the way of the future; but it does mean the competition in their space is more limited and less indicative. There are ground-up rewrites of Cassandra in non-GC'd languages out there, for what it's worth.
http://people.inf.ethz.ch/wirth/ProjectOberon/index.html
http://www.astrobe.com/default.htm
http://wiki.osdev.org/Go_Bare_Bones
It just needs someone to port that Oberon code to Go, maybe people will then stop discussing how suitable Go is for systems programming.
Therefore Go is closer to that space than people want to admit. A change of its runtime or compiler would let it do operating systems. Even Java (JX) and Haskell (House) do operating systems. I'm sure one could that is derived from and similar to a language designed for implementing OS's. :)