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

Several core problems with Rust

bykozy.me

Post reply on HN
Print view View original

241–250 of 341 posts

Re: Several core problems with Rust

#241

Post by imtringued »

byko3y wrote: post #82
yoyohello13 wrote: post #53

Earlier quoted context omitted.

I haven’t seen a positive Rust article hit HN in over a year. Seems the zeitgeist has turned against it. All it took was the US government giving the thumbs up I guess.

On the other hand, lets face it: most of the time security in IT systems is the least priority. I mean after shipping fast, iterate fast, better performance, compatibility, architecture soundness (whatever it is), convenient tests, docs with UML diagram, well-designed interface — and somewhere in a distant drawer on the bottom you may find a note about security issues. It's often times people talk about importance of…

>We probably don't need the Rust though.

Uhm, I would have picked Rust just for shipping fast, iterating fast, better performance and compatibility. The security is a bonus that comes along for the ride. You probably haven't had the displeasure to work with C++ in combination with ROS. That experience really soured me on C++.

Re: Several core problems with Rust

#242

Post by benjiro »

tptacek wrote: post #113
benjiro wrote: post #109

Earlier quoted context omitted.

[flagged]

I didn't downvote you and couldn't have (you were replying to me). Please don't comment about the voting on comments. It never does any good, and it makes boring reading. https://news.ycombinator.com/newsguidelines.html

[flagged]

Re: Several core problems with Rust

#243

Post by bryanlarsen »

adastra22 wrote: post #212
saghm wrote: post #116

Earlier quoted context omitted.

> Some very solid argument here. However, as already implied in my article, you can get most of the guarantees without losing your sanity. I think this is part of why your article is causing a strong reaction from a lot of people; quite a lot of the justification for your point of view is left implied, and the concrete examples you do give about Rust (e.g. `Arc >>>` and `.unwrap`) are hard not to see as straw men whe…

Also the argument with `Arc >>>` boils down to "Rust makes it hard to work with automatic reference-counted shared mutable heap-allocated state." In which case... mission accomplished? Rust just made explicit all the problems that you still have to deal with in any other language, except dealing correctly with all that complexity is such a pain that you will do anything you can to avoid it. Again, mission f#*@ing acc…

Nit: it doesn't make it hard, it makes it ugly and explicit. `Arc>>>` is not hard to use, it's just annoyingly verbose and ugly.

That's a low level construct, there are much nicer higher level sharing constructs, like channels.

Mission accomplished.

Re: Several core problems with Rust

#244

Post by Measter »

dana321 wrote: post #233
hypeatei wrote: post #68

> We actually had a recent Cloudflare outage caused by a crash on unwrap() function Oh boy, this is going to be the new thing for Rust haters isn't it? Yes, unwrapping an `Err` value causes a panic and that isn't surprising. Cloudflare had specific limits to prevent unbounded memory consumption, then a bad query returned a much larger dataset than expected which couldn't be allocated. There are two conclusions: 1) If…

