Comment by jcranmer | Hacker News Reader

Comment by jcranmer | Hacker News Reader

Parent Full thread

> C won the competition because it just gives programmers the bare minimum functionality to put an operating system and a compiler in place!

Not really. C won because it was the standard compiler for Unix, and was a free compiler for a free operating system in a time when both were highly unusual.

But in the past few decades, C has lost a lot of its market share to other programming languages. In the realm of desktop (and mobile) applications, C is basically unused for new projects--its standard library is truly anemic here, and major support libraries (e.g., GUI toolkits) are often in C++ and not C. Where C is still the dominant language is the land of embedded applications, and it's not had a lot of competition here since most languages don't bother trying to define a freestanding implementation.

Rust is really the first language to try to contend this space. And there are signs that it may supplant C: Intel is apparently looking to move its firmware to Rust; Linux is allowing Rust for device drivers and kernel modules. Hell, even some OS programming courses (e.g., Stanford, Georgia Tech) have moved their curriculum to use Rust instead of C.

Rust doesn't compete with C, rust competes with C++. Rust doesn't get why C programmers still use C at all.

As a C (not C++) programmer, I understand where you're coming from — Rust is a big complicated language, like C++, in comparison to C — but personally, I really want to use Rust in some applications where I would otherwise use C. I don't think it can be said universally that Rust has no value to C practitioners or that Rust's designers don't understand why people use C.

For sure. I do see the strengths of rust as well. And would most likely use it if i had to write software that absolutely has to be memory safe. It wont prevent other kind of issues however.

This comment irks me in a strange way. I've found very little software where what you care about doesn't build upon the fact that you trust your program's memory safety. You can use C or any other language, but if your tools can't free you from that worry, memory safety should be something that your programs "absolutely" have.

Not every program is connected to internet nor does they run elevated priviledges, or they run anything where people lives would be at stake.

In addition operating systems gives you bunch of safety measures if you design around them. (Obvious being separate processes)

One has to also remember that even if your program would be memory safe it still does not guarantee its flawless nor secure. One very good recent personal experience I can give you is certain popular swift SQL library. It was written in swift which also boasts the "memory safe by default". However, that library due to its design was subject to the very basic SQL injection attacks. Needless to say I ended up writing my own SQL bindings. I hope that library is now fixed or something replaced it, as since at the time I had to write swift (and no I didn't like it), it was the only and most popular (scary) option on github.

I could also write long rant about threads and how the implementations and the threading primitives often have subtle bugs or are broken in different ways. And how using threads in general makes your application basically undefined unless you only absolutely know every piece of code that runs on that thread.

I wasn't talking about security, but correctness, although statistically people underestimate the level of security required by their projects, more than not. Memory safety does not imply correctness, but if you want to reason about correctness you really have to trust that your program doesn't do something funky with your bits. And, at least my programs, like to prove me wrong about what I believe is possible.

If you want correctness, you need proofs, or generate the code from specification. And even then cosmic rays and bit-banging and faulty hardware can break your application. Or simple change of stack size :)

It does indeed compete with C in a lot of places. Device drivers and embedded are a couple of places where Rust will replace a lot of C.

It may replace some software, but it won't really lure many of the C / embedded developers. The problem is that rust developers miss the point of C. People who program with C want the bare minimum, they don't care about classes or other OOP features. If there was something that sort of grogs what C programmers want, it's probably zig-lang.

To put it in short, C programmers hate needless abstraction and work with raw memory and hand-crafted data structures whenever possible. More data, less code.

Putting on my embedded engineering hat, it's not that I wanted the bare minimum it's that I couldn't afford anything more than the bare minimum.

I couldn't afford abstractions, memory safety guarantees, algebraic data types, generics, pattern matching, thread data safety (at least in the context of interrupts). The languages that had these things were hulking languages with giant runtimes and exactly zero support for embedded development. Not to mention no vendor toolchains.

Rust supports all these things, with no allocator, no standard library, and often with zero additional cost -- in terms of compute and in terms of memory. Then, being built on LLVM means that the vendor toolchain support is quickly becoming a non-issue. I suspect we'll start to see more and more of Rust in embedded, but only time will tell.

