Hacker News Reader

Comment by DCKing | Hacker News Reader

I was already secretly imagining a future where Rust will completely replace C as the low level language for everything. Even the Linux kernel rewritten in it eventually. It'd be a much better world with no #ifdefs, strong type safety and memory safety depending on compilers instead of fallible programmers.

But I was expecting it would take a while before people had the ambition to start doing these things, even when it comes to the smaller ambition of rewriting the GNU coreutils. Rust is a great language already, but it's not a stable language yet.

I wonder if my imagination will become reality eventually. There's really good buzz around Rust now, and it's not even 'production ready'.

View on HN

The best advantage of writing libraries in C is that it allows the library to be usable via FFIs in many other languages. Also, C is extensively standardised, widely used and thus greatly test-covered. This is a nice property of the language, as the programmers can be sure that as long as they follow the standards, they'll find a compiler to compile the programs they write. I have not used Rust for more that «Hello world!», but I know that I'd regret sooner or later, if I wrote a multi-million line project in a language that is not somehow standardised.

Also, memory safety is hard to enforce, I reckon, while controlling the memory hardware, which is what an operating system like Linux* has to do. Rust can be used, but still, there are many unsafe things that OS has to do, like moving and assigning pages, managing which programs use which pages, swapping, etc.; which, I reckon, requires knowledge and usage of physical memory addresses and access to individual bytes.

Rust may be an appropriate and advantageous language to use for the non-core parts of a microkernel, though.

* I acknowledge that Linux is not an operating system per se.

Rust has memory safety by default. However, it can do memory unsafe things in special blocks[1]. So it can do everything low level that C can, including controlling memory hardware [2]. It does unsafe things only in special blocks that can be specifically audited. That's part of why I find it so promising.

C has no memory safety by default. So if you want to audit your C program for memory safety problems, those problems can be anywhere. Even if that C program/component doesn't actually need such low level access in the first place!

[1]: http://static.rust-lang.org/doc/master/rust.html#unsafety

[2]: Here's a list of (hobby) kernels written in Rust: https://github.com/mozilla/rust/wiki/Operating-system-develo...

Everytime I say something negative about Rust, the counterarguments push me to learn the language. I'll definitely check out the kernels page, thanks a lot for that.

With your comments I have to concur. I have also read a comment on name-mangling somewhere on this thread, probably one that you've written. If C can be replaced with Rust for most-if-not-all applications in future, it is a step forwards IMO.

In my opinion, your argument about only C being usable from FFI is a strong one against using Rust if you're making a library.

It is possible to expose Rust data and functions to Python, Ruby, etc, since Rust is ABI-compatible with C. Unfortunately, you lose most of the Rust standard library since the Rust runtime is not freestanding. And I'm not sure how -- or if -- Rust will fix this issue. It's certainly desired, but it will be a lot of work.

The only bright side to all of this is that Rust is such a modern and pleasant language to use that scripting language bindings are almost not needed. Almost. But it's still a enough of a low-level language that bindings are highly desirable for quick prototypes, exploratory programming, and other scripting tasks.

  > I'm not sure how -- or if -- Rust will fix this issue.

We're addressing this as we speak! We've split out the stdlib into many constituent libraries that depend on each other, and then just made the stdlib a convenient facade for these libraries. After opting out of the stdlib, you can then opt into any of the "core" libraries as you like, a la carte. Many of these smaller libs don't rely on the runtime (they don't depend on librustrt) nor do they rely on allocation at all (liballoc), and can thus be used in a freestanding environment. See the other comment in this thread for more details:

https://news.ycombinator.com/item?id=7883451

Oh wow, that's great to hear. Any idea when/if basic, safe network/file IO will be possible without the runtime? Or is it already?

> Also, C is extensively standardised

Not really, at least not in the sense that you mean here: The generation of machine code in shared objects. There is a distinct lack of definition between C syntax and the resulting machine code.

