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

361–370 of 675 posts

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

#361

Post by tsimionescu »

monkeyelite wrote: post #352
kelnos wrote: post #67

Earlier quoted context omitted.

I wish more people (and crate authors) would treat panic!() as it really should be treated: only for absolutely unrecoverable errors that indicate that some sort of state is corrupted and that continuing wouldn't be safe from a data- or program-integrity perspective. Even then, though, I do see a need to catch panics in some situations: if I'm writing some sort of API or web service, and there's some inconsistency in…

> I probably really would prefer only that request to abort, not for the entire process to be torn down, This is a sign you are writing an operating system instead of using one. Your web server should be handling requests from a pool of processes - so that you get real memory isolation and can crash when there is a problem.

Even if you used a pool of processes, that's still not one process per request, and you still don't want one request crashing to tear down unrelated requests.

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

#362

Post by imtringued »

Arnavion wrote: post #121
codedokode wrote: post #103

Earlier quoted context omitted.

It's pretty difficult to have no panics, because many functions allocate memory and what are they supposed to do when there is no memory left? Also many functions use addition and what is one supposed to do in case of overflow?

>many functions allocate memory and what are they supposed to do when there is no memory left? Return an AllocationError. Rust unfortunately picked the wrong default here for the sake of convenience, along with the default of assuming a global allocator. It's now trying to add in explicit allocators and allocation failure handling (A:Allocator type param) at the cost of splitting the ecosystem (all third-party code,…

>Return an AllocationError. Rust unfortunately picked the wrong default here for the sake of convenience, along with the default of assuming a global allocator. It's now trying to add in explicit allocators and allocation failure handling

Going from panic to panic free in Rust is as simple as choosing 'function' vs 'try_function'. The actual mistakes in Rust were the ones where the non-try version should have produced a panic by default. Adding Box::try_new next to Box::new is easy.

There are only two major applications of panic free code in Rust: critical sections inside mutexes and unsafe code (because panic safety is harder to write than panic free code). In almost every other case it is far more fruitful to use fuzzing and model checking to explicitly look for panics.

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

#363

Post by monkeyelite »

bsder wrote: post #192
codedokode wrote: post #110

Earlier quoted context omitted.

When there are 3-4 parameters it is too much trouble to write the names.

> When there are 3-4 parameters it is too much trouble to write the names. Sorry, I don't agree. First, code is read far more often than written. The few seconds it takes to type out the arguments are paid again and again each time you have to read it. Second, this is one of the few things that autocomplete is really good at. Third, almost everybody configures their IDE to display the names anyway . So, you might as…

Making something longer doesn’t make it easier to read, especially in repetition.

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

#364

Post by monkeyelite »

mamcx wrote: post #13
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.

But unfortunately you will encounter async in libraries you want to use, so this approach is difficult

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

#365

Post by jeffparsons »

Ygg2 wrote: post #357
eptcyka wrote: post #318

Earlier quoted context omitted.

As per the article, Rust has benefits beyond the ones afforded by the borrow checker.

Sure, but it is pragmatic in other ways as well :) It takes ADT, but not function currying, and so on.

I've occasionally wondered about the lack of currying in Rust; it feels like something that can be done mechanically at compile time, so why not support it? Perhaps to do it cleanly (without more magical privileged functions in core) would require variadic generics?

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

#367

Post by renox »

Arnavion wrote: post #208
b5n wrote: post #146

Earlier quoted context omitted.

There's a bit more nuance here than 'basic errors', and modern c compilers offer a lot of options _if you need to use them_. I appreciate that there are guardrails in a tool like rust, I also appreciate that sharp tools like c exist, they both have advantages.

To be clear, the only difference between Rust and C here is whether the conversion happens by default or not. Rust doesn't do the conversion by default but will let you do it if you want to, with `as`. There are also more type-safe conversion methods that perform a more focused conversion. Eg a widening conversion from i8 -> i16 can be done with .into(), a narrowing conversion from i16 -> i8 can be done with .try_int…

That's funny, if memory serves 'as' should be avoided in Rust and other casts should be used. That's a Rust wart which cannot be fixed..

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

#368

Post by timschmidt »

pjmlp wrote: post #360
timschmidt wrote: post #329

Earlier quoted context omitted.

36 years is counting from the first CFront release. Counting the same way for Rust, it's been around since 2006. It's got almost 20 years under it's belt already. edit: what's with people downvoting a straight fact?

Because it is counting since CFront 2.0, the first official release with industry use in UNIX systems. So that would be Rust 1.0, released in 2015, not 2006, putting it down to a decade. And the point still stands when looking at any long enough ecosystem still in use, with strong backwards compatibility, not only the language, the whole ecosystem, eventually editions alone won't make it, and just like those language…

Fair enough. I can cop to getting the CFront date wrong. Still, a decade since 1.0 is non-trivial.

> eventually editions alone won't make it, and just like those languages, Rust will gain its own warts.

That's possible. Though C++ hasn't had editions, or the HLIR / MIR separation, the increased strictness, wonderful tooling, or the benefit of learning from the mistakes made with C++. Noting that, it seems reasonable to expect Rust to collect less cruft and paint itself into fewer corners over a similar period of time. Since C++ has been going for 36 years, it seems Rust will outlive me. Past that, I'm not sure I care.

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

#369

Post by d_tr »

timschmidt wrote: post #329
pjmlp wrote: post #278

Earlier quoted context omitted.

Just give Rust 36 years of field use, to see how it goes.

36 years is counting from the first CFront release. Counting the same way for Rust, it's been around since 2006. It's got almost 20 years under it's belt already. edit: what's with people downvoting a straight fact?

Rust 0.1, the first public release, came out in January 2012. CFront 1.0, the first commercial release, came out in 1985.

The public existence of Rust is 13 years, during which computing has not changed that much to be honest. Now compare this to the prehistory that is 1985, when CFront came out, already made for backwards compatibility with C.

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

#370

Post by jk3000 »

TinkersW wrote: post #341

Dunno about this, the example C++ code is so obviously bad that I had no desire to watch the video. Creating strong types for currency seems like common sense, and isn't hard to do. Even the Rust code shouldn't be using basic types.

Somehow this is the pattern when comparing C++ to Rust: write outrageously bad C++ in the first place, then complain about it.
Post reply on HN