And as others have called out, Rust has very few OOP features like an optional notion of a `self` on a function bound to a structure. There's no classes, no subclassing, no message passing, no inheritance at all (structure, interface or implementation), limited dynamic dispatch, no polymorphism.

> Rust has very few OOP features like an optional notion of a `self` on a function bound to a structure. There's no classes, no subclassing, no message passing, no inheritance at all (structure, interface or implementation), limited dynamic dispatch, no polymorphism.

As an embedded developer for a living, if you put it that way, then the first thing it comes to my mind is "so why should I bother learning Rust" for embedded.

Other than the usual "please consider UB and network/memory handling/security issues" (reasons that don't really affect me), so far nobody could provide a convincing answer.

It's not that the usual answer I get is wrong or invalid or doesn't have a point. But if I ask "ok, what else?" there is really little motivation for me to move on.

Someone once told me I'll become an outdated curmudgeon here on HN, but I think I'll be long gone before something truly deserves to replace C for embedded (and low level).

Personally, I always encourage people to learn new and (particularly) different languages from time to time and see what concepts and design patterns they can learn and take with them into their day to day. All I can say is give it a shot sometime and see what you think. Worst case you've learned something :)

> Someone once told me I'll become an outdated curmudgeon here on HN, but I think I'll be long gone before something truly deserves to replace C for embedded (and low level).

You (and I) may become an outdated curmudgeon before long, but it won't be because you refused to learn Rust haha.

> the first thing it comes to my mind is "so why should I bother learning Rust" for embedded.

Generics alone are a huge time saver compared to C, even if you use hacks like macros in the latter to do something similar already.

> C / embedded developers

Embedded developers use C because they have to, not typically because they want to. And they have to use C because of proprietary toolchains and existing libraries, among other similar reasons. Good reasons, sure, but not because C the language is so great.

> hand-crafted data structures [...] More data, less code

You're paying lip service to the principle of datastructures-over-algorithms, yet you're advocating for a language which has neither algebraic data types nor tuples? Come on. That's like praising functional programming but using Fortran.

Rust doesn’t have classes or indeed many traditional OOP features, and it has an extremely strong focus on data.

> To put it in short, C programmers hate needless abstraction and work with raw memory and hand-crafted data structures whenever possible.

I wrote Monocypher in C for one reason: portability.

From a systems point of view, crypto libraries are trivial: you don't need any dependency, code is pathologically straight-line, there is no almost data structure to speak of beyond arrays of bytes and arrays of words.

Yet I can tell you that if not for portability, Rust would have been a better fit. So I could group buffers and their size in a single argument. So I could provide genuinely high-level interface. So I could use types to avoid silly mistakes and enforce some invariants. Portability won over all that goodness: worst case I can have a Rust wrapper. Heck, someone else already wrote one for me.

These zero-cost-abstraction languages don't pay much attention to binary code size. They can't compete with C in that regard. For the low-cost, high-volume embedded devices, code size relates to the unit cost, and thus the profit margin.

Just read this.

https://www.ecorax.net/as-above-so-below-1/

> To put it in short, C programmers hate needless abstraction and work with raw memory and hand-crafted data structures whenever possible. More data, less code.

This. Even if it is less safe.

C says "Rust? Who?"

> Rust doesn't get why C programmers still use C at all.

Because Rust is redundant, its safety guarantees are a subset of safety guarantees of ATS[1]. A project in plain C integrates more naturally with it at any point of its development cycle[2], and it doesn't require giving up safe pointer arithmetics[3]

[1] http://ats-lang.sourceforge.net/DOCUMENT/ATS2FUNCRASH/HTML/c...

[2] http://ats-lang.sourceforge.net/DOCUMENT/INT2PROGINATS/HTML/...

[3] http://ats-lang.sourceforge.net/DOCUMENT/INT2PROGINATS/HTML/...

EDIT: those who downove, let's discuss the topic in substance and let's avoid zealotry. If you promote and pitch Rust to the audience of C by advertising its safety guarantees, zero cost abstractions, and how well it integrates with C ABI, at least be consistent when it turns out that there's another $TECH that does it safer and more consistently with C programmers' reliance on certain useful features of C.

Are you really arguing that Rust is currently redundant because of a language that hasn't hit v1.0.0 yet, has no industry support, and doesn't use a modern build system or package manager?

I do really argue that Rust is redundant for C developers who want to bring some extra safety into their projects without disrupting their toolchains and practices. I also argue that this extra safety can bring more than Rust is capable of providing. Now, what's the technical merit of Rust that justifies spending time learning it when the same time can be spent on bringing ATS into the same codebase/toolchain one function at a time?

What's the point of waiting for 1.0.0? It's just a tag that doesn't save you from bugs and breaking changes.

What is industry support? What does it have to do with a team where everyone can read the documentation of the tool that is already built on top of a mature GCC ecosystem and that adheres existing approaches to debugging, profiling, releasing and maintaining C codebases?

> and doesn't use a modern build system or package

Why do I need a separate solution such as Cargo if I can build, package, and distribute everything with Nix and get reproducibility, distributed builds, transparent caching, and environment isolation along the way for free?

C won because it was the only low level language that was competently implemented for DOS for years. DOS was were 90% of the programming action was in the 80's, and C was a perfect fit for DOS. C also was easily extended to handle segmented memory.

(Turbo/Borland) Pascal was comparable to C in terms of closeness to hardware on DOS - I mean, it even had language facilities specifically for interrupt handlers! A lot of DOS software was written in that. In some countries, it was the case for most DOS software made in them.

So I'd amend this to: C won because it was the only cross-platform low level language that was competently implemented for DOS.

I'm enrolled for a masters at Georiga Tech right now and last I checked the OS course is in C, I would kinda prefer to learn rust anyway so I hope you are right.

Why would you prefer to learn Rust at this point, especially during OS course when all relevant OS code you will encounter is in C and understanding C is crucial to understand low level programming concepts. You can always learn Rust later when/if it becomes more relevant. Without C a lot of programming areas will be a closed door forever.

> understanding C is crucial to understand low level programming concepts

That is a patently false statement. To understand low-level programming concepts, you need to understand fundamental notions about how machines represent state in registers and memory, how memory is organized (including primarily the concept of function calls and the stack), and the indirect referencing of memory via pointers. Note that nowhere in that list did I describe a concept that is unique to C.

In fact, one of the more common approaches to introducing developers to low-level programming is to introduce them to these concepts via assembly (say, Nand2tetris). In my own experience TA'ing such a course, I am more than willing to translate code into whatever language the student is most comfortable with to express the concepts as necessary. You can absolutely learn these concepts in other languages, and my own suspicion is that unsafe Rust does a slightly better job of it than regular C does.

C does not have a monopoly on understanding the low-level organization of code, and quite frankly, C's lack of coverage here can be frustrating. C has no concept of multiple return values, functions with multiple entry points, unwinding the stack, computed goto, SIMD vector types, nested functions, discontinuous structures, or tail calls, and these are all concepts that are present in other languages that cannot be expressed in standard C or often even in vendor-extended C.

> You can absolutely learn these concepts in other languages, and my own suspicion is that unsafe Rust does a slightly better job of it than regular C does.

> C has no concept of multiple return values, functions with multiple entry points, unwinding the stack, computed goto, SIMD vector types, nested functions, discontinuous structures, or tail calls, and these are all concepts that are present in other languages that cannot be expressed in standard C or often even in vendor-extended C.

ATS does a better job than safe Rust and you can think of it as a vendor-extended C (http://ats-lang.sourceforge.net/DOCUMENT/INT2PROGINATS/HTML/...).

https://tc.gts3.org/cs3210/2020/spring/info.html

Dunno how often this class runs, and if it was just for one semester or more than that.

GT just switched over in the spring semester, I believe.

> Linux is allowing Rust for device drivers and kernel modules.

Oh, did this happen? I remember some discussion some months ago, has it actually been merged?

Nothing has merged yet, but the basic plan to start allowing Rust has been approved at a high level.

One area I still see it pop up frequently is audio related code on mobile.

Reply on news.ycombinator.com