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

81–90 of 341 posts

Re: Several core problems with Rust

#81

Post by byko3y »

yoyohello13 wrote: post #51
cwillu wrote: post #40

Earlier quoted context omitted.

“Summary: So, is the Rust bad or good? It’s neither. It’s a mediocre programming language with thousands of man-month put into its development — this fact alone makes Rust a viable tool, just because you can pick it from the shelf and employ as-is. This blog was generated with Zola, written in Rust — I did not have to write a single line of Rust code to use it. And the Rust is a good fit for Zola SSG because of its n…

Literally hates on Rust for the whole article except the final summary.

Man, I explained it in the first sentence of the article — it's not bad, it's much worse than it could have been. The main body of the article is not hate — it's plain facts. Everybody working on a significant Rust codebase agrees that Rust compilation takes eternity. Complexity? I know people that like complexity, they would say "that's a great language because of how hard it is to write a program in it!" — complexity would feel like a praise for them. Shared state? "Just don't use it, you are doing it wrong". That's is, where is the hatred?

Re: Several core problems with Rust

#82

Post by byko3y »

yoyohello13 wrote: post #53
siliconsorcerer wrote: post #43

Earlier quoted context omitted.

Absolutely not. Rust lovers are still incessant as they’ve ever been. More Rust haters is a good thing.

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 security after it destroyed the whole business.

We need more of the security. We probably don't need the Rust though.

Re: Several core problems with Rust

#83

Post by bdangubic »

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…

security incident destroying a business is so rare and penalties for security breaches are non-existent and hence while everyone talks “security is important” it really isn’t all that important - in vast majority of the situations. I mean, fucking experian, the company whose sole purpose for existence is collecting and keeping data on everyone safe leaked everyone’s data and everyone was like “oh ok, thats cool, carry on…”

Re: Several core problems with Rust

#84

Post by hu3 »

yoyohello13 wrote: post #65
hu3 wrote: post #20

Earlier quoted context omitted.

> Rust haters have become more annoying than the Rust evangelists I disagree. There's a long road till that inflection point for me.

At least the Rust evangelist build shit.

People who get shit done are too busy to evangelize.

Re: Several core problems with Rust

#85

Post by josephg »

siliconsorcerer wrote: post #43
yoyohello13 wrote: post #3

I think we’ve officially reached the inflection point where the Rust haters have become more annoying than the Rust evangelists. Maybe in a couple years we will finally be able to stop writing blog post about it.

Absolutely not. Rust lovers are still incessant as they’ve ever been. More Rust haters is a good thing.

Can you give some examples? C/C++ devs seem to be very upset about rust content. Where all these annoying articles claiming we should rewrite everything in rust? They must be all over the place given how much C/C++ devs are upset. But I don't think I've read any?

There was that article from the android team about how rust improved their development workflow[1]. Is that what you're talking about? Was that article emotionally upsetting? Do you wish it wasn't written? What in particular is upsetting? Do you want people to stop writing technical articles to protect your feelings?

[1] https://news.ycombinator.com/item?id=45918616

Re: Several core problems with Rust

#86

Post by hu3 »

jhhh wrote: post #70

You really have to compare articles like this, which are just a bunch of hand waving around the author's biases, against articles with more concrete statements like the Android team finding a 1000x reduction in memory vulnerabilities compared to C/C++. Thanks for your opinion but I'm going to weigh the people who actually use the language more than you.

Hard disagree.

For my reality of developing for smaller projects than Android, I will absolutely weight Android team's opinion less than the opinion of smaller projects.

Trying to mimic FAANG engineering practices is a fools endeavour that ranges between naiveness at best and CV padding at worst.

Re: Several core problems with Rust

#87

Post by HeavyStorm »

byko3y wrote: post #81
yoyohello13 wrote: post #51

Earlier quoted context omitted.

Literally hates on Rust for the whole article except the final summary.

Man, I explained it in the first sentence of the article — it's not bad, it's much worse than it could have been. The main body of the article is not hate — it's plain facts. Everybody working on a significant Rust codebase agrees that Rust compilation takes eternity. Complexity? I know people that like complexity, they would say "that's a great language because of how hard it is to write a program in it!" — complexi…

Subjectiviy (eternity, complex, etc) is never factual. Your post has facts, it does, but it still sounds a lot like hate.

Re: Several core problems with Rust

#88

Post by EnPissant »

byko3y wrote: post #78
fn-mote wrote: post #41