> The best advantage of writing libraries in C is that it allows the library to be usable via FFIs in many other languages.

You can create C shared objects from Rust (or from a ton of other languages which generate native code). No big deal. It can do what you want.

> There is a distinct lack of definition between C syntax and the resulting machine code.

And more importantly: there is a distinct lack of similarity in behavior in this respect between vendors, versions, architectures, language features, ambient temperatures, and times of day. Change any of those things and you can get different output from your C compiler.

But not C include files. I think nimrodhas something here. Vala? I do not know.

That's just because Rust is still in development, and tooling like that is developed incrementally. There's already an issue about automatically creating C headers representing a Rust library, https://github.com/mozilla/rust/issues/10530 (and Alex Crichton has even started working on a tool for it, see his comment).

> The best advantage of writing libraries in C is that it allows the library to be usable via FFIs in many other languages.

Rust has allowed this for over a year at this point. For example, see the (old) blog post "Embedding Rust in Ruby": http://brson.github.io/2013/03/10/embedding-rust-in-ruby/

And the third production deployment of Rust is at Tilde for skylight, which uses a Ruby extension written as a Rust library with a thin C wrapper, due to Ruby's extensive C macros which would be annoying and bug-prone to port.

Like creating servers or user space drivers. That is what IOMMU is for.

Total language displacement is a pretty rare event, and technical superiority isn't even a prerequisite.

And I happen to like having a preprocessor.

Yes, it's far too early to tell. The good thing to take away is that, at the moment, the answer to "is Rust a viable threat to C/C++?" does not seem to be a categorical no. The same cannot be said for other languages in the area, such as Pascal, D, Ada, Nimrod and even Go, although all of these languages have their use.

Any adoption of Rust in areas where people otherwise use C/C++ is an improvement I think. It doesn't have to be total displacement, and that will never happen.

Any systems programming language can displace C.

You just need a successful OS vendor pushing the said language as only means to target their OS.

I think the reason many people are rooting for Rust is because it's got comprehensively better features than competing languages. I'm not talking just about memory safety, but also its adoption of functional language features. I'm of the opinion that immutability-by-default, pattern matching, first-class functions and real macros combined with no garbage collection are a Very Good Thing™ for this type of language (and I'm not the only one).

So yeah, I disagree that any systems programming language can displace C. Other system languages simply don't come with the same amount of improvements that Rust offers.

> So yeah, I disagree that any systems programming language can displace C. Other system languages simply don't come with the same amount of improvements that Rust offers.

So, given my premise, how do you target super-cool-everyone-wants-it-os that only offers new-cool-language as their system programming language in the OS SDK?

Are you going to write a C compiler in new-cool-language to be able to keep on using C?

Why not cross compile?

You could as well.

In case case the C runtime has to be implemented on top of the new-cool-language ABI, as it is the only way the vendor supports creating software for their system.

What I am describing is not that different from thirty years ago when C was a UNIX only language, and other OS had other languages as their systems programming language.

> super-cool-everyone-wants-it-os that only offers new-cool-language

I'd suggest that these are fundamentally incompatible statements. "Only offers new-cool-language" is another way of saying "it's a pain in the ass to port to - you have to rewrite your whole app!" if you're coming from anywhere that's ever touched not-quite-as-cool-language.

D is a viable alternative to C++, period, not necessarily to C. I believe a rewrite of Xorg in D would be googd. The only problem with all these languages is that you cannot e.g. create a dll in Ada and generate appropriate headers to use it in C, even more in Go. In this respect I feel that this is the real problem here. The biggest obstacle is the C++ legacy code.

D is absolutely a viable alternative to C++ and probably C. There's no argument there.

D is not a viable threat to C/C++ (this is what I said!), as noone is really thinking that D will actively displace the use of C/C++ in many projects in the future. The same goes for all the other languages I mention. In my perception there's a buzz around Rust that indicates it might be viewed differently.

