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

241–250 of 675 posts

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

#241

Post by tialaramex »

pdimitar wrote: post #114
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?

Don't know about your parent poster but I didn't take it 100% literally. Obviously if there's no memory left then you crash; the kernel would likely murder your program half a second later anyway. But for arithmetics Rust has non-aborting bound checking API, if my memory serves. And that's what I'm trying hard to do in my Rust code f.ex. don't frivolously use `unwrap` or `expect`, ever. And just generally try hard to…

Rust provides a default integer of each common size and signedness, for which overflow is prohibited [but this prohibition may not be enforced in release compiled binaries depending on your chosen settings for the compiler, in this case what happens is not promised but today it will wrap - it's wrong to write code which does this on purpose - see the wrapping types below if you want that - but it won't cause UB if you do it anyway]

Rust also provides Wrapping and Saturating wrapper types for these integers, which wrap (255 + 1 == 0) or saturate (255 + 1 == 255). Depending on your CPU either or both of these might just be "how the computer works anyway" and will accordingly be very fast. Neither of them is how humans normally think about arithmetic.

Furthermore, Rust also provides operations which do all of the above, as well as the more fundamental "with carry" type operations where you get two results from the operation and must write your algorithms accordingly, and explicitly fallible operations where if you would overflow your operation reports that it did not succeed.

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

#242

Post by JBits »

steveklabnik wrote: post #231
smj-edison wrote: post #184

Earlier quoted context omitted.

Ah, my bad, I guess I've been misunderstanding how the Allocator proposal works all along (I thought it was only for 'static allocators, this actually makes a lot more sense!). I guess all that to say, I agree then that this should've been in std from day one.

The problem is, everything should have been there since day 1. It’s still unclear which API Rust should end up with, even today, which is why it isn’t stable yet.

Looking forward to the API when it's stabilised. Have there been any updates on the progress of allocators of this general area of Rust over the past year?

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

#243

Post by steveklabnik »

JBits wrote: post #242
steveklabnik wrote: post #231

Earlier quoted context omitted.

The problem is, everything should have been there since day 1. It’s still unclear which API Rust should end up with, even today, which is why it isn’t stable yet.

Looking forward to the API when it's stabilised. Have there been any updates on the progress of allocators of this general area of Rust over the past year?

I haven’t paid that close of attention, but there have been two major APIs that people seem to be deciding between. We’ll see.

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

#244

Post by jpc0 »

rq1 wrote: post #154
jpc0 wrote: post #88

Earlier quoted context omitted.

Do you really want width and height or do you actually want dimensions or size? Same with transfer, maybe you wanted a transaction that gets executed. Worst case here use a builder with explicit function names.

I don’t really understand your point there. Sound type systems are equivalent to proof systems. You can use them to design data structures where their mere eventual existence guarantee the coherence and validity of your program’s state. The basic example is “Fin n” that carries at compile time the proof that you made the necessary bounds checks at runtime or by construction that you never exceeded some bound. Some la…

My point is a Width type is usually not the sound type you are looking for. What probably wanted was a size type which is width and height. Or a dimensions type which is width and height. The problem was maybe not two arguments being confused but in reality a single thing with two elements…

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

#245

Post by jpc0 »

noelnh wrote: post #199
jpc0 wrote: post #79

Earlier quoted context omitted.

I don’t disagree. Rust learnt a ton from C++. I have my gripes with rust, more it’s ecosystem and community that the core language though. I won’t ever say it’s a worse language than C++.

Could you elaborate on those points, I'm genuinely curious? So far, I have found the Rust community to be immensely helpful, much more so than I experienced the C++ community. Granted, that's quite some time ago and might be at least partially caused by me asking fewer downright idiotic questions. But still, I'm interested in hearing about your experiences.

Rust libraries tend to over abstract and then need large refactors when those abstractions fall apart. When I’ve complained about it in the past I’ve been met with “You would need the abstraction eventually”. Maybe, but I’m also capable of building it myself it it gets to that.

Maybe that’s more of a bias with rust media stuff, seems to be going deeper into that rabbit hole though.

The community was at least, may still be, very sensitive to rust being criticised. I genuinely brought an example of a provably correct piece of code that the borrow checker wouldn’t accept, interior mutability problem. I was I should build a massive abstraction to avoid the problem and that I’m holding it wrong… Put me off the language for a few years, it shouldn’t have, I should have just ignored the people and continued on but we all get older and learn things.

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

