Hacker News Reader

Comment by bluejekyll | Hacker News Reader

Maybe I missed it in the article, but it alludes to this: C is the least common denominator. It's not a great language, but it works everywhere and will work in the most restricted of environments.

As the article states, it's resurgence is bc of restricted small devices, but that's not because it's a great language. Debugging memory issues is horrible, having strange things happen because of randomness between compilers, no fun.

I had a recent desire to get back to baremetal, but I didn't go back to C; I have too many battle scars. I went to Rust, and have never looked back or regretted it. The FFI between Rust and C is pretty easy too for any cases where I need it.

View on HN

It seems that a few years ago several big name tech companies found themselves at the limit of what they could do with the c#/java style languages. But they weren't willing to go back to c/c++. Facebook started experimenting with D, apple created swift, google created go, Mozilla created rust, Microsoft had a rumored system language that never seemed to materialise, and even c++ is trying to get away from itself.

It is sort of looking like the industry as a whole is starting to see if there isn't a better way to do things and I think we will see how things shake out in the next five years or so.

I think this is a nice development :)

When I was doing my CS degree it was Java all the way.

I mean, today you can start a Haskell or OCaml project without people laughing at you.

I find your description to be the best one in the thread. It's also reflecting my exact motivation in dabbling with Golang.

Thank you.

For new projects on hardware that supports the Rust compiler, there are few reasons to choose C over Rust.

That said, take the kind of lifelong momentum that PHP has, and multiply it by a few orders of magnitude, and you have C. It will be a very long time before C is replaced by anything.

Yes. But if people choose to , like me, go to a safer language that reduces congnitive load around bugs etc, it's easy enough to use the FFI of Rust to utilize any existing C libraries out there.

I'm sure I'll still be able to compile my c programs, without change, in 10 years.

Is rust willing to make that commitment? Or even 5 years? 2?

We have very strong backwards compatibility guarantees. We do reserve the right to make soundness fixes, but they must be trivial to fix in user code. Otherwise, we don't break backwards compatibility. We have had one or two of those in the first year and a half of post-1.0 Rust, but virtually all code that did not hit one of those issues still compiles today. Newer iterations of the C standard have also introduced small backwards incompatibilities, it's just how the world works.

Our intention is to have that kind of long-term stability, yes, and we put a lot of work into making sure that it happens.

I'm glad to hear that -- I've had bad experiences with some other languages moving too fast and breaking things. I understand that's great for people developing every day, but I have several systems I dip in and out of.

Now I know rust has entered a stable phase, I might give it a look!

Trust me; we hear you. pre rust 1.0 was not pleasant, and it was even my job to keep up with the changes.

For more on how this works:

https://blog.rust-lang.org/2014/10/30/Stability.html

https://github.com/rust-lang/rfcs/blob/master/text/1122-lang...

https://github.com/rust-lang/rfcs/blob/master/text/1105-api-...

These are the RFCs and policies we came up with when cutting 1.0. I haven't read them in a while, but there haven't been any changes. Some of the text and/or examples might be reflective of the time they're written.

Oh, and one more thing: we have a tool, "crater", that we run every so often against every open source package in the ecosystem to make sure things don't break. Some of the most popular packages are built on every commit, as well.

The other big advantage of C is that multiple compilers for it exist that are good enough to use in real life, for a wide variety of toolchains, and it's simple enough that it's possible to write a compiler for it (if not necessarily a very good one) as a hobby project. We can be reasonably sure that C will continue to exist.

By comparison, C++ has precisely two working open source compilers --- clang and gcc --- and Rust has one: if you commit to using Rust, you're also committing yourself to an LLVM-based monoculture. The chances of the entire Rust team being simultaneously hit by a bus is low... but it's something that needs to be factored into a product assessment.

That argument seems akin to avoiding C# because only MS supports it, or avoiding Python because CPython is the only serious implementation.

The language with the most sensible implementations seems to be javascript, I guess.

It can be rational to develop projects on new languages. It can also be rational to consider the risk posed by the ecosystem you are plugging into. For example, it would be rational to consider the risk to a new project of basing itself on a language that is only supported by one corporation. (Imagine if Oracle had become a single point of failure for Java.)

That said, Microsoft has very deep pockets, shows every indication of continuing to promote and use .NET extensively, and has also built up a lot of commercial buy-in over the 15 years or so that .NET has existed, which could carry it forward a while or fuel alternate implementations if something catastrophic happened.

