Comment by DCKing | Hacker News Reader

Comment by DCKing | Hacker News Reader

Parent Full thread

As someone who never much got into systems programming, Rust feels like a breath of fresh air. It makes systems programming way more accessible for me personally, coming from non-systems languages. Learning to write C well is just not something that appeals to me at all.

From mostly an outsiders' perspective, I just don't think C is a very nice programming language. It looks easy to to pick up and it probably is (for some definitions of "pick up"), but I don't think that's a good thing. The language gives you almost nothing. Pointers, structs, arrays, control flow. Not much else. I'm barely exaggerating when I say that all the C code I see looks like a chaotic pointer juggle fest for precisely that reason. The few features and library that it does have come with non-obvious gotchas that will punish you later.

Rust is probably much harder to "pick up", and way more complicated in general, but it's just, uh, more language. I'll take pattern matching, encouraging immutability, functional style programming, trait programming over C's simplicity any day of the week. The safety is extremely nice, but I think Rust's biggest eye-opener for me is that all these "higher level" features are just possible at (close to) the performance of C. That makes it very appealing to me.

> As someone who never much got into systems programming, Rust is a breath of fresh air.

I think that's part of the problem :) Because Rust looks high level it appeals to people used to high-level programming. But once you get into systems programming, the issues are different from high-level programming, and you're less happy to pay for features that solve other problems. What I'm saying is, obviously, a matter of taste, and some people doing low-level programming do prefer C++'s high-level feel, which is also found in Rust. I hope it goes without saying that just programming in Rust -- or C++ -- doesn't mean you're doing systems programming unless you're, say, writing a device driver, a kernel, a GC, a game framework etc.

Part of the problem is that "systems programming" is an overloaded term that means a number of different things. Is writing a web browser "systems programming"? What about a CLI utility like grep? Kernel module? Bare metal on a STM32? Depending on who you ask most of those will get both a yes and a no answer. On a related note, some language are more or less suitable for each of those. Can you write an OS in Java? Yes. Should you? Probably not.

I think one of the previous comments, and others on other forums have things right when they say that Rust is a better C++. Anything you would consider using C++ for is a good candidate for using Rust for. Rust is not a better C though, it's just a bit too high level for that. There are languages that are aiming to be a better C (Zig is REALLY interesting, but very very new right now), but Rust isn't really one of them.

I could very easily see something like an OS aimed at x86 desktops being written in Rust. Desktop systems are beefy enough and the problem space is complex enough that the extra overhead involved in Rust (similar to C++) makes sense. On the other hand if you're doing some bare metal work on something like an Arduino you just don't have enough there to justify the extra overhead and something very basic like C (or assembly, or Zig once it matures a bit more) is probably a better fit.

If you're doing anything higher level than kernel programming, Rust is just as viable as anything else, at that point it's mostly down to personal preference on whether you can deal with not having conveniences like garbage collection or not.

> Can you write an OS in Java? Yes. Should you? Probably not.

PTC, Aicas and Gemalto embedded JVMs for industrial automation can run either with a real time OS, or directly bare metal with Java Real Time JSR.

Android has plenty of Java in it, as of Project Treble it is possible to write user space drivers in Java, something that Android Things supported since the beginning.

MicroEJ has a minimal hardware glue in C, with everything else in Java.

At CCC there was a demo about TamaGo, bare metal Go for USB security devices, then there is also Astrobe with Oberon-07, the new Meadow boards run .NET Standard based OS.

Arduino and ESP 32 support Circuit Python, uLisp, MicroScheme and picoOCaml.

So plenty of systems programming examples with GC.

> If you're doing anything higher level than kernel programming, Rust is just as viable as anything else

I don't think so because it suffers from the same limitation that all low-level languages have, which is that API clients need to be aware of implementation details. Rust sometimes makes that propagation of leaked information automatically via the type system, but internal implementation details -- how allocated memory is managed, whether a target is a subroutine or a coroutine, whether an argument is passed at runtime or compile-time -- still leak in a viral way. It's just that Rust and C++ can look high-level, but they don't behave like high-level languages. But Rust is great for those low-level programmers who like this high-level style and are willing to pay for it.

That's not a limitation of "low-level languages", it's inherent in low-level API's. These two are not the same. You could have a Rust program that interfaces with outside systems only via protobufs over a network socket, or what have you, and it will work just fine. Same for just about any "high-level API" format you could think of. Of course, using such high-level formats comes at an efficiency cost since you have to translate along the way. But other languages are the same, they just hide that step from you.

The program itself is made of components that expose a low-level API, or otherwise you wouldn't use a low-level language. The API clients are other parts of your program. Programs written in low-level languages are much more tightly coupled than languages that support better abstraction (for the price of less control).

You're probably correct, but I think Rust is probably fitting a solid place of making developers used to higher level languages actually -look- at embedded programming. It's an entry point.

Now, for those who get involved enough in it, they might find issues with the language, and that will provide them incentive to get comfortable with C. Or maybe they won't; maybe they'll get turned off at that point, or maybe they'll find making Rust work a better option, or they'll find still another language that is even closer to C, without the holes.

But either way, providing a way to move in that direction without having to immediately accept all the baggage C brings seems like a good thing. It certainly has moved my mindset from "screw embedded unless it's beefy enough I can run Erlang" to "well, maybe; Rust looks interesting". And I figure if I get comfortable enough with looking into the space, I either

Does the travesty that's currently playing out in the IoT space suggest that we now have a shortage of good embedded people or am I reading that wrong?

A tool that gets more decent developers to even look at embedded sounds like it would have been a good thing to have 5+ years ago, but better late than never.

I don't think there's a shortage of good embedded people. A lot of the companies involved in this travesty could afford them, and have access to good candidates, but have no reason to do it. Cheaper and commoditized hardware has lowered the barrier of entry for selling your own stuff, and the lack of regulation means that the consequences for screwing up in terms of security or privacy are basically zero.

What you see happening isn't an accident. There are companies that do excellent IoT work, with excellent people. Many companies that don't could afford to excellent engineers, and have access to a terrific pool of candidates, but their management chooses another way and they're perfectly aware of what they're doing.

(Sauce: am embedded developer, has been involved on and odd in the IoT scene since 2011 or so).

The nice part about Rust is that if you don't want to use a given feature, you can just ignore it. You can totally write Rust in a struct + functions style, just like C.

If you want higher level abstraction only in some parts of your codebase, you can do that too. It's easy to mix-and-match.

Right, like C++.

Sure, but you still get memory safety.

... hence a better C++. If a better C++ is what you want, then Rust is a great fit.

In 1995 people said Java was a "better C++", but it was basically 1991 C++ plus GC (and numerous misunderstandings), minus concrete types.

Rust can do more of the things C++ can do than Java can, but there is a very great deal that can be put in a C++ library that is wholly beyond Rust's capacity.

If you have lesser expectations to capture semantics in libraries, or to use such libraries that do, Rust serves. But the gap will only grow wider.

> but there is a very great deal that can be put in a C++ library that is wholly beyond Rust's capacity.

Just out of curiosity, do you have some examples?

The easy examples involve operator overloading.

Some more subtle would involve template dispatching according to properties of the types operated on.

But just run down the list of features supported in C++, and not in Rust, and think about how they could change how a library interface or implemention would look. Most C++ features are meant for people writing libraries.

Rust has limited operator overloading. You can do common operations like arithmetic, but you can't define symbol soup

For me it is already enough to be high level as Object Pascal (the original Mac OS variant) or Modula-2, let alone what came later.

Although they do have security issues regarding use-after-free.

Reply on news.ycombinator.com