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

261–270 of 341 posts

Re: Several core problems with Rust

#261

Post by estebank »

neonspark wrote: post #255
imtringued wrote: post #234

Earlier quoted context omitted.

.unwrap() was a huge mistake. It should be banned from release builds outright. It's the equivalent of dereferencing a null pointer in C or the NullPointerException in Java. All .unwraps() should be replaced by .expect("uniquely identifying message") immediately and preferably the compiler checks that the expect messages are unique within a crate and issues a warning. Debug builds should by default give .unwrap() and…

> Debug builds should by default give .unwrap() and .expect() a tiny chance, like 0.1%, to trigger anyway, even when the Option is Some (opt out via configuration). I'm trying to understand what you're proposing. Are you saying that normal debug builds should have artificial failures in them, or that there should be a special mode that tests these artificial failures? Because some of these failures could cause errors…

I guess they are advocating for exhaustive branch testing.

Re: Several core problems with Rust

#262

Post by saghm »

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…

> So many times I've tried to do something in Rust the old fashioned way, the way I have always done things, and been stopped by the compiler. I then investigate why the compiler/language is being so anal about this trivial thing I want to do.. and yup, there's a concurrency bug I never would have thought of! I guess all that old code I wrote has bugs that I didn't know about at the time.

This is also my experience. I've had dozens of times over the years that I've been confused about why Rust does something a certain way, but I don't think I can recall a single one where I didn't end up finding out that there was an extremely good reason for it. That's not to say that in every one of those cases, the design choice Rust made was the only reasonable one, but in the cases where it wasn't, the situation always ended up being more nuanced than it appeared to me at first glance, and what I would have originally expected would have implicitly made a significant tradeoff I hadn't considered.

I'm having trouble finding it now, but years ago someone had a quote that ended up getting published in the language's weekly newsletter that was something like "Rust moves the pain of understanding your program from the future to the present". It's extremely apt; most of the difficulty I've seen people run into when trying to program in Rust ends up being that they're forced to consider potential issues that in other languages they could have ignored until later, and then would have had to debug down the line.

Re: Several core problems with Rust

#263

Post by bryanlarsen »

adastra22 wrote: post #250
bryanlarsen wrote: post #243

Earlier quoted context omitted.

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.

Of course you have to lock a mutex. You'd have to do that no matter the language, right?

And that's what I meant by verbose/ugly. Each of those steps is usually an if let / else error. None of those steps are hard, but you have to do them every time.

Re: Several core problems with Rust

#264

Post by Voultapher »

What a waste of time article. There is plenty of debunking of the points already so I won't repeat them.

Yes C++ has many many issues, and yet most of the biggest most complex software systems in existence are written in it. I don't see the browsers, OSs, DAWs, AAA games etc. being implemented in Go. Rust is a real improvement for these areas, with a proven track record of making software more reliable and maintainable.

If the author intended to say "Rust is not the best programming language for every problem" they should have said that but it would have been worth an article as much as "Screwdrivers are not the best hammers".

Re: Several core problems with Rust

#265

Post by aw1621107 »

estebank wrote: post #258
aw1621107 wrote: post #251

Earlier quoted context omitted.

> It's not "my take". https://www.pingcap.com/blog/rust-compilation-model-calamity ... is a good resource on this. I think one interesting thing that could be explored more is what aspects of Rust "inherently" result in slow compilation (i.e., if you changed said aspects to improve compilation speeds then you end up with a "different" language, assuming some hand-waviness with respect to equivalence here) and what as…

There are at least three separate things that rustc and cargo could do to significantly improve compilation speed, but they are complex engineering efforts that require time and engineers being paid to work on full-time. They are: doing what zig does to compile only items that arr reachable, which requires making rustc reentrant to stop after name resolution and cargo more complex to pass used paths through subsequen…

Oh, I hadn't heard that you guys are looking at Zig-style "targeted" compilation (for lack of a better phrase). That sounds like it entails quite a bit of infrastructure work. Is there a GitHub issue I can follow to keep an eye on progress?