Can you use D without GC? How would it look like? If very restricted, then I don't see it as a viable C++ alternative. I'm ok with GC on a web server, but coreutils are better without it.

It is possible to allocate objects in the stack (objects without polymorphism, defined with the struct keyword). No use of heap and GC in that case at all.

It's not that different to using C++ objects in the stack.

If by no GC you mean to use heap allocated objects with manually managed destructors, then I think the answer is no.

I'm looking at "http://dlang.org/garbage.html" section "D Operations That Involve the Garbage Collector", and there are some pretty interesting things on the list that require GC: all dynamic arrays, associative arrays, closures, asserts. Can you even read a file without these?

In college, a group of is (mostly my friends) wrote a kernel in D, with no GC: http://xomb.org

It's true that D's stdlib still uses GC, but he D team has been working on eliminating that.

You can write the non-GC part in C and call it from D. What is the prercentage of an app that is going to get harmed by GC? I believe it is manageable in C or even FreeBasic or even Freepascal or even Assembly. I used to believe that C++ is the best. Not the last three years.

Having a preprocessor is nice. Having a real macro system is nicer.

I consider them to serve different purposes. For stuff like the Linux Kernel, the preprocessor is great because it can be used with any number of different types of files the Linux Kernel has in it's source. The Kernel configuration basically just becomes a bunch of #define's, and you can access that information from C, assembly, linker scripts, etc...

How is this nicer than a configuration file template?

the nice thing about cpp is that you can use it on any file.

... unless the file contents happen to clash with CPP syntax.

I hope that never happens, because I think such a world would be extremely dystopian. Strong safety guarantees sound very beneficial at first ("safe" anything in general tends to evoke that response), but as shocking as it may seem, a lot of the freedom we have today is a result of using "unsafe" languages like C: iOS jailbreaks, Android rooting, homebrew on game consoles, and many other examples of freeing one's devices from restrictions imposed by the original manufacturer and giving control back to the user depend on this. These bugs and vulnerabilities, although they can be exploited maliciously, are in some ways like an escape hatch from the tyranny of corporate control. If strongly safe languages become the norm, all these would disappear and our computing experience become even more locked-down and restricted. The thought of them being used for DRM is scary (I remember reading an academic paper that suggeted this as one of their applications, and that's one of the thing that provoked me into really starting to think about this.) Even open-source software where safer languages appear most beneficial can be used against the user.

Ultimately is a security vs. freedom tradeoff, and I think we've sacrificed too much of the latter already.

I'm baffled by that opinion. The fact that memory-unsafe software keeps on being produced in C/C++ is a good thing? The capabilities of criminals to run local (or remote!) root exploits on many devices is offset by the fact that some hackers can tinker with them?

Freedom should be achieved in different ways. Please don't make freedom and security contradictions.

Yes, it's definitely controversial but I think a little bit of insecurity is a good thing but not too much -- the question is how much. Consider that had the NSA been far more secure in their processes, the whole Snowden thing may have never happened... which is somewhat ironic.

> Freedom should be achieved in different ways. Please don't make freedom and security contradictions.

In an ideal world, they wouldn't be. Unfortunately that's not how it is in reality.

So what do you think about the NSA's capabilities to easily rootkit your "free" exploitable device? I don't think this is a consistent worldview.

Freedom is not about consistency in everything.

I've never said that freedom is about consistency. Opinions should be consistent if they are to be taken seriously.

This guy wants to intentionally leave software exploitable, ready to be unknowingly hacked by criminals or governments, and call it freedom. And he gets upvoted for it!

What's not consistent?

Also, it seems that "criminals" are the new "terrorists".

To play a devil's advocate, I want to answer this directly as answered.

Available information indicates that NSA used various coercion tactics to ensure cooperation from various companies and that it has the methods to ensure hardware modifications in its own interests.

So the damage to NSA from improving security too much is less than damage to my ability to use the computing device I have paid for as an actual computing device.

Of course we should also consider smaller threats.