PyPy is a serious implementation of Python. There are others and have been others over the years. While the corporate buy-in isn't the same as .NET or Java, there is a large amount of open source funding and buy-in from very diverse sources. Python is older than .NET as well.

Maybe the risk of using Rust is acceptable even if a bit larger, or the added risk is offset by Rust's good qualities - nonetheless, it's a very new language with no Microsoft-scale company behind it. Not precisely comparable.

It doesn't matter if Rust is perceived as having less ecosystem risk than Python or .NET, if in (say) 10 years it doesn't make significant headway against C, which is what it actually has to compete with. Here we could consider the examples of Pascal and Lisp - they competed with C, were arguably much better languages, and they lost anyway.

It's something worth considering if your dreams are founded on Rust.

>That argument seems akin to avoiding C# because only MS supports it

Or avoiding Flash because only Adobe supports it, or SilverLight/VB because only MS supports it, or Objective C because only Apple supports it.

Many popular languages nowadays essentially have just one viable open source toolchain: Go has the Go toolchain (gccgo being niche), Python 3 has CPython (Jython and IronPython only support Python 2.7, and PyPy is not up-to-date), Swift has the apple toolchain, Haskell has GHC (none of the other compilers is widely used).

That's not necessarily a bad thing since the compilers are all open source and you can port them to whatever platform you want anyway. C managed to spawn a lot of adequate compilers, but the language itself has seen very few changes since it was standardized (27 years ago), while all the other contenders (including C++!) see a major release at least every 2-3 years, and up to several times a year (for Rust).

You can't have that pace of changes and still maintain compatibility between all the different implementations.

>Many popular languages nowadays essentially have just one viable open source toolchain: Go has the Go toolchain (gccgo being niche), Python 3 has CPython (Jython and IronPython only support Python 2.7, and PyPy is not up-to-date), Swift has the apple toolchain, Haskell has GHC (none of the other compilers is widely used).

The problem is that having multiple providers prevents the BDFL from playing too hard with the language.

If there was an alternate Python toolchain, Python3 wouldn't have happened.

> Rust has one: if you commit to using Rust, you're also committing yourself to an LLVM-based monoculture

rust currently has only one backend, which is LLVM, but their is a working project to build an alternative one for the Cretonne compiler[1] for the «debug» builds, and there might also be a GCC backend for rustc one day if people are interested enough to build it. I'm not aware of any fundamental difficulties that would prevent it.

[1]: https://internals.rust-lang.org/t/possible-alternative-compi...