Out of curiosity, have there been any interesting pondered/proposed avenues for speedup that were rejected because they would result in too much breakage, violate a core tenant of Rust (e.g., require a runtime to be usable) or other reason that is "inherent" to Rust?

Re: Several core problems with Rust

#266

Post by nrds »

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!! }

Maybe rust should put a function in the core library which does this! Send a PR!

Re: Several core problems with Rust

#267

Post by estebank »

aw1621107 wrote: post #265
estebank wrote: post #258

Earlier quoted context omitted.

There are at least three separate things that rustc and cargo could do to significantly improve compilation speed, but they are complex engineering efforts that require time and engineers being paid to work on full-time. They are: doing what zig does to compile only items that arr reachable, which requires making rustc reentrant to stop after name resolution and cargo more complex to pass used paths through subsequen…

Oh, I hadn't heard that you guys are looking at Zig-style "targeted" compilation (for lack of a better phrase). That sounds like it entails quite a bit of infrastructure work. Is there a GitHub issue I can follow to keep an eye on progress? Out of curiosity, have there been any interesting pondered/proposed avenues for speedup that were rejected because they would result in too much breakage, violate a core tenant of…

You can see epage's replies to my copy of this comment for an idea of the open questions: https://hachyderm.io/@ekuber/115605792856416650

You can look at what is currently effectively staffed at https://rust-lang.github.io/rust-project-goals/#flexible-fas...

We discussed a lot of these last May in person. Haven't kept track of who's doing what on these fronts.

> have there been any interesting pondered/proposed avenues for speedup that were rejected because they would result in too much breakage, violate a core tenant of Rust (e.g., require a runtime to be usable) or other reason that is "inherent" to Rust?

Yes, but I haven't been part of all of them and can't ellaborate much here. Opening a thread in internals.rust-lang.org with that question might get some good info sooner that I could.

Re: Several core problems with Rust

#268

Post by 15155 »

nrds wrote: post #266
dana321 wrote: post #233

Earlier quoted context omitted.

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!! }

Maybe rust should put a function in the core library which does this! Send a PR!

https://doc.rust-lang.org/std/result/enum.Result.html#method...

Re: Several core problems with Rust

#269

Post by aw1621107 »

estebank wrote: post #267
aw1621107 wrote: post #265

Earlier quoted context omitted.

Oh, I hadn't heard that you guys are looking at Zig-style "targeted" compilation (for lack of a better phrase). That sounds like it entails quite a bit of infrastructure work. Is there a GitHub issue I can follow to keep an eye on progress? Out of curiosity, have there been any interesting pondered/proposed avenues for speedup that were rejected because they would result in too much breakage, violate a core tenant of…

You can see epage's replies to my copy of this comment for an idea of the open questions: https://hachyderm.io/@ekuber/115605792856416650 You can look at what is currently effectively staffed at https://rust-lang.github.io/rust-project-goals/#flexible-fas... We discussed a lot of these last May in person. Haven't kept track of who's doing what on these fronts. > have there been any interesting pondered/proposed avenu…

> You can see epage's replies to my copy of this comment for an idea of the open questions: https://hachyderm.io/@ekuber/115605792856416650

Those are some interesting discussions there! Decent number of things I hadn't considered.

> Opening a thread in internals.rust-lang.org with that question might get some good info sooner that I could.

I'll have to see about setting signed up, then (or finding my old credentials; don't remember if I ever had any).

Re: Several core problems with Rust

#270

Post by zorobo »

throwaway81523 wrote: post #147
teleforce wrote: post #108

>Its compilation is slow. I mean SLOW. D language smiling in the corner [1]. "D supports Ownership and Borrowing, just like Rust. DMD, D's reference compiler, can compile itself in less than 5 seconds, thanks to a fast frontend and fast backend. D is easy to metaprogram through traits and templates. You can make your own JIT in D with dynamicCompile." [2] [1] Kevin James meme creator tries to guess why the photo went…

Ocaml compilation is also very fast, and it has generics like Rust, amirite?

Partly; OCaml does not, in the general case, generate code for a function for each boxed data type it is called with, for example. This, and the fact that the compiler does not optimize extensively, makes for fast compilation. The code still runs fast, especially for a language with gc.
Post reply on HN