211–220 of 341 posts
Earlier quoted context omitted.
Err, you can't use `?` with `Option` unless I've really missed a big feature somewhere. You'd have to map it to a `Result` then unwrap, but at that point you still need to define an error type.
You have missed a big feature! They added support for that like a year ago or something.
Earlier quoted context omitted.
>Yeah until that memory safety issue causes memory corruption in a completely different area of code and suddenly you're wasting time debugging difficult-to-diagnose crashes once they do start to surface. Some very solid argument here. However, as already implied in my article, you can get most of the guarantees without losing your sanity. Memory-safety-related problems are important, but they are not the sole source…
> 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…
Again, mission f#*@ing accomplished. Maybe you DON'T need that state to be shared, reference-counted, or heap allocated. Maybe you can refactor your code to get rid of those annoyingly hard to deal with abstractions. And you end up with better, more reliable, likely faster code at the end of it.
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.
There are basically two reactions people have to this situation: (1) they're thankful that they learned something, their code is improved, and go about their day learning something new; or (2) feel frustrated and helpless that the old way of doing things doesn't work, and rage-quit to go write a "WHY RUST IS THE WORST THING SINCE MOSQUITOS" blog article.
Earlier quoted context omitted.
>"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.
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 feel like the old tool. They did not really invent some new model, look at std::shared_ptr, std::mutex, move semantic — it was already in C++ before the prototype of Rust. The "share immutables, lock mutables" model was a holy grail of C++ concurrency caused by the way STL worked — and STL is not nearly the only container library in C++.
Okay, what's your take on why exactly Rust compiles slowly?
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…
> The cloudflare bug was not caused by rust Yeah. Rust’s Option::None as like null in C++. Unwrapping an option is like checking if something is null and crashing. This "crash from an unwrap" is just a null pointer exception / segfault in any other language. The same bug would be trivial to write in any other language, and with more or less the exact same result. Its just - weirdly news because it was rust code. What…
I say this as a Rust advocate and daily Rust programmer, btw.
Earlier quoted context omitted.
It's 200% LLM used in production — like 10 hours of dialogs right before writing the article. I had much more hours of coversations with Rust fanboys and it was mostly a waste of time, they just would not try to negotiate on Rust's weak points. I would definitely not be able to write the article with only human support — it's really sad to conclude that LLM-s are much better assistants because they are neutral and ob…
Were any parts copy pasted from LLM output (and possible changed after)?
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…
Earlier quoted context omitted.
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, sinc…
> 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…
>There are two conclusions: 1) If Cloudflare hadn't decided on a proper failure mode for this (i.e. a hardcoded fallback config), the end result would've been the same: a bunch of 500s, and 2) most programs wouldn't have behaved much differently in the case of a failed allocation. So why do they need Rust then? What advantages does it provide? That was the main point of the article — we all wanted a better language,…
If you're going to criticize something, at least do it properly.
> 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 has potential to be the new thing, since several details synergize to make this incident more powerful: 1. Previous claims that Rust code often just works after compiling. 2. Previous claims that low-level error-handling idioms like matching, using Result, etc improve code reliability. 3. Previous claims that using unwrap in example code is ok for brevity. Also, Rust developers would know not to use it in producti…
2. They do. If you use them, which they didn't.
3. It is. Let's not discard personal responsibility.
4. The error would've happened in any language, Rust debatably made it easier to find though.
I don't write Rust code myself because I simply don't write any code that requires this kind of reliability, and thus I haven't expended the effort learn it properly. But if I were to start such a project, I would still go for Rust and learn it properly. I also don't have a "favorite" language. I just pick whichever seems most appropriate for the project, any decent programmer should be able to pick up any non-esoteric language to the point of adequacy in a few weeks anyway.
I'm annoyed that this submission's title was changed. This was first submitted with the original title, "Rust is a disappointment," and got flagged. It looks like it's been unflagged and the title has been changed. A quick search of HN shows a bunch of articles, "X is a disappointment," which aren't flagged. Do folks have such thin skin about this topic that expressing disappointment deserves flags?
Language wars are an endemic pathogen on HN and any steps we take to suppress are probably for the good.
But that's rarely the case with flagging. I'd say impossible to enforce even.