It was bad coding. .unwrap() is not required to be used. use: if let Some(value)=something_to_unwrap{ }else{ // log an error and exit!! }

Fun fact: that's what an unwrap does. It panics, which causes the error to be logged and the thread ended.

Re: Several core problems with Rust

#245

Post by Measter »

josefx wrote: post #217
bccdee wrote: post #169

Earlier quoted context omitted.

What UB? This has nothing to do with UB; it'd be well-defined in any language. It's equivalent to this python snippet: config = load_config() if !config.valid(): sys.exit(1) # config is corrupt. restart pod Did Python do something wrong by letting users call `sys.exit`? No. This is a deliberate crash. Under other circumstances, crashing might have been a valid strategy, but here it turned out to be a bad choice, sinc…

Sys exit does not crash. It raises a SystemExit exception, which can be caught on any layer above it. Given that python uses exceptions for trivial things like loop termination this can be considered normal flow control.

And, by default, panicking in Rust also doesn't crash, it begins a stack unwind which can be caught on any layer above it with catch_unwind.

Re: Several core problems with Rust

#246

Post by jimjag »

I think people are missing the main point. The real issue with Rust is that it is a designed language which is really tuned and optimized for a specific use case. And for that specific usage, it is really, really good. But even so, it requires a lot more up-front work, due to the limitations and restrictions it imposes.

But it is NOT a good general purpose language. And, maybe to be putting words into the author's mouth, that is their main beef. That every seems to be pushing "Rust All Things" even when it makes no sense, and even if there are much better alternatives available.

So for such comments as "so what about compile time", the issue is that for some, compile time _is a concern_. If it isn't for you, great. But you just can't discount what are valid concerns for others.

People seem to forget that languages are _tools_, and as such, have different sweet-spot use-cases.

Re: Several core problems with Rust

#247

Post by vacuity »

byko3y wrote: post #213
vacuity wrote: post #164

Earlier quoted context omitted.

"Generics" is not why Rust compiles slowly. Rust had certain design decisions and implementation details that impact compile times significantly. Do not misrepresent them and pretend that the Rust developers are incompetent or malicious. By doing so, you invite discourse as ideological and uncritical as that of Rust fanatics, however many or few there are.

>Do not misrepresent them and pretend that the Rust developers are incompetent or malicious. I'm sorry, but I sensirely think the Rust designer did a sloppy work by reimplementing C++ flaws with a new syntax. The history repeats itself, the same pathological mechanism once driving C++ development now drived Rust — I mean large enterprise wanting to change everything without changing nothing, the new tool that would f…

Rust certainly takes after C++, but it's not the same. It's more like C++ if it was made today. For instance, Rust's destructive move semantics are the better default. (However, Rust making everything moveable by default is a bit of a drawback.) I don't understand your point about std::shared_ptr, std::mutex, and the immutability/mutability model. These are not C++ constructs; they are general programming constructs that C++ has an implementation of. Rust does not claim to have some innovative take on reference counting or locking. However, Rust's borrowing is an improvement (by default) on managing shared mutable state. Rust is not Carbon, or whatever new C++ variant is out there; it is a backwards-incompatible language that offers better ways to do many of the things C++ is used for.

> Okay, what's your take on why exactly Rust compiles slowly?

It's not "my take". https://www.pingcap.com/blog/rust-compilation-model-calamity... is a good resource on this.

Re: Several core problems with Rust

#248

Post by mlsu »

phaylon wrote: post #227
deng wrote: post #200

> In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. Not a fact. Particularly in the embedded world, crashing is preferable to malfunctioning, as many embedded devices control things that might hurt people, directly or indirectly. > If a pacemaker stops — telling a victim “but the memory was not corrupted in the crash” is a weak co…

Something else I usually don't see: A system hitting a fail-safe is a lot easier to detect and handle from the outside than one that just enters an unknown invalid state. Like, if the rule were "Always-Keep-Running" then hospital equipment power supplies wouldn't have circuit breakers that cut the power when something is wrong. But cutting power seems lot easier to detect for the backup power supply so it can fully t…

Engineer:

“It crashed on an assert…”

Pointy haired boss:

“… well, what are you waiting for!? remove all the asserts so it doesn’t crash any more!”

Re: Several core problems with Rust

#249

Post by TinkersW »

ModernMech wrote: post #140

Regarding slow compilation... On the one hand, I don't regard it as a real "problem" because as the post says, it's by design and the design is that you pay the compilation cost but in return you get something valuable from it: fast safe code. So you pay a fixed cost to compile during development and it's your users and future you who get the benefit of future performance and stability. This is why Rust users are usu…

My understanding is Rust compiles each crate in the same way C++ compiles each .cpp file, so if you stick everything in a single crate you get horrible compile times.

This does seem like a poor design decision by Rust to me, forcing people to break things into arbitrary crates just to get reasonable compile times.

It also seems like a disaster for incremental compilation.

Re: Several core problems with Rust

#250

Post by adastra22 »

bryanlarsen wrote: post #243
adastra22 wrote: post #212

Earlier quoted context omitted.

Also the argument with `Arc >>>` boils down to "Rust makes it hard to work with automatic reference-counted shared mutable heap-allocated state." In which case... mission accomplished? Rust just made explicit all the problems that you still have to deal with in any other language, except dealing correctly with all that complexity is such a pain that you will do anything you can to avoid it. Again, mission f#*@ing acc…

Nit: it doesn't make it hard, it makes it ugly and explicit. `Arc >>>` is not hard to use, it's just annoyingly verbose and ugly. That's a low level construct, there are much nicer higher level sharing constructs, like channels. Mission accomplished.

It is hard to use because you can’t just access the shared state. You have to annoyingly lock it, handle the guard object, etc. Each one of those layers has protocols.
Post reply on HN