Hacker News Reader

Comment by bluejekyll | Hacker News Reader

If we’re talking about switching to a new language from C, why only go almost safe with “modern” C++ and not all the way to fully safe Rust?

I’m not trying to be snarky, but the thread was about Rust as an improvement to C and you just threw C++ into the mix... which isn’t as safe.

View on HN

Don't forget about SaferCPlusPlus[1]. Much safer than conventional modern C++. Also (optionally) uses scope lifetimes to prevent use-after-free. (Not yet fully compiler enforced like Rust, but hopefully that'll be coming at some point.) There is a translation helper tool[2] that, at this point, can automatically replace native C array and pointer iterator declarations with macros that make them memory safe (bounds and use-after-free) when compiled in C++ mode.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus/blob/master...

[2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

Actually the thread was about C and someone threw Rust into the mix, as is typical.

One could go to almost safe C++ because C code compiles with a minimum amount of changes and turning on compiler warnings, using vector, string and smart pointers already gives a massive saftety improvement, without a complete rewrite in a language that's quite different from C, like Rust is.

Smaller costs and still significant benefits in other words.

> Actually the thread was about C and someone threw Rust into the mix, as is typical.

I was referring to the thread that started a conversation about pointers and safety in Rust, not to the general post.

You are correct that C and Rust require some more bridging between the languages, but C++ also requires this when going from objects to C datatypes and vice versa. Mostly you save a little bit on the header definitions, but even there, the headers are generally #ifdef'ed to almost illegibility. With Rust's bindgen tool, getting C headers into Rust is actually quite easy: https://rust-lang-nursery.github.io/rust-bindgen/

Ok, so then we could agree that the more general general topic is safety, so different options could be discussed: D, Ada, Rust, C++, etc.

The bindgen tool allows integrating C code with Rust code, which means than an existing C code base can be replaced with Rust step by step.

A C code base can be compiled with some modifications as C++ and then it can be slowly refactored to use safer C++ idioms. In this case the safety improvements will be available much faster, even if the resulting code base won't be as safe as a Rust code base. The culture shock will also not be as large for the C programmers.

These are non-negligible benefits, and a big reason why C code bases are moving to C++.

Staying a little more focused, I have reasons for none of the languages you mention, but in terms of ease of integration of C and Rust, here’s one real world example: https://people.gnome.org/~federico/blog/librsvg-build-infras...

Which recently passed a milestone of having less C than Rust: https://www.reddit.com/r/rust/comments/8ofa0w/librsvg_has_no...

At this point I personally find it much easier to move C to Rust than C++, and end up with a much safer codebase.

There are fewer safety guarantees even in modern C++, but there are times where Rust’s safety requirements do require slower code. Depending on why you were writing C, C++ can be the better choice, even though it can be harder. Where I stand, my biggest reason for not yet having used Rust for any projects is that the overhead for learning it outweighs what seems like a negligible gain for me when C++ already meets my needs.

That is my approach, because C++ still fits better my workflow than Rust, and C++17 is already quite sweet spot.

However that doesn't prevent copy-paste C code from team mates, only languages that aren't C compatible do provide such additional safety.

I like Rust, but based on the difficulty I’ve had writing even the most basic of bare metal software in it, it will be like 10 or 15 years before the community and the tooling are ready to do kernel or device driver work in Rust. C may have a lot of foot guns but it’s really easy to learn and use.

Rust took me longer to learn than most languages, I'll grant you, but I'd say after 3-4 weeks I was writing safer code than anything I ever wrote in C.

Not claiming to be an expert in C, but I paid my share of blood and tears with it, and all I can say is that it's worth the effort to learn Rust for the huge guarantees the language gives you in the same contexts as C.

If you're interested in baremetal, there are a number of tutorials out there, all focused on different things. I really love the TockOS tutorials, they are really awesome for getting across some of the different benefits at different levels: https://github.com/tock/tock/tree/master/doc/courses/rustcon...

And then more raw OS stuff: https://os.phil-opp.com/

Rust is already at a good level when you are writing low level OS infrastructure code and CLI utilities.

For GUI software or GPGPU development, it still needs to mature a bit more.

Yes, though I think patterns are starting to emerge that will start taking hold. For example: https://raphlinus.github.io/personal/2018/05/08/ecs-ui.html

I mostly think this is a gap in common libraries at the moment and decent coding practices. We’ll see what happens with all of that.

Personally I’m more focused on web-backends, micro-services, and DNS, so GUIs don’t generally present problems for me.

Thanks for the link, it is quite interesting read.

I’m gonna have to disagree with you there: once you turn off std, you’re off the map. Building a syscall handler for example, or implementing VM or even a simple bootloader is non-trivial and has taken me like 10x the time it would in C. If we want rust for device drivers, we need a more sane method of implementing std below userspace. The fact is that C is dead simple and currently contorts more easily. The cognitive load is two orders of magnitude less. Until Rust is this easy, we will use C at work.

Given that I loved doing systems programming in Turbo Pascal, Oberon, avoid to use C as much as possible, focus on Java, C# and C++, I do love a bit of straitjacket in name of security.

I do agree though that it might need still some ergonomic improvements to earn the hearts of other developers that don't share this opinion.

You must be a hell of a lot smarter than me: I’ve been hacking rust on the side and it’s taking me like 10x as long at least to do fairly simple things. It’s like the crushing burden of choice of C++ paired with the strictness of Haskell. And I’m not sure it’s that much safer than C for low level stuff that requires you to use unsafe anyhow. I’m going to take my kernel project through to programming the MMU, and re-evaluate but it’s slow going man. None of my coworkers would have the patience for this slog.

I hope that you’re using some of the many community resources to help learn. I personally don’t have time to join the IRC channels, but those are great for point in time help, the users forum, stackoverflow, and reddit are all good resources too.

Many of the Rust users have all gone through similar learning hurdles, and are very helpful when asked. Often there are tricks that newcomers are unaware of for working around some of the Rust idiosyncrasies. I encourage you to reach out.

The official community page has a lot of resources: https://www.rust-lang.org/en-US/community.html

Somewhat surprisingly, you can relatively quickly move from the world of raw pointers and direct hardware interaction to safe abstractions (or at least single-point-of-unsafety, typically on construction, requiring that a pointer points to the right memory-mapped registers, etc). The series written by Phil Opp linked above does a great job of demonstrating this.

Reply on news.ycombinator.com