Hacker News Reader

Comment by jcoffland | Hacker News Reader

Rust is also still very far from having eaten any significant chunk of C.

I think IoT will push embedded development towards Rust. As well as security critical desktop/server code. Especially when said code needs to be a loadable library (.dylib, .so, .dll).

While Rust certainly isn't the silver bullet, it demonstrably significantly reduces memory and concurrency related bugs.

Yeah, the last firmware I developed was in C and assembler. No, I could not have done it in Rust, mainly due to no Rust compiler available for the arch. Then again, I could not have done it in pure C either...

For future platform selection availability of a Rust compiler is already a factor. Even if we'd still end up using C/C++ for now.

Since Rust does not yet really work on ARM Cortex or AVR it's still a long way from taking over IoT. Only devices with an OS, like a RaspberryPi, are properly supported by Rust at this point. That's a huge limitation. GCC can target literally hundreds of bare metal devices with C and even C++. Developers have been using C and C++ successfully in IoT devices for years now.

Rust may be the bees knees but it has many hurdles to overcome before it dominates a language that has been around for 46 years.

Embedded use cases including ARM Cortex-M and AVR support seems to be in the focus on the Rust 2018 roadmap: "We want embedded programming to reach first-class status this year." https://blog.rust-lang.org/2018/03/12/roadmap.html

ARM (thumb 2, Cortex M0-M4) is by far the most important target. Second is cores like Cortex A7 and A53.

I think AVR is pretty minor outside hobbyist circles. After ARM support, I'd rather first see MSP430 (amazing for low power), some FPGA softcores (like NIOS, microblaze, etc., common in low volume, industrial & medical devices) and even 8051 (these buggers seem to still be everywhere, but I guess targeting Rust for this arch is the ultimate challenge.).

I guess RISC-V would be cool as well, I can see this getting more popular in the future, eating ARM market share.

MSP430 already works, as far as I know. RISC-V is there too.

> Only devices with an OS, like a RaspberryPi, are properly supported by Rust at this point.

You must be confused, as this isn't true. https://www.tockos.org/ is even an OS written in Rust for ARM boards.

ARM Cortex stuff already works, AVR is coming.

Do you see any reason why it won't eventually do so?

Even if it is objectively better in every way (not saying it is, only going for the most extreme end point for purposes of making a point) it is not guaranteed to replace C. Too many people have invested too much time mastering C and learning to deal with its quirks to simply give it up.

There may come a day where basically 0 new C projects are made. I do not think that will be in my lifetime. And I say that as someone with near 0 investment in the language but intends to get more serious about learning rust in the near future.

Until we replace UNIX derived OSes and throw away POSIX compatibility that day will never come.

We've already thrown away POSIX compatibility. Linux isn't POSIX. Mac OS X isn't POSIX. Windows isn't POSIX. POSIX only continues to exist in varying degrees at different times.

I mean it might eventually happen but currently hardware support, vendor support, also all major Unix operating system implementations are written in C and the maintainers don't look like they will change anytime soon. Also C has lot's of inertia behind it.

The other question is whether there actually is a reason that it will eventually do so. I personally have my doubts. C has found that perfect sweet spot between not getting in the way of doing things and running on almost any platform. Rust still has to achieve that status and judging from other competitors like C++/D it seems hard to get to that point. Heck, even Java was advertised as systems language on Java CPUs for a while.

Well, Java is the systems language on Android that has full exposure to what app developers can actually use.

NDK is quite constrained, mostly as a means to implement Java native methods.

On Android Things they went one step further and the user space drivers are written in Java.

With Treble it is also possible to write drivers in Java thanks to the new micro-kernel like architecture.

> The other question is whether there actually is a reason that it will eventually do so. I personally have my doubts. C has found that perfect sweet spot between not getting in the way of doing things and running on almost any platform.

That is the question. The way I see it, Rust's attractiveness to C developers goes up considerably the more accountable they are for the code they ship. If IoT and embedded devices start having repercussions for out of date, exploitable firmware/services, either through public opinion, legal or legislative means, making a switch to a language that provides more guarantees starts to look a lot more feasible and attractive to a lot of C die-hards.

I think more importantly Rust has to clearly demonstrate that it really is better for projects that use C currently. I think the failure of wider adoption of D is a good case study.

> I think more importantly Rust has to clearly demonstrate that it really is better for projects that use C currently.

I halfway agree. More evidence is always welcome, but the nature of that evidence will almost always be subjective, and I'm not sure a lot of language adherents even care all that much when the evidence is objective. So more is better, but "clearly demonstrate" may be pie in the sky thinking.

> I think the failure of wider adoption of D is a good case study.

I always considered D interesting, but not worth the effort for the gains it offered. A more ergonomic C/C++ is nice, but ergonomics just steer you the right way, they're a far cry from preventing a while class of errors. A GC does offer some help in that direction, but comes with a clear continuous cost. Compiler level error prevention with zero cost abstractions comes across as something a bit more new and novel, and changes the cost/benefit analysis some. It's now a one-time up-front cost, with the possibility that the cost will lesson over time as you become more accustomed to the language.

From an outsider's perspective, Nim was actually a lot more attractive than D as a replacement for C/C++. The cost seems almost negligible since it compiles to C, which makes the benefit fairly good (if overall of less magnitude than I perceive the benefit of Rust to be).

"I halfway agree. More evidence is always welcome, but the nature of that evidence will almost always be subjective, and I'm not sure a lot of language adherents even care all that much when the evidence is objective. So more is better, but "clearly demonstrate" may be pie in the sky thinking."

One way to clearly demonstrate this in my opinion would be big projects that are implemented in Rust. I remember when Java came up there were plenty of people saying that it would totally replace C/C++ but you just had to look around to see that not much big software was written with it. Same for C#. Once we see something widely used like git, a big database, a web browser or similar written in Rust then we know Rust has arrived.

In that respect, I think Servo and Firefox is the big project. Unfortunately (or fortunately, depending on the direction you look at it from), due to Mozilla's putting good engineering principles ahead of marketing and pulling in proven pieces of Rust code from Servo piecemeal, most people will likely never know. The best we can hope for is not that it's just a win, but that it's such a large, obvious win that when people go "How is Firefox so awesome"? the answer is Rust. That's a tall order to fill. :/

" putting good engineering principles ahead of marketing and pulling in proven pieces of Rust code from Servo piecemeal, most people will likely never know"

That's really not a good strategy. At work I can't just start using Rust without justification but if I can point at large projects being written in Rust suddenly has credibility.

For marketing a language? No, unless you ruthlessly capitalize on every small change.

For iterating on large changes to a stable secure web browser used by many millions? It seems to have worked well for them so far.

The problem is that if Rust doesn't establish itself in the broader market then the effort of developing it and adding to the browser is pretty questionable. You generally don't want code in a language nobody else uses.

I hope rust will make it but it's very hard to establish a language long-term.

It's still too early. There's tons of good reasons to write C code today for many projects. Furthermore, there's so much C code out there that even if nobody wrote a single new line of C today, it'd be decades before it would go away.

It's really about growing the pie rather than replacement anyway, in my opinion.

>even if nobody wrote a single new line of C today, it'd be decades before it would go away.

But then we can get sweet sweet COBOL level salaries in 40 years.

Although, a lot of us are working towards replacement of C in a lot of areas. Being able to say you've written something in Rust is one thing, but having the whole stack Rust all the way down is something else. Not to mention, it's fairly simple to create C bindings from Rust libraries using Cargo workspaces and cbindgen.

Reply on news.ycombinator.com