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

231–240 of 675 posts

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

#231

Post by steveklabnik »

smj-edison wrote: post #184
Arnavion wrote: post #172

Earlier quoted context omitted.

Explicit allocators do work with Rust, as evidenced by them already working for libstd's types, as I said. The mistake was to not have them from day one which has caused most code to assume GlobalAlloc. As long as the type is generic on the allocator, the lifetimes of the allocator don't appear in the type. So eg if your allocator is using a stack array in main then your allocator happens to be backed by `&'a [MaybeU…

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.

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

#232

Post by simpaticoder »

brundolf wrote: post #219
simpaticoder wrote: post #213

I don't get it. 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. That is, calls with concrete values are NOT going to be hard-coded into your program. I would write the function to assert() invariants within the function, and avoid chasing compile-time safety entirely. If parameter order was a concern, then I'd modify th…

> 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.

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

#233

Post by bigstrat2003 »

atemerev wrote: post #183
bigstrat2003 wrote: post #99

Earlier quoted context omitted.

Why not just use pointers? Rust has them, they aren't evil or anything. If you need to make a data structure that isn't feasible with references due to the borrow checker (such as a linked list), there's absolutely nothing wrong with using pointers.

And it will look like this: https://rust-unofficial.github.io/too-many-lists/sixth-final... (filled with boilerplate, strange Rust idioms, borrow_unchecked, phantomdata, and you still have to manage lifetimes annotations).

And? I don't really see the issue. It works, it is sound, and it has a nice clean interface for safe code to use. That's all I really ask for. Lots of useful things in programming are quite gnarly under the hood, but that doesn't mean those things aren't worth using.

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

#234

Post by Maxatar »

Etheryte wrote: post #92
kasajian wrote: post #84

This seems a big silly. This is not a language issue. You can have a C++ library that does exactly all the things being shown here so that the application developer doesn't worry about. There would no C++ language features missing that would accomplish what you're able to do on the Rust side. So is this really a language comparison, or what libraries are available for each language platform? If the latter, that's fin…

Just like language shapes the way we think and talk about things, programming languages shape both what libraries are written and how. You could write anything in anything so long as it's Turing complete, but in real life we see clearly that certain design decisions at the language level either advantage or disadvantage certain types of solutions. Everyone could in theory write C without any memory issues, but we all…

The Sapir Whorf hypothesis has long been debunked:

https://en.m.wikipedia.org/wiki/Linguistic_relativity

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

#235

Post by bigstrat2003 »

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.

The Rust community is helpful... but also quite political and extremely hostile to anyone who doesn't share those politics. Even something as anodyne as saying "let's keep politics out of technical discussion" is frequently met with hostility (because many community members believe that tech is inherently political and that trying to keep politics out is really just a bad faith attempt to frame things in terms of the requester's preferred politics). It's also full of drama in a way that other communities online simply aren't. For example, the drama that happened when the guy behind thephd.dev got invited to give the keynote at rustconf, then his talk was downgraded from the keynote - everyone involved in that mess (including other bloggers who weighed in) came off as immature and not someone you would ever want to work with.

I like the Rust language quite a bit. I find the Rust community to be one of the most toxic places in the entire tech business. Your mileage may vary and that's fine of course - but plenty of people want to stay far away from a community that acts like the Rust community does.

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

#236

Post by zaphar »

ryandrake wrote: post #157
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…

Error handling and propagation is one of those things I found the most irritating and struggled[1] with the most as I learned Rust, and to be honest, I'm still not sure I understand or like Rust's way. Decades of C++ and Python has strongly biased me towards the try/except pattern. 1: https://news.ycombinator.com/item?id=41543183

Counterpoint: Decades of C++/Python/Java/... has strongly biased me against the try/except pattern.

It's obviously subjective in many ways. However, what I dislike the most is that try/except hides the error path from me when I'm reading code. Decades of trying to figure out why that stacktrace is happening in production suddenly has given me a strong dislike for that path being hidden from me when I'm writing my code.

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

#237

Post by zaphar »

kanbankaren wrote: post #227
mb7733 wrote: post #200

Earlier quoted context omitted.

Isn't that their point though? They don't have 30 years of C/C++ experience and a workplace with very strict guidelines. They are just trying to write some code, and they run into trouble on C++'s sharper edges.

> with very strict guidelines. Low level languages always came with a set of usage guidelines. Either you make the language safe for anyone that they can't shoot themselves in the foot and end up sacrificing performance, or provide guidelines on how to use it while retaining the ability to extract maximum performance from the hardware. C/C++ shouldn't be approached like programming in Javascript/Python/Perl.

And yet, Rust doesn't sacrifice performance and it has all kinds of those guardrails.

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

#238

Post by BlueTemplar »

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.

For where I am concerned, I don't want to have anything to do with the kind of developers that still think that it's acceptable to use Github, VS Code, or Discord in 2025 in a professional setting, much worse teach a new generation of developers to use them : that's like being a doctor and giving out cigarettes to children.

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

#239

Post by CJefferson »

jchw wrote: post #228
CJefferson wrote: post #222

Earlier quoted context omitted.

You could assert. You could throw. I can’t understand how, this modern age where so many programs end up getting hacked, that introducing more UB seems like a good idea. This is one odd the major reasons I switched to rust, just to escape spending my whole life worrying about bugs caused by UB.

Assertions are debug-only. Exceptions are usually not guaranteed to be available and much of the standard library doesn't require them. You could std::abort, and that's about it. I think the issue is that this just isn't particularly good either. If you do that, then you can't catch it like an exception, but you also can't statically verify that it won't happen. C++ needs less of both undefined behavior and runtime e…

I agree these things would be better, but I don’t understand how anyone can think UB is better than abort.

(Going to moan for a bit, and I realise you aren’t responsible for the C++ standards mess!)

I have been hearing for about… 20 years now that UB gives compilers and tools the freedom to produce any error catching they like, but all it seems to have done in the main is give them the freedom to produce hard to debug crash code.

You can of course usually turn on some kind of “debug mode” in some compilers, but why not just enforce that as standard? Compilers would still be free to add a “standards non-compliant” go fast mode if they like.

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

#240

Post by tialaramex »

PhilipRoman wrote: post #136
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?

>what are they supposed to do when there is no memory left Well on Linux they are apparently supposed to return memory anyway and at some point in the future possibly SEGV your process when you happen to dereference some unrelated pointer.

You can tell Linux that you don't want overcommit. You will probably discover that you're now even more miserable and change it back, but it's an option.
Post reply on HN