But the better the platform is locked down, the less limitations there ae for advertiser-friendly platform design, which makes people expect a lot of permissions requested by applications, so phishing and trojans become easier.

The problem here is about the effects of scale: it is hard to produce just a few thousands phones with good specs.

That freedom also means I have the freedom to modify my device after exploiting it in order to remove those exploits. On the other hand, a device that is completely unexploitable due to being written in a strongly safe language, would mean I no longer have that freedom - and while it may be unexploitable to everyone else, I'm pretty sure the NSA has its ways to get in anyway; if it does, then there's no escape.

So, you like languages that are prone to obscure bugs because they allow you to remain competitive with the NSA?

Practical experience shows that once you run into even routine systems programming elements, like writing device drivers and whatnot, you eventually have to concede some safety, or end up with an unprogrammable behemoth of such baroque complexity that you likely have more security holes, just of some other kind. There has been a lot of research into this back in the 1990s; most of the useable results produced security by architecture rather than tools.

It's almost as if what one would want is a language where you could shrink unsafe operations to as small a footprint as possible by confining them within a block with a special keyword, like this:

     unsafe { … }

Someone should invent such a thing.

Edit: …yeah, I was being tongue-in-cheek. This is exactly what Rust provides.

http://doc.rust-lang.org/rust.html#unsafety

"...When a programmer has sufficient conviction that a sequence of potentially unsafe operations is actually safe, they can encapsulate that sequence (taken as a whole) within an unsafe block. The compiler will consider uses of such code safe, in the surrounding context…"

- http://msdn.microsoft.com/library/chfa2zb8.aspx

- http://doc.rust-lang.org/rust.html#unsafe-blocks

If I call a function that is running unsafe { } inside of it, do I know? Because I really want to know. And I want my function to be marked as unsafe as well (because it is) as well as any function calling my function, etc.

You don't know, but you can use a compiler flag that will tell you if you are.

> I want my function to be marked as unsafe as well (because it is)

This misunderstands the nature of `unsafe`. `unsafe` means "I promise that this is actually safe, even thought it can't be inferred." Take, for example, a type which has mutable, shared state, but enforces all access through a mutex[1]. This type presents a safe interface, but the compiler can't know that it's safe, so you have to use `unsafe` internally.

1: http://static.rust-lang.org/doc/master/std/cell/struct.RefCe...

> If I call a function that is running unsafe { } inside of it, do I know? Because I really want to know.

Pretty much every function is going to be transitively running unsafe code, since the core libraries use it to implement the base primitives.

It should be noted that the unsafe code in the core libraries is kept to a minimum and (at least in theory) heavily scrutinized.

All code in mozilla/rust gets a code review before landing, so there's always at least 2 sets of eyes on it.

The way that you mark a function as unsafe is to stick a keyword in front of it:

  unsafe fn foo() { ... }

Any function marked as such is then allowed to call other unsafe functions:

  unsafe fn bar() { foo(); }

But there is a way to break the chain, which is to use an `unsafe` block without marking your function as unsafe:

  fn qux() {
      unsafe {
          bar();
      }
  }

That said, it's incorrect to think that Rust is any more unsafe than any other language because of this; most languages simply defer this behavior to their FFI. By pulling it into the language itself, Rust is actually safer than e.g. calling C from Python, because Rust can do the low-level fiddling while still retaining at least some of the safety checks of normal Rust code. Even unsafe Rust is safer than C.

> Even unsafe Rust is safer than C.

This is an important point. `unsafe` blocks only let you do a few extra operations[1], not anything you want. A lot of safety checks still happen inside of unsafe blocks.

1: http://static.rust-lang.org/doc/master/rust.html#behavior-co...

Well, no, you can still theoretically do anything you want, you just need to be very, very explicit about it. :)

Some things are undefined behaviour[1]... so you really don't want to want to do them (i.e. you can do them inside `unsafe`, but the compiler optimises/reasons assuming they never happen: if they occur at all, you could have an arbitrarily broken program).

