Live data from Hacker News

What it feels like when Rust saves your bacon

smallcultfollowing.com

161–170 of 192 posts

Re: What it feels like when Rust saves your bacon

#161

Earlier quoted context omitted.

I don't agree. The support for static polymorphism is in it's infancy at best.

Can you give some examples of what you mean? I use static polymorphism in C++ routinely and haven't felt particularly limited by it.

Sure. I guess template-based polymorphism is alright for code dispatch. But if you want to store the different types of objects involved you have limited choices. There's no straight-forward support for sum types. std::variant is fairly new, has a cumbersome API, and is quite slow (ballpark the same as virtual calls). There's no support for methods on enums nor anything for customizing the fields of different enum constants. There's also no pattern matching or other really convenient way of deconstructing variants.

So while it's there, I would say that the oo virtual method style is much better supported, although storage for those usually requires some type heap allocation.

Re: What it feels like when Rust saves your bacon

#162
post #110

Earlier quoted context omitted.

> There are however valid questions, like if Rust slows down your development say, 5%, would you get more net safety from spending 5% more time testing/fuzzing c++ code instead? etc. I think a similarly valid question is how often you resorted to dynamic allocations just to get the borrow checker off your back. If your Rust version uses 5% more dynamic memory (with the corresponding performance and memory footprint p…

That is a fair thing to wonder about, but at the moment most of the design decisions Rust pushes you toward tend to be better for performance on modern hardware. For instance using an array based arena to store a graph, instead of the traditional allocation of a chunk of memory per node on the heap. Or just keeping more stuff on the stack.

But it takes a lookup hit and you need an arena per object type with its memory overheard. You'll get more cache misses.

A lot of the rust performance talking points just aren't true. Rust is slower than C and C++, not by much but you can't get a true believe to even recognized this. Rust has turned into a religion.

Rust also disallows some things that you can do fine on C++ if you know our architecture because thing won't work on some machine 20 years ago (eg, it has more strict alignment requirements than any machine a consumer can see).

Throughput may only be 5% or more slower, but latency issues for rust is a much bigger issue. The devs I've talked to don't even try to pretend they have a good latency profile.

Re: What it feels like when Rust saves your bacon

#163
post #31

Earlier quoted context omitted.

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…

I see many C++ programmers say stuff like this, and maybe it is the case that studios exist which can do C++ without mistakes related to memory management or sigils and so on, but I also observe that: 1. High quality teams like the Linux kernel team and PostgreSQL, do periodically have serious security bugs that are things Rust would have caught. 2. I see sometimes C++ instructors making the same claims you do and th…

The linux kernel is absolutely anything other than high quality lol

Re: What it feels like when Rust saves your bacon

#164
post #32

Earlier quoted context omitted.

Just because Rust, in particular, compiles successfully, that's no guarantee that the code isn't complex and difficult to understand. I can write a complex badly designed app in any language. Similarly I can write simple well designed large applications in any language too.

Yeah, but that doesn’t mean all languages are created equal in that department. Let’s take this pseudocode: int a = 0; if (findindex(mylist, myvalue, &a)) { // dostuff with a } Here, findindex returns false if it can’t find the value. The problem is that there’s nothing forcing you to use the if, you can just forget it and you’ll be left with incorrect code. In Rust, this type of error is impossible to make by accide…

[deleted]

Re: What it feels like when Rust saves your bacon

#165
post #95

Earlier quoted context omitted.

I'd venture that the development slowdown from using rust is closer to 50% than 5%. Even just compile times probably slow down that much, not to mention you have to write (sometimes) as much as 10x code to express yourself. The specific exercise I have in mind is a lockless thread queue. < 20 lines in C .. ~200 lines in Rust.

>The specific exercise I have in mind is a lockless thread queue. Do they have an equivalent API? Rust does have a hard time explaining very, very low level stuff that you'd have to do unsafe and various magicks. But once you get the unsafe details right, the consumer API for them tends to be extremely rigid and fool proof.

> Rust does have a hard time explaining very, very low level stuff

A little odd for a supposed system langauge

Re: What it feels like when Rust saves your bacon

#166
post #8

This article is super overcomplicated. All it had to say was that rust tells you when you keep reference to on stack variable after it goes out of scope. Context provided adds nothing. I must say - as someone who doesn't use rust - I haven't had this type of issue in years, and when I did it wasn't hard to debug. You get corrupted data, set data breakpoint and in the provided example you will see it being modified by…

Earlier this month we integrated a C++ library written by my team with a server written by another team. We saw the data corruption, and we knew it was a reference issue, but it took quite a bit of effort to track down. The cause was confusion around string_view and string&, with different behavior when you pass each to a new thread. Rust would have caught this much earlier and saved 3 days work.

[deleted]

Re: What it feels like when Rust saves your bacon

#167
post #42
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. You know, I'm a Rust evangelist. And I can tell you, why I ignore logic bugs when trying to sell Rust. Rust can prevent some logic bugs if they break invariant you managed to encode or enforce in your types. But it is a difficult topic to dive in a…

> Rust deniers

Wow.

Re: What it feels like when Rust saves your bacon

#168

Earlier quoted context omitted.

Can you give some examples of what you mean? I use static polymorphism in C++ routinely and haven't felt particularly limited by it.

Sure. I guess template-based polymorphism is alright for code dispatch. But if you want to store the different types of objects involved you have limited choices. There's no straight-forward support for sum types. std::variant is fairly new, has a cumbersome API, and is quite slow (ballpark the same as virtual calls). There's no support for methods on enums nor anything for customizing the fields of different enum co…

Okay, yeah, I would broadly agree with this. I think most people use template-based polymorphism, which is pretty flexible in practice. The use of virtual methods is verboten for many common use cases of C++, due to the necessity of being in paged memory, so constructions for dealing with polymorphism without virtual methods are commonplace. And std::variant is a bit of a hot mess.

Re: What it feels like when Rust saves your bacon

#169

Earlier quoted context omitted.

Sure. I guess template-based polymorphism is alright for code dispatch. But if you want to store the different types of objects involved you have limited choices. There's no straight-forward support for sum types. std::variant is fairly new, has a cumbersome API, and is quite slow (ballpark the same as virtual calls). There's no support for methods on enums nor anything for customizing the fields of different enum co…

Okay, yeah, I would broadly agree with this. I think most people use template-based polymorphism, which is pretty flexible in practice. The use of virtual methods is verboten for many common use cases of C++, due to the necessity of being in paged memory, so constructions for dealing with polymorphism without virtual methods are commonplace. And std::variant is a bit of a hot mess.

> The use of virtual methods is verboten for many common use cases of C++, due to the necessity of being in paged memory

I wasn't aware of this. Maybe I'm just out of the loop. Do you know where one can I learn more about this? I'm desperately trying to reduce the number of virtual calls in our codebase, but I'm hitting the aforementioned problems.

Re: What it feels like when Rust saves your bacon

#170
post #70
post #31

Earlier quoted context omitted.

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

There are and never will be (meaningful) statistics for the "N percent of bugs are caused by X" question.

Every org's use cases are different, how do you get (let alone compare) data frm different orgs, who really counts their bugs anyway (and those that do at scale and in detail are probably doing suffering from some form of myopic management disorder or another), etc.

All you can do is ask people their gut take based on their particular experience. For systems engineers, a lot of bugs are due to memory safety. For more consumer-oriented startups (or in most any bigcorp), yeah, it's "business logic" (or people's inability / unwillingness to communicate), etc.

"We found that 70 percent of our bugs could have been prevented by moving to TypeScript", yeah sure.

Post reply on HN