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

What it feels like when Rust saves your bacon

smallcultfollowing.com

Post reply on HN
Print view View original

61–70 of 192 posts

Re: What it feels like when Rust saves your bacon

#61

Post by sitkack »

sgift wrote: post #54
kjksf wrote: post #18

Earlier quoted context omitted.

The thing they rewrote also worked great in production. And fuzzing originated in C / C++ tools and is available for them as well, probably more diverse and mature than what is available in Rust. The point you did ignore was: Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing. Which Rust evangelists find difficult to acknowledge b…

> The point you did ignore was: Rust is being sold as magically making software safe and people selling that completely ignore the fact that logical bugs are also a thing. There are straw men and then there are straw man armies. This is probably the biggest one I've seen yet.

Ohh, I got one. Rust is less secure than C++ because it causes people to be overconfident in its security properties. The sharp edges of C++ are a feature that cause people to focus on correctness, not just get it for free.

Re: What it feels like when Rust saves your bacon

#62

Post by proto_lambda »

dijit wrote: post #58
axilmar wrote: post #56

Rust is undoubtedly a step forward in correctness, but boy, the article's code is so thick that for me, that I am a C++ programmer, is almost unreadable, especially for a quick reading... I skipped all the code and only read the text. I got to the point where it mentions that the language prevented them from storing a pointer to a stack object in a heap object, and that's really great, but boy oh boy, the code presen…

For whatever it’s worth: I think it’s harder to learn rust as a C++ programmer than it is for a new programmer. Reason being that you have to unlearn your paradigm before you’re able to learn the new paradigm; and it’s made slightly worse by giving the appearance of similarity (since certain concepts map directly, like flow control and loops).

One big hurdle for C++ programmers learning Rust that I've seen time and time again in various community support channels is fixing their trust issues with the compiler. They are so used to compiler output being useless or worse than useless, they are unable to take advantage of rustc's stellar diagnostics (which frequently tell you exactly what you need to change to make things work) until they force themselves to actually read and internalise them.

Once they realize that the tooling is actually working _with_ them, not _against_ them, they start to pick things up much quicker.

Re: What it feels like when Rust saves your bacon

#63

Post by BiteCode_dev »

mejutoco wrote: post #60
BiteCode_dev wrote: post #52

Earlier quoted context omitted.

And hence the general recommendation of having a single direction in your input/render cycle: - wait for input - a dispatcher take any input and turn it into a queue of model update actions - pop queue to perform latest model updates. - trigger a full tree rendering, passing the new model - start again So: - the model is a dumb static data structure - the dispatcher is the responsible for model updates and is a singl…

> - trigger a full tree rendering, passing the new model I agree the Elm model makes it easy to reason about it. Just because we pass "the state of the world" each time instead of mutating it, does not mean that we need a full tree rendering. That is an implementation detail. We can update just the relevant part. If we think of it mostly as pure functions a lot of it is easier to memoize and — for same input — it is…

That's what I mean by hard to optimize. Memoization is hard to get right, because if you compare only by value, it can be slow, but if you compare by identity, the cache can take a lot of memory.

And of course, forcing a purely immutable model comes with its own unique challenges.

Re: What it feels like when Rust saves your bacon

#64

Post by dgb23 »

axilmar wrote: post #56

Rust is undoubtedly a step forward in correctness, but boy, the article's code is so thick that for me, that I am a C++ programmer, is almost unreadable, especially for a quick reading... I skipped all the code and only read the text. I got to the point where it mentions that the language prevented them from storing a pointer to a stack object in a heap object, and that's really great, but boy oh boy, the code presen…

I skimmed the code and there are a ton of language features in there that you might not be super familiar with:

- pattern matching is quite expressive and ubiquitous in Rust, as in "stuff on the left" is almost always a pattern even in places that you might not expect at first

- lifetime annotations, a form of generics, are quite unique and make the code more verbose/noisy if you are not familiar with them

- Rust is expression based (a bit lispy) so you might not quite see the flow of the program as well if you are used to statement based syntax

- traits are are an important part of the language and some of the methods and method chains you see there might look arbitrary, but many of them are very common. A more experienced reader can identify many of them and see the code very differently.

- there is no syntax highlighting on the article's snippets so you already have to know how to parse them

Re: What it feels like when Rust saves your bacon

#65

Post by cyber_kinetist »

jstimpfle wrote: post #53
strictfp wrote: post #38

Earlier quoted context omitted.

I've worked in a variety of languages, and returning to a c++ project recently I do see that we spend a lot more time thinking about how to write the code in a way that avoids problems. Meaning that there's a lot more architecturing required to reach a sane state. We have a sister product written in a dynamic language, and sometimes we have identical functionality. I've noticed that when a change is discussed, the c+…

Maybe I'm wrong, but I believe that most of the architecting that you describe would be effectively what you do with regards to performance as well: Minimizing change of ownership, moving to a system with more static allocations with fewer "objects" that are linked into a variety of subsystems.

…and when you do need a large number of dynamically allocced/deallocced objects, then using indices to arrays instead of pointers. Which kinda defeats the purpose of using the Rust borrow checker…