The author says "Rust crashes all of the time" and then goes on to invoke the Cloudflare unwrap() as an example of that. Uhhhh... but that was clearly a programmer error, right? Ignoring the possibility of a Result being Err instead of Ok is not something the language is supposed to protect you against.

There are programming languages/models/runtimes that crash and recover, there are models that gracefully degrade. Rust cannot recover. Neither can C++ in many cases e.g. when you have an exception in a destructor then it's a guaranteed `std::terminate`. Do note that C did not have such a flaw built into language — C++ authors invented it and Rust inherited this flaw (the authors simply did not feel like it's a flaw).…

Nothing forces you to panic in Rust any more than anything forces you to call abort() in C.

    let a = b.unwrap();
is conceptually no different to:

    if (b == NULL) {
        abort();
    }
    a = *b;
don't write either if you don't want to halt.

Re: Several core problems with Rust

#89

Post by aw1621107 »

byko3y wrote: post #78
fn-mote wrote: post #41

The author says "Rust crashes all of the time" and then goes on to invoke the Cloudflare unwrap() as an example of that. Uhhhh... but that was clearly a programmer error, right? Ignoring the possibility of a Result being Err instead of Ok is not something the language is supposed to protect you against.

There are programming languages/models/runtimes that crash and recover, there are models that gracefully degrade. Rust cannot recover. Neither can C++ in many cases e.g. when you have an exception in a destructor then it's a guaranteed `std::terminate`. Do note that C did not have such a flaw built into language — C++ authors invented it and Rust inherited this flaw (the authors simply did not feel like it's a flaw).…

> Rust cannot recover.

catch_unwind exists for a reason.

> e.g. when you have an exception in a destructor then it's a guaranteed `std::terminate`.

You can throw in a destructor [1]. You just need to mark that destructor noexcept(false). You do get a guaranteed std::terminate if an exception escapes a destructor while unwinding is already underway, though.

> Do note that C did not have such a flaw built into language

assert() says hi?

> I mean specially designed embedded C code can survive total RAM erasure and still perform some meaningful work (with CPU registers and ROM intact).

Why doesn't a similar argument apply to "specially designed" Rust?

> Or compare it to BEAM that can have processes crash all day long and still continue to work.

Again, nothing stops you from writing Rust that does the same.

[0]: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

[1]: https://cpp.godbolt.org/z/ao4cf3zrr

Re: Several core problems with Rust

#90

Post by byko3y »

josephg wrote: post #67
lumost wrote: post #12

Earlier quoted context omitted.

We really just need official/honest guidance on Rust for what works and what doesn't. The classic example is the dodging around cyclic datastructures. Tl;DR Rust doesn't support any form of cyclic datastructure without indirection or unsafe. The indirection tooling is weak, and most real examples simply switch to unsafe rust. Unsafe rust is completely fine if you know what you are doing with memory, and is ok to use…

A couple years ago I implemented a btree (technically order statistic tree) in a couple thousand lines of unsafe rust for a project. I wrote it more or less how I'd do it in C. Each internal node and leaf node was a separate heap allocation and internal nodes had an array of child pointers. It was surprisingly hard to program up. And complicated! In my opinion, unsafe rust code is worse to use than C because rust is…

>Eventually I rewrote my btree on top of Vecs. My node & leaf pointers are now array indices. The result? There is no longer any unsafe code. The code has become significantly simpler and it now runs ~10% faster than it did before, which is shocking to me. I guess bounds checks are cheaper than memory fragmentation on modern computers.

Optimizations are very complex and potentially fragile in Rust, LLVM has to sort through tons of generated IR, so it might be just that native Rust structures are optimized better for compilation. Particulary, Rust is able to optimize out some bound checks.

Do note that binary trees are mostly an obsolete legacy today — they are way too cache-unfriendly. I mean you could have written similar code in C++ using std::vector or std::dequeue and get the bounds checking too.

>Everyone talks about memory safety but IMO rust’s best features are enums, traits, cargo, match expressions and so on

C++20 with concepts mostly reproduce the traits. C++17 with std::variants emulate enum/tagged union. Match is unmatched by C++, that's true.

Cargo is good for as long as there are few packages in there. Large projects already suffer from five versions of serde in one build and dependencies on FFI-connected libs that cargo itself cannot build. I mean look at the NPM nightmare — and they've mostly dodged FFI-s.

Post reply on HN