[1]: http://doc.rust-lang.org/master/rust.html#behavior-considere...

The point that I'm trying to make here is that you cannot make any assumptions about an unsafe block. Anything can happen, including really terrible undefined behavior. But the fact that anything can happen is why Rust is as powerful as C in this area.

My point is that while anything _can_ happen, it's not like Rust just turns off every single check. Yes, they can be gotten around, but it's not like the type system suddenly goes away.

I think a lot of us are somewhat happy with freedom being maintained by the laws of the land. Granted, those do seem under attack, as well. Oddly, by a similar mantra as what leads type safety.

Consider, in a "type safe" law system, intent doesn't matter. Only what you did. Now, look at the laws that run on that principle.

Now, I personally think this is probably orthogonal to type safe programs. But I'm not completely convinced, yet. Type safe programming seems hamstrung by the fact that a type system only really protects that which is specified in the type system. Which seems to mean you can't easily have a variety of ways to do things, as ultimately the type system has to grow to encompass all of the system.

Now, I grant I'm probably just soured by some bad systems in the past where a change to one part required a rework of the entire system.

Most type safe systems have escape hatches that allow for conversion between types.

Also, IME, type safe languages don't hobble me as a programmer. However, the systems and things I work on (and am trying to get work on) have generally well considered specs associated with them. Be it radio protocols, file formats, or whatever. A type safe language (haskell, sml, ocaml, ada, rust (it seems, not explored it much yet), etc.) can really help with these projects. Instead of needing a dictionary translating what magic # 134 means if it's used in this context (god, these old fortran programs break me), we can actually specify things in code in sane, clear ways that map from spec/design to code cleanly. OO, in theory, can help us with this, but it also adds a lot of overhead to create a ton of classes when really we want integers that the compiler knows some are meant to be temperature and some are meant to be pressure. If you start adding temperature and pressure, it flags it. If there's some formula where that actually makes sense, you deliberately, intentionally, explicitly handle the conversion. This is a good thing. Slightly more verbose code, but such a boon for mainenance and v&v work.

Doesn't shock me too much. The experience I have had is when folks basically try to do their programming in the type system. This can work for some cases, maybe all if you "do it right." I've not been lucky enough to see that. Instead, I like it when the types are basically there to help, not force, you.

Good post. We need to remember that security is a transitive verb: we secure something against something or someone. As you say, DRM is "securing" a device against the user.

More freedom for mediocre or bad coders = more ways to fuck up. More freedom for good coders = more ways to make great things (and fuck up).

So basically it's a tradeoff. If people working on the Linux kernel were very careful and good hackers, writing in C would be much less of a risk than letting fresh-out-of-college programmers tinker with memory on the low-level. But even very careful and good hackers can screw up sometimes—see what happened with OpenSSL.

