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

161–170 of 341 posts

Re: Several core problems with Rust

#161

Post by vacuity »

lordnacho wrote: post #54

I tend to disagree. - Compile speed. Why do people care so much? Use debug for correctness and iterating your code. You're hardly going to change much between runs, and you'll get an incremental compile. Let rust-analyzer tell you if there are errors before you even try compiling. Let your CI do release optimization in its own time, who cares if CI is slow? - The cloudflare bug was not caused by rust. Every language…

Your point about compile times is very dismissive and wrong, but I agree aside from that. It's worth noting that the Rust team explicitly tracks, monitors and limits regressions in, and actively optimizes for compile times, and Rust community surveys always ask for better compile times. This is clearly a significant issue, and while Rust is never going to compile as fast as C or Pascal, it can and will improve so that it becomes more usable.

Re: Several core problems with Rust

#162

Post by vacuity »

Capricorn2481 wrote: post #156
lordnacho wrote: post #54

I tend to disagree. - Compile speed. Why do people care so much? Use debug for correctness and iterating your code. You're hardly going to change much between runs, and you'll get an incremental compile. Let rust-analyzer tell you if there are errors before you even try compiling. Let your CI do release optimization in its own time, who cares if CI is slow? - The cloudflare bug was not caused by rust. Every language…

> Things having unsafe {...} does not make them unreliable. On the contrary, if you run into a memory issue in a rust program, you know where to look for it This isn't true, no matter how much people keep saying it. Unsafe does not scope bugs to the block, or even where you have to look for bugs. Just having unsafe in your codebase means changing code outside the unsafe block could cause UB. Doesn't mean I think it's…

Internal use of unsafe requires securing the safe code at the module boundary. However, the design of unsafe still greatly reduces the burden of memory safety, both when it is and isn't used directly. The specific semantics of Rust aside, unsafe is more or less the ideal way for a language to express unsafe escape hatch constructs.

Re: Several core problems with Rust

#163

Post by vacuity »

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…

I am not too familiar with D, but it seems that D's borrowing system is somewhat different than Rust's, given that it is not the focus of how D is implemented and used. This means different design tradeoffs.

There are appropriate ways to contrast D with Rust and illustrate where D is stronger, but it is inaccurate to say "Rust has borrowing; D has borrowing" and conclude that they are comparable in this sense.

Re: Several core problems with Rust

#164

Post by vacuity »

byko3y wrote: post #139
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…

>"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." Indeed, there are languages that have generics, compile blazingly fast, and still have good runtime performance. Go lang is another good examp…

"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.

Re: Several core problems with Rust

#165

Post by [deleted] »

byko3y wrote: post #152
lordnacho wrote: post #54

I tend to disagree. - Compile speed. Why do people care so much? Use debug for correctness and iterating your code. You're hardly going to change much between runs, and you'll get an incremental compile. Let rust-analyzer tell you if there are errors before you even try compiling. Let your CI do release optimization in its own time, who cares if CI is slow? - The cloudflare bug was not caused by rust. Every language…

>Compile speed. Why do people care so much? Use debug for correctness and iterating your code. You're hardly going to change much between runs, and you'll get an incremental compile. What's the largest Rust-based public codebase so far? Rustc with like 1 million lines of code including all the dependencies in all the languages? Zed IDE has 800k lines. Incremental compilation seems to work fine at this scale, but thin…

[deleted]

Re: Several core problems with Rust

#166

Post by vacuity »

dannersy wrote: post #66

This is either performance art or rage bait. The opinions here are so wild. There are so many claims here that are wrong and just strange, it is hard to know where to start.

Seeing this comment from Kent Overstreet was hysterical: https://news.ycombinator.com/item?id=46029555. He's not even criticizing Rust, nor is he the author, but still...

But yes, this sure is a nice and sane thread.

Re: Several core problems with Rust

#167

Post by bccdee »

throwaway81523 wrote: post #153
bccdee wrote: post #80

Earlier quoted context omitted.

The article complained that a Rust program can crash when you call `unwrap`—in fact, the author says that's their strongest critique. Python crashes when you call `sys.exit`, so it's no better. Unfortunately I don't think their critique is really coherent—this is an absurd standard.

Other languages have some kind of exception mechanism so the crashing unwrap gets caught and handled, preferably sanely. Erlang in fact is written around the idea of expecting stuff to crash, and restarting the crashed thing when it happens.

This crash gets caught and handled too: the process exits, the kubernetes pod fails, and the deployment recreates it from scratch. Panicking like this is a request for the infrastructure to turn the whole service off and on again, which is sometimes the correct way to deal with transient failures. The problem here is that the infrastructure was restarting the service with the same bad config every time, causing a crashloop. It's a system design bug.

Re: Several core problems with Rust

#168

Post by vacuity »

PaulDavisThe1st wrote: post #118
loeg wrote: post #62

Earlier quoted context omitted.

Idk, it's a general rule of thumb that the more mutable shared state an algorithm has, the worse it scales. So if you're trying to scale something to be concurrent, mutable shared state is an antipattern.

as noted someone else, it is lock contention that doesn't scale, not mutable shared state. lock-free data structures, patterns like RCU ... in many cases these will scale entirely appropriately to the case at hand. A lot of situations that require high-scale mutable shared state have an inherent asymmetry to the data usage (e.g. one consumer, many writers; many consumers; one writer) that nearly always allow a better…

Mutable shared state is literally the nature of contention. It's true that locking is the mediocre default, but "avoid locks" is not a silver bullet. Alternatives have their own tradeoffs. If you "carefully design" a solution, it's probably because you're not just using an alternative but actually taking care to optimize, and because you have a specific use case (which you described).

Re: Several core problems with Rust

#169

Post by bccdee »

Mauneam wrote: post #151
rddbs wrote: post #144

Earlier quoted context omitted.

You get to choose between UB, a crash, or handling the error — same as most other languages. It’s not a reliability issue of the language if as an author of software you choose to crash in your failure handling cases. Claiming otherwise is either disingenuous or a failure to understand what actually happened.

No, it's not the "same as most other languages". C and C++ are actually the only mainstream languages that suffer from UB to this extent. The fact that, in practice, with Rust you get a crash instead of UB is 100% a reliability issue with the language. The crashes are inbuilt. And blaming the crash on the author, saying they "chose to crash", is exactly the same as blaming UB on the author of C code, saying they "cho…

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, since Cloudflare's infrastructure was restarting the service with the same bad config every time.

Re: Several core problems with Rust

#170

Post by vacuity »

Mauneam wrote: post #151
rddbs wrote: post #144

Earlier quoted context omitted.

You get to choose between UB, a crash, or handling the error — same as most other languages. It’s not a reliability issue of the language if as an author of software you choose to crash in your failure handling cases. Claiming otherwise is either disingenuous or a failure to understand what actually happened.

No, it's not the "same as most other languages". C and C++ are actually the only mainstream languages that suffer from UB to this extent. The fact that, in practice, with Rust you get a crash instead of UB is 100% a reliability issue with the language. The crashes are inbuilt. And blaming the crash on the author, saying they "chose to crash", is exactly the same as blaming UB on the author of C code, saying they "cho…

You don't have to call unwrap()...Rust provides alternatives, which are very prominent.
Post reply on HN