Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Matt Godbolt sold me on Rust by showing me C++

collabora.com

Post reply on HN
Print view View original

11–20 of 675 posts

Re: Matt Godbolt sold me on Rust by showing me C++

#11

Post by cogman10 »

markus_zhang wrote: post #3

What if we have a C that removes the quirks without adding too much brain drain? So no implicit type conversions, safer strings, etc.

I've seen this concept tried a few times (For example, MS tried it with Managed C++). The inevitable problem you run into is any such language isn't C++. Because of that, you end up needing to ask, "why pick this unpopular half C/C++ implementation and not Rust/go/D/Java/python/common lisp/haskell."

A big hard to solve problem is you are likely using a C because of the ecosystem and/or the performance characteristics. Because of the C header/macro situation that becomes just a huge headache. All the sudden you can't bring in, say, boost because the header uses the quirks excluded from your smaller C language.

Re: Matt Godbolt sold me on Rust by showing me C++

#12

Post by jasonjmcghee »

dvratil wrote: post #8

The one thing that sold me on Rust (going from C++) was that there is a single way errors are propagated: the Result type. No need to bother with exceptions, functions returning bool, functions returning 0 on success, functions returning 0 on error, functions returning -1 on error, functions returning negative errno on error, functions taking optional pointer to bool to indicate error (optionally), functions taking r…

unfortunately it's not so simple. that's the convention. depending on the library you're using it might be a special type of Error, or special type of Result, something needs to be transformed, `?` might not work in that case (unless you transform/map it), etc.

I like rust, but its not as clean in practice, as you describe

Re: Matt Godbolt sold me on Rust by showing me C++

#13

Post by mamcx »

markus_zhang wrote: post #3

What if we have a C that removes the quirks without adding too much brain drain? So no implicit type conversions, safer strings, etc.

If you can live without much of the ecosystem (specially if has async) there is way to write rust very simple.

The core of Rust is actually very simple: Struct, Enum, Functions, Traits.

Re: Matt Godbolt sold me on Rust by showing me C++

#15

Post by dvt »

dvratil wrote: post #8

The one thing that sold me on Rust (going from C++) was that there is a single way errors are propagated: the Result type. No need to bother with exceptions, functions returning bool, functions returning 0 on success, functions returning 0 on error, functions returning -1 on error, functions returning negative errno on error, functions taking optional pointer to bool to indicate error (optionally), functions taking r…

Maybe contrarian, but imo the `Result` type, while kind of nice, still suffers from plenty of annoyances, including sometimes not working with the (manpages-approved) `dyn Error`, sometimes having to `into()` weird library errors that don't propagate properly, or worse: `map_err()` them; I mean, at this point, the `anyhow` crate is basically mandatory from an ergonomics standpoint in every Rust project I start. Also, `?` doesn't work in closures, etc.

So, while this is an improvement over C++ (and that is not saying much at all), it's still implemented in a pretty clumsy way.

Re: Matt Godbolt sold me on Rust by showing me C++

#17

Post by GardenLetter27 »

alexchamberlain wrote: post #6
markus_zhang wrote: post #3

What if we have a C that removes the quirks without adding too much brain drain? So no implicit type conversions, safer strings, etc.

I'm inferring that you think Rust adds too much brain drain? If so, what?

The borrow checker rejects loads of sound programs - just read https://rust-unofficial.github.io/too-many-lists/

Aliasing rules can also be problematic in some circumstances (but also beneficial for compiler optimisations).

And the orphan rule is also quite restrictive for adapting imported types, if you're coming from an interpreted language.

https://loglog.games/blog/leaving-rust-gamedev/ sums up the main issues nicely tbh.

Re: Matt Godbolt sold me on Rust by showing me C++

#18

Post by titzer »

writebetterc wrote: post #4

Yes, Rust is better. Implicit numeric conversion is terrible. However, don't use atoi if you're writing C++ :-). The STL has conversion functions that will throw, so separate problem.

> Implicit numeric conversion is terrible.

It's bad if it alters values (e.g. rounding). Promotion from one number representation to another (as long as it preserves values) isn't bad. This is trickier than it might seem, but Virgil has a good take on this (https://github.com/titzer/virgil/blob/master/doc/tutorial/Nu...). Essentially, it only implicitly promotes values in ways that don't lose numeric information and thus are always reversible.

In the example, Virgil won't let you pass "1000.00" to an integer argument, but will let you pass "100" to the double argument.

Re: Matt Godbolt sold me on Rust by showing me C++

#19

Post by _mlbt »

markus_zhang wrote: post #3

What if we have a C that removes the quirks without adding too much brain drain? So no implicit type conversions, safer strings, etc.

Swift is really great these days and supports Windows and Linux. It almost feels like a scripting language other than the compile time of course.

Re: Matt Godbolt sold me on Rust by showing me C++

#20

Post by koakuma-chan »

jasonjmcghee wrote: post #12
dvratil wrote: post #8

The one thing that sold me on Rust (going from C++) was that there is a single way errors are propagated: the Result type. No need to bother with exceptions, functions returning bool, functions returning 0 on success, functions returning 0 on error, functions returning -1 on error, functions returning negative errno on error, functions taking optional pointer to bool to indicate error (optionally), functions taking r…

unfortunately it's not so simple. that's the convention. depending on the library you're using it might be a special type of Error, or special type of Result, something needs to be transformed, `?` might not work in that case (unless you transform/map it), etc. I like rust, but its not as clean in practice, as you describe

You can use anyhow::Result, and the ? will work for any Error.
Post reply on HN