Re: What it feels like when Rust saves your bacon

#66

Post by rob74 »

tremon wrote: post #57
rob74 wrote: post #24

Earlier quoted context omitted.

What you said, although I would have probably phrased it less harshly :) But yes, my point was that there are a lot of enthusiastic articles about how Rust can prevent "whole classes of bugs", which mostly gloss over the fact that there are other classes of bugs that it doesn't prevent. Of course this doesn't mislead experienced developers, but I'm not so sure about novices or less technically inclined people.

which mostly gloss over the fact that there are other classes of bugs that it doesn't prevent That's nothing more than a technically-dressed version of whataboutism, isn't it? Or can you show other languages that do prevent those other unnamed classes of bugs?

Er... no. I was simply saying that the many articles about how reliable Rust is and how many bugs it catches for you might lead to a false sense of safety. Nothing more, nothing less.

Re: What it feels like when Rust saves your bacon

#67

Post by strictfp »

jstimpfle wrote: post #53
strictfp wrote: post #38

Earlier quoted context omitted.

I've worked in a variety of languages, and returning to a c++ project recently I do see that we spend a lot more time thinking about how to write the code in a way that avoids problems. Meaning that there's a lot more architecturing required to reach a sane state. We have a sister product written in a dynamic language, and sometimes we have identical functionality. I've noticed that when a change is discussed, the c+…

Maybe I'm wrong, but I believe that most of the architecting that you describe would be effectively what you do with regards to performance as well: Minimizing change of ownership, moving to a system with more static allocations with fewer "objects" that are linked into a variety of subsystems.

Yes, that's true. In a sense, c++ requires good code structuring.

That's also part of why I enjoy returning to c++, the people involved know how to structure code and create clean architecture.

That said, sometimes c++ does get in the way. Creating trees or graphs can be cumbersome, and IMO it's very biased towards virtual methods to solve polymorphism.

Extending lifetimes by pooling or similar is also quite common, and is in my eyes sometimes overdoing it. If you for instance use Rust, you can be a lot more confident that the compiler catches these issues, and be more conservative and efficient in the solution.

Re: What it feels like when Rust saves your bacon

#68

Post by woodruffw »

MauranKilom wrote: post #45
proto_lambda wrote: post #29

Earlier quoted context omitted.

Have you seen modern C++? It has had new syntax bolted on every couple years for the past few decades, the result is quite phenomenal.

Can you name what new syntax you abhor? I mean, other than [] (){}() being a valid C++ expression [0], C++ hasn't even made any notable sygil-related syntax changes recently. Sure, some keywords were added (auto, constexpr, co_yield...) but I don't see how that leads to "ugly" syntax. [0]: That's a lambda capturing no state, having no template parameters, taking no arguments, with an empty body, finally being called…

I find the new user-defined literals syntax pretty ugly. Useful, but ugly.

On the older side: the initialization list syntax has always been ugly (and bug-prone, due to the unintuitive evaluation order.)

Re: What it feels like when Rust saves your bacon

#69

Post by girvo »

lelanthran wrote: post #43
vgel wrote: post #25

Earlier quoted context omitted.

It probably depends on project type and how complex your ownership models are, but that doesn't really track with large projects having a majority of their CVEs be memory safety issues that are far less likely in Rust[1] (e.g., https://www.chromium.org/Home/chromium-security/memory-safet... ) [1] I say far less likely because obviously it's possible with unsafe Rust, but I've never had one happen, seen one happen in…

I'm not saying that a large number of CVEs won't be prevented in Rust, I'm saying that so few bugs are CVEs that the trade-off is not always worth it. If you have 1000s of bug reports, of which 5 are CVEs, and then have 3 of those 5 be preventable, most dev teams are still going to consider the cost/benefit of going through the pain of developing a long-term product in Rust, or of switching to Rust altogether.

I suppose it comes down to risk assessment; if those CVEs are critical “fix this now or the world catches fire”, then their relative infrequency seems to be outweighed by their impact, no?

Re: What it feels like when Rust saves your bacon

#70

Post by lmm »

shuger wrote: post #31
bestouff wrote: post #22

Earlier quoted context omitted.

Yeah no. In my experience, when several people commit to a common C/C++ codebase this kind of issue become really exhausting when it happens more than once, and the symptoms may be so subtle it's a bitch to debug. Rust lowers your mental load. You spend more time being creative and way less time debugging "obvious" (or not) mechanical problems (reference not-on-stack-anymore variables, use-after-free, concurrent writ…

I work in probably what is considered one of the least "safe" languages: C++ The issues that Rust is supposed to help with are simply not what we spent time on. All the bugs reported are pretty much exclusively root caused to "business logic". From recent time I can recall only one that was a programming mistake and not architecture/business logic related. It was a missing break in a switch that already had some fall…

> The issues that Rust is supposed to help with are simply not what we spent time on. All the bugs reported are pretty much exclusively root caused to "business logic".

Everyone claims this, probably because business logic bugs are more memorable. But I've never seen it match the real statistics. According to the best published data, null alone is something like 30-70% of bugs, you just don't remember them because they're uninteresting.

Post reply on HN