I've used Rust and I like it alright but it has the ugliest syntax of any major language since Perl
agreed, I’ve tried to pick up rust a few times and the syntax has always made me give up halfway through the point of writing a real project. It’s really a shame since they had every opportunity not to make the syntax horrible. CPP has horrendous syntax but a lot of that is because they needed to start representing features over time that didn’t exist from the ground up. Rust had pretty much all of its killer feature…
It shouldn't be surprising that Rust's syntax is inspired by C++, Rust is literally designed to entice C++ programmers, and the syntax reflects that (modulo a handful of irresistible ML-isms to match the type system).
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…
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…
Static analyzers can catch this stuff nowaways (in this case clang's builtin analyzer):
Rust's safety features have never been its main selling point for me. Modernity and (recently) momentum are. That it's impossible to author certain classes of bugs is a nice bonus. That said, I never want to see another rounding bug in financial statements that happened because some piece of code implicitly converted a string to a float and it kinda almost worked every time. To quote a cliche, I'm too old for that sh…
(Probably float to string and back, actually. Some mess like that anyway)
It’s pointing out that we are pushing into this vector
which needs references into “the AST”, but we haven’t
declared in our signature that the ast::Ty must actually
from “the AST”.
I think someone needs to write a typechecker for English to help out the author of this sentence.
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…
> All it had to say was that rust tells you when you keep reference to on stack variable after it goes out of scope.
The author isn't just telling you that Rust is awesome because it tells you something, he's acknowledging the frustration in learning how to listen to the compiler.
It's kind of like Jerry Pournelle describing the ups and downs of USB by documenting an epic journey that all started with trying to scan some handwritten notes for his next novel using a Canon scanner he borrowed from Alex that he's just now getting around to reviewing, because the pins of the parallel port are too bent to use the old Epson. Okay, so maybe it was a little overcomplicated.
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,…
Sometimes (definitely not always) you can use std::function instead for dynamic polymorphism.
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.
What's the use of standing on that anti-static mat and wearing that grounding strap? Can't you see there are fork lifts zipping around just right in the next room? That mat is giving you a false sense of security!
I had to deal with a senior dev. that gave me a talk about seniority after I ran valgrind over our software. Guy was so deep into the whole senior dev. power trip that he blamed third party libraries for his bugs, dev. tools for "incorrectly" identifying his bugs and wrote more bugs to work around his other bugs. Finding and fixing issues in C++ code can be easy with the available tools, getting people to use them on…
That sounds more like an expert beginner than senior.
Sounds like someone who senses his place in the hierarchy is threatened.
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…
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.
It seems like it is true and accurate to say that Rust prevents “whole classes of bugs”. It is obvious that other bugs can still exist. Otherwise people would say Rust prevents “all bugs”.
Are you disappointed that Rust evangelists don’t spend time talking about the fact that bugs can exist in Rust programs? Did you see the two articles posted in the last week alone about bugs that were found in Rust code? They reached the front page of HN
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…
Counterpoint: When I was on the Windows accessibility team at Microsoft, one of my most brilliant colleagues gave a presentation about what to look for when doing code reviews, and he emphasized three main categories: C++, COM (Microsoft's Component Object Model), and concurrency. Rust eliminates many of the issues in the first and third categories. And yes, we were writing modern C++ as much as we could in that legacy codebase; by 2019 we were using several C++17 features, as well as the latest C++ utility libraries for working with COM and WinRT. Given the state of the Rust windows crate, that team (which both I and that colleague left in late 2020) might even be able to use Rust in new code. I'm sure that would make him happy.