(The reason cretonne is debug only is that it's raison d'être is for WASM, so it won't be doing (many) optimizations. It will help with rapid prototyping however, and perhaps let you do things like a rust interpreter)

The question is not so much how many working compilers are there, but how many rely on the language.

Practically, PHP has one interpreter, but if they go out, you can be assured that someone will fork and maintain it.

On the other hand, if MyToyLangOnGitHubGraduateProject goes belly up, you're stuck maintaining it yourself.

If you never adopt new technology there is no progress. C++ dissed, but offered enough ergonomics that it gained adoption. Java succeeded in giving people a platform on which they could distribute software while relying on a consistent runtime. Rust is new compared to these, but again offers significant ergonomics over C and C++, seems to be delivering on platform independence pretty well (better than C/C++ imo); it really is the best of both worlds.

What's also amazing, is that Rust is growing through sheer love of the language. There is no one pushing it, but for the joy of hacking. It is lik C in that way.

> As the article states, it's resurgence is bc of restricted small devices, but that's not because it's a great language.

To be fair, it's an amazing language, but if you're coding to get things done with a deadline (or with an unknown set of specs), of course you should go for the nailgun instead of making custom hammers.

Syntactically I agree with you. I love the C style, I pretty much only use C derived languages for a reason. I think it was great for it's time...

I'd suggest that it's still "its time", but not for daily use for most people.

Hardware is cheap and fast and there are safer languages (I hear Rust is good; I'd use Java if I wasn't carpal-tunnel concerned), and often a VHHL is more than sufficient for time/speed trade-off s or even obligatory (e.g. Python, client-JS respectively).

But that said, C is _great_ as a teaching/learning language -- not much magic, small --, as a "I have very specific/strict goals" tool, and as a very well-tested underpinning for making languages that are safer/magical (e.g. CPython).

Would I pay 60 people to write C for a .com/.io startup where 10 people writing NodeJS could get something out the door faster? No, but I'd love it if a couple of those 10 had a solid C background so when _shit gets weird_ or a framework's magic starts barfing on systemd's magic, the engineering team doesn't decide it's time to switch to golang.

Back in the mid 80s, the CS program at my Uni switched from Pascal to C as the standard course language. C always felt like a crippled death trap in comparison, even if real work would have had to have been done in Modula, rather than actual Pascal. C has a nice data literal mechanism, and return/break, but all the things you gave up: array bounds checking; references that couldn't be null; subrange types; non-int enums; arbitrary array indices; sets; nested subroutines.

How many people even realize that C++ (formerly "C, with classes") is largely just a rehash of the Simula preprocessor (for Algol) from the 60s?

That said, I think the Unix creators meant for C to be an assembly alternative bootstrap language, not the primary development tool for almost all applications.

In a sense, the rise of microcomputers was a disaster for programming language development, or at least a mixed bag in the short run.

Having worked in both, Pascal (at least in the 1980s) felt like trying to work inside a straightjacket.

Perhaps the worst example: The size of an array was part of the type of the array. This means that you couldn't access outside of the array. That was good. It also meant that you couldn't have a variable-sized array, because there was no possible type for it to have! That was really problematic at one particular point when we needed to deal with a variable-sized 2D array. We wound up having to create the maximum size we had memory for, and only use the subset that we needed, which to this day I consider a kludge to deal with a language limitation.

For more, Google for "Why Pascal Is Not My Favorite Programming Language". Despite being written by Kernighan, it's not a Pascal-vs-C evaluation - it's more Pascal-vs-Ratfor, with Pascal coming off rather badly for real-world use.

For university teaching, though, Pascal was probably better...

The fixed size array limitation of the 1970 CDC Cyber teaching version usually gets an extension in the (Modula or Modula inspired) versions that people actually use. E.g. -

http://www.freepascal.org/docs-html/ref/refsu69.html

https://www.modula2.org/sb/m2_extensions.htm

Yes, I've read "... Not My Favorite ..." (and "Worse is Better", and "Unix ... C ... Hoax")

Yes, I know there was an extension. Unfortunately, the one I had to use didn't have it, so I was trapped.

I have also been looking to get back into bare metal programming professionally (I miss the torture). Did you see an immediate switch to rust or is this a rare unicorn project in a sea of C/ASM code for embedded devices?

I've been writing my own ground up stuff. Nothing really on the hardware side for me to publish, but I have been writing a few articles on my DNS project which I have some plans for in the small device realm at some point (not free of allocations yet though).

There are many articles by others out there for getting going with Rust on baremetal, and with Rustup it's now easy to cross compile from your Dev computer to the tartget device.

fosho. Will look into those, but I guess my question is if it's worth practicing some development for embedded devices in rust to switch jobs or if most are still using C and I shouldn't waste the time.

EDIT: if anyone can answer this that would be so awesome :)!

Compared to C, the number of employers looking for rust developers is so close to 0 that it's essentially a rounding error.

I really like rust, and I think it's worth learning, but it is definitely in the early adopter stage and not something that has really made a dent in the embedded industry, let alone taken over.

Yeah, if you're looking for employment opportunities today, or in the next couple of years, learn C.

That said, if you want to be a better C programmer (and you already know C): learn and write Rust, and figure out what sorts of things you can't write in Rust and why. Once you learn how to make the Rust compiler's safety checks pass without it yelling at you all the time, you'll know how to write good code in a similar language without the safety checks.

I'll second my sibling comment in saying that C (and C++!) will be around for a long time, and is epically easier to get hired with if you're trying to break into the industry. The C ecosystem just has too many advantages at this point (i.e. not just existing code but also number of supported platforms, etc.).

Also, a significant fraction of embedded code is going to be "unsafe" Rust by definition: drivers performing volatile load/stores on memory mapped hardware. In those scenarios, defect mitigation techniques are a matter of system architecture (MPUs, pre-empting deadline-based task schedulers) rather than being language-specific. Arguably even Rust provides you with no protection against the most devious bugs (memory barrier usage, cache-DMA interactions).

The machine is ultimately unsafe. Rust's strength is to be able to encapsulate that unsafety to be a small part of your code, and have most of your code be safe. This is even true in an embedded or osdev context, though the percentage is higher than in an application context.

I am new to programing (well new in the sense that I have been doing it sparsely for years) and only have written code for microcontrollers, is rust a good replacement for C in that domain?

I don't know much about other languages, but it seems C is pretty well tailored for doing all bit-level stuff. Is rust the same way?

"All" modern compiled languages will have bit-manipulation. As long as a language can compile for your microcontroller, you're golden to use something higher level.

Reply on news.ycombinator.com