I don't see a reason not to use Rust except for performance, or when the unsafe features of C are required to get the job done. I can't say a lot here because I've only seen Rust's syntax and feature list and never programmed in it. (On the other side, I've written a fair amount of (functioning) code in C, and I feel that debugging race conditions coupled with memory management bugs has shaved a few years off of my expected lifespan already.)

Rust shouldn't be a performance problem. The language semantics allow for all the things that make C fast, as well as doing a better job at aliasing.

Idiomatic Rust will drop a little bit, to the level of idiomatic C++, but there's nothing stopping you from optimizing that to C levels in exactly the same way when necessary.

What about bounds checking and stuff? Sorry for my ignorance on the matter.

It seems you can use unsafe versions of vectors/arrays/strings to bypass bounds checking. Essentially, if you're very confident that your code is correct, then you can speed it up (is it worth it?) to C levels.

On the other hand, a lot of bounds checking is probably going to happen where you'd manually enter it into C/C++ code anyways (if you wanted to avoid certain errors).

Additionally, idiomatic Rust code will employ iterators rather than direct indexing where possible. Rust's iterators are memory safe and do not perform bounds checking.

It appears the compiler optimizes out bounds checking if and only if it can tell during compile time that the index is correct [1]. Arrays of dynamic size or with dynamic references are bound checked. In dynamic cases you should be writing manual bound checking guards in C anyway.

[1]: https://github.com/mozilla/rust/issues/9024

Not only do iterators help avoid them in most cases, I'm anxiously awaiting Intel MPX for more hardware support for bounds checks.

Fortunately Rust has unsafe { ... }

It's interesting to think of an insubordinate dev being tasked to write some horrible locked-down system in Rust and going, "yeah, this thing has to be in an unsafe block because xyz, oh, woops, I guess I introduced a jailbreak opportunity".

Agreed... I'm quite worried about unsafe code in libraries that I'd use.

Not that jailbreaks aren't a good thing, because I'd hate to be forced to use a locked (aka dumb) device.

I doubt that most jailbreaks have anything to do with buffer overflows or pointer bugs in C code.

The iOS jailbreaks used to (haven't followed them recently) involve exploits in C/C++/Objective-C code. They've taken advantage of various system applications to install the jailbreaks. Some used exploits in PDF handling, others in USB handling.

This is a really frightening post. There is a real tradeoff between security and freedom, but memory safety is not where it manifests. It manifests in the fact that if you give the user power to mess up their system, sometimes they actually do it. However, the dichotomy between freedom and basic memory safety is false and needs to be fought tooth and nail. Your believing it is a minor victory for the corporations you excoriate.

When we build the next generation of free operating system, I want it to be as secure as humanly possible. Your device isn't free if the NSA or some criminal has owned it.

How is it a false dichotomy if things like jailbreaks and console homebrew essentially rely on the lack of memory safety to work?

> Your device isn't free if the NSA or some criminal has owned it.

It's not free if you can't own it either - and that's where the problem lies: how do we stop the secure systems we create from being used and secured against us.

It's a false dichotomy because there's a possible world where you don't have to resort to that crap to get control of the device you bought, where you're in charge at the start (looking back, I wasn't explicit about this, sorry). That's what we should be working on, not holding back the state of the art of programming languages. That's the wrong place to attack the problem.

That would be an ideal world, and I agree that safer languages definitely do make sense there, but the big question is how do we get there.

> That's the wrong place to attack the problem.

Then what do you think is the - currently practical - way to attack the problem?

I think there is a bit of misunderstanding I created in my original post; I'm not completely against security and hate buggy software as much as anyone, but only pointing out that we rely on insecurity for many good things and freedom we have today, and thus we should give more consideration to the implications of using more secure languages before they get to the point of becoming so popular that there is no turning back. They're just such a good fit to be used in trusted computing/DRM systems, and that's what scares me the most.

That fear is akin to governments being afraid of cryptography. The genie's out of the bottle, we know how to make better languages/development environments. The question becomes, do we deliberately hobble ourselves or do we accept the reality and move forward. The "enemy", if they're rational, will be moving towards these better tools. On the other side of the fence, we should as well. Otherwise we're leaving our own code and systems open for abuse.

Ultimately, the only way to correct this is the active encouragement of DRM-free content. The active development of FOSS software. The active development of open-specced hardware. Let's take these tools that let us develop things with fewer errors (or where errors are made blindingly obvious) and make this free world we want.

You don't achieve freedom through bad software. What the hell? Note that the NSA spying on you is also facilitated by all the complex, buggy, broken software we use.

I don't think it makes sense to rewrite the Linux kernel in Rust. As long as we're dreaming, let's talk about a new OS without all the legacy cruft. Be sure to make it hard to lock the user out, so userbinator is happy too, but (again) as long as we're dreaming that's on the agenda too.

Developing a lot of relatively small programs seems like a good way to get experience with the language, find issues with it, report them, etc.

Reply on news.ycombinator.com