#246

Post by nextaccountic »

tcfhgj wrote: post #91
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…

would you consider panics acceptable when you think it cannot panic in practice? e.g. unwraping/expecting a value for a key in a map when you inserted that value before and know it hasn't been removed? you could have a panic though, if you wrongly make assumptions

Obviously yes. For the same reason it's acceptable that myvec[i] panics (it will panic if i is out of bounds - but you already figured out that i is in bounds) and a / b panic for a and b integers (it will panic if b is zero, but if your code is not buggy you already tested if b is zero prior to dividing right?)

Panic is absolutely fine for bugs, and it's indeed what should happen when code is buggy. That's because buggy code can make absolutely no guarantees on whether it is okay to continue (arbitrary data structures may be corrupted for instance)

Indeed it's hard to "treat an error" when the error means code is buggy. Because you can rarely do anything meaningful about that.

This is of course a problem for code that can't be interrupted.. which include the Linux kernel (they note the bug, but continue anyway) and embedded systems.

Note that if panic=unwind you have the opportunity to catch the panic. This is usually done by systems that process multiple unrelated requests in the same program: in this case it's okay if only one such request will be aborted (in HTTP, it would return a 5xx error), provided you manually verify that no data structure shared by requests would possibly get corrupted. If you do one thread per request, Rust does this automatically; if you have a smaller threadpool with an async runtime, then the runtime need to catch panics for this to work.

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

#247

Post by kllrnohj »

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,…

> Rust unfortunately picked the wrong default here for the sake of convenience, along with the default of assuming a global allocator. [...] Zig for example does it right by having explicit allocators from the start

Rust picked the right default for applications that run in an OS whereas Zig picked the right default for embedded. Both are good for their respective domains, neither is good at both domains. Zig's choice is verbose and useless on a typical desktop OS, especially with overcommit, whereas Rust's choice is problematic for embedded where things just work differently.

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

#248

Post by kllrnohj »

codedokode wrote: post #103
zozbot234 wrote: post #40

Earlier quoted context omitted.

> 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 This isn't really true since Rust has panics. It would be nice to have out-of-the-box support for a "no panics" subset of Rust, which would also make it easier to properly support linear (no auto-drop) types.

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?

> Also many functions use addition and what is one supposed to do in case of overflow?

Honestly this is where you'd throw an exception. It's a shame Rust refuses to have them, they are absolutely perfect for things like this...

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

#249

Post by siev »

simpaticoder wrote: post #232
brundolf wrote: post #219

Earlier quoted context omitted.

> Isn't this a runtime problem and not a compile-time problem? buy() or sell() is going to be called with dynamic parameters at runtime, in general. Yes, but the strength of Rust's type system means you're forced to handle those bad dynamic values up front (or get a crash, if you don't). That means the rest of your code can rest safe, knowing exactly what it's working with. You can see this in OP's parsing example, b…

What if the valid input for quantity must be greater than 0? A reasonable constraint, I think. The OP's example is contrived to line up with Rust's built-in types, and ignores the general problem.

Rust also has the standard NonZero type for that use case.

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

#250

Post by almostgotcaught »

mountainriver wrote: post #223
thrwyexecbrain wrote: post #132

The C++ code I write these days is actually pretty similar to Rust: everything is explicit, lots of strong types, very simple and clear lifetimes (arenas, pools), non-owning handles instead of pointers. The only difference in practice is that the build systems are different and that the Rust compiler is more helpful (both in catching bugs and reporting errors). Neither a huge deal if you have a proper build and testi…

I still find it basically impossible to get started with a C++ project. I tried again recently for a proxy I was writing thinking surely things have evolved at this point. Every single package manager couldn’t handle my very basic and very popular dependencies. I mean I tried every single one. This is completely insane to me. Not to mention just figuring out how to build it after that which was a massive headache and…

> Every single package manager couldn’t handle my very basic and very popular dependencies

Well there's your problem - no serious project uses one.

> I’m convinced it’s a bunch of masochists

People use cpp because it's a mature language with mature tooling and an enormous number of mature libraries. Same exact reason anyone uses any language for serious work.

Post reply on HN