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

Rust Is Hard, Or: The Misery of Mainstream Programming

hirrolot.github.io

Post reply on HN
Print view View original

111–120 of 811 posts

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#111

Post by bobbylarrybobby »

0des wrote: post #24
nullcipher wrote: post #7

Unpopular opinion: I find rust code unreadable. And I consider myself a polyglot. I am sure all those symbols have a special meaning but it's like perl to me. Just throw some random special characters and they all mean something.

Perl did nothing wrong, but I echo the sentiment you have about Rust. Last year I ported a mid size internal project to it as part of a resolution to learn a new language and the experience left me feeling like it was just me who "didnt get it". Building things took a lot longer, not just in the amount of code, but also the compile time. Ultimately compile time was the dealbreaker. On more than one ocassion I'd have…

Rust pro tip: don't compile til you're really done. Use something like cargo check or rust-analyzer to quickly spot errors without wasting time on the rest of compilation.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#112

Post by pclmulqdq »

duped wrote: post #99
the_duke wrote: post #12

Rust does not have to be this hard. Most of the pain here come from the unholy trifactor: combining async, lifetimes and dynamic dispatch with trait object closures; which is indeed very awkward in practice. Async support is incredibly half-baked. It was released as an MVP, but that MVP has not improved notably in almost three years. There are lots of ideas, some progress on the fundamental language features required…

The last thing I would take away from async/await in Rust is that it's "half baked." It's incredibly deeply thought out with years of RFCs, great contribution work that required both low level implementations in nightly and creating extensions to the memory model, and extensive bike shedding and discussion with the community on surface APIs.

Like a lot of things in Rust, it's incredibly well thought out but its implementation just isn't complete to the point that it is usable by other programmers. A lot of Rust libraries and components of the Rust STL are "half baked" in this way.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#113

Post by beltsazar »

While I can see why zero-cost abstractions are important in Rust, I was wondering how much simpler Rust async could have been if zero-cost had not been a hard requirement. The way I see it, Rust async is most useful for IO-bound applications, which can afford some non-zero abstraction CPU cost.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#114

Post by estebank »

koyote wrote: post #47

As someone that has only dabbled in Rust, the post reminds me of C++ and its mind-boggling templating system. Rust even seems to provide you with the multi-page compile errors. Is it really as bad, or does the post only highlight the misery you get when you're working on the fringes of what the language is capable of doing?

> Rust even seems to provide you with the multi-page compile errors.

rustc strives to provide you as much relevant context as possible. When hitting very verbose output, it is a hint that what you're trying to do is difficult and will require considered design that the compiler can't help you with. The compiler is trying to help you clarify your code so that it can understand it.

Looking at the diagnostics shown in the blogpost, I see only one that is indeed terrible[1], but those in particularly are getting less and less verbose as we tackle them one by one with more targeted diagnostics. I also see the lifetime errors (the closure one when you specify the argument type and the on "`Execute` impl is not general enough"), which I wish gave more context.

As support for HRTBs lands, related errors will stop happening as much and the code will indeed work (or the compiler will be able to tell you what alternative syntax you should be using).

And, in a general plea for people writing Rust, when you encounter a subpar diagnostic, file a ticket[2].

[1]: https://hirrolot.github.io/media/rust-is-hard-or-the-misery-... Be aware that this is not exactly what rustc outputs, as some text decoration have been stripped, but that is a lot of text.

[2]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao...

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#115

Post by dagmx »

eternalban wrote: post #82
mynameisash wrote: post #45

I started picking up Rust a bit over two years ago, and it was HARD. I didn't have teammates who knew it to help me out, so I used community resources (/r/rust, exercism.io, etc.) I'm still not great with the language, but I'd say I'm about as proficient in it as anything else. The progress is slow enough that you find many more opportunities to quit, but once you do become productive, I think the hard work really pa…

Rust and Python sit at almost extreme opposite ends of programming paradigms. The question on the table remains if the excessive complexity of the Rust language is factually worth the pain.

While that's true they sit at opposite ends, I find Rust is a really good compiled language to switch to for people used to Python.

For a lot of cases, my rust code is very identical to my Python code when it comes to writing CLI tools or flask like web apps.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#116

Post by dagmx »

adeon wrote: post #10

I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I like Rust's wide ecosystem with high quality packages, the nice type system, traits, the idea that my code generally runs pretty fast even if I'm being lazy about writing good code, and my code usually working correctly if it compiles. I care about speed and correctness but Rust makes me also care about ownership an…

Sounds like you're describing Swift. I'm trivializing it, but Swift is basically a higher level Rust with everything wrapped in an Arc.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#117

Post by HKH2 »

999900000999 wrote: post #62

The syntax is just hard. I tell new programmers to start with either Python or JavaScript. The pay is the same or better, and it's much easier. I've been programing for almost a decade, I still can't understand lower level languages like Rust and C++. Why, if you can design a new language, not make something with the simplicity of Python ? If your going to compile the binary anyway, have the complier figure out the t…

> If you're going to compile the binary anyway, have the compiler figure out the types and optimize.

Rust does have type inference. I normally only use types explicitly when I'm collecting from an iterator, or when I want simpler error messages.

> We need people who use a bit of Python, JavaScript, etc, to make their jobs easier.

I am not a programmer, but I use a bit of Rust to make my job easier.

> Rust has some applications, but it's too hard for most

Debugging scripts is usually harder than debugging Rust, in my experience. Being explicit about things has a lot of benefits in the long run.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#118

Post by Arnavion »

armchairhacker wrote: post #40

I personally believe that Rust is an exceptional language and it’s ahead of its time. Seriously, can you think of any other language with as incredible type system, incredible tooling, incredible performance, incredible package management and general package quality, incredible compilation target support, and practically no few backwards-compatibility quirks? But Rust is a really bad general-purpose language. Because…

>It’s designed for high-performance, low-memory, safe computing.

Meh. If it had been designed for low-memory computing, it wouldn't have had an implicit static global allocator, or a standard library that panics on allocation failures. Currently you have to choose between having no upper bound on your program's memory usage, or using an allocator with an upper bound and accepting that you'll crash on OOM, or giving up on almost the entire third-party crates ecosystem and write with no_std.

The upcoming effort to stabilize std::alloc::Allocator and the A in `Vec` etc doesn't help, because every piece of third-party code that currently uses `Vec` is implicitly using `Vec`, and using other allocators in your own code will do nothing to change that. Heck, libstd's own std::io::Read::read_to_end requires a `Vec`

Maybe someone in the future will invent some bastard child of Zig's comptime, Zig's explicit allocators and everything else from Rust, and that will be the language to rule them all.

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#119

Post by estebank »

crabbygrabby wrote: post #48
Patrol8394 wrote: post #30

I am fluent in C/C++, Java, Scala. I really wanted to like Rust, but it is hard. The borrow checker is hard and the language api is not intuitive and/or ergonomic.

In my opinion, easy rust is easy, hard rust is hard. A lot of people take for granted how hard some things are to do correctly until they are asked to do them correctly. Not saying this to put you down, we all struggle with this until we get over the hump. My best advice for loving errr learning rust is put it aside for a few weeks after being annoyed with it. Survey some other language like idk Haskell, then try it…

If I am allowed to quote myself[1]:

> I have the unsubstantiated theory that experienced developers have a harder time than less experienced developers when learning Rust. You need to forget a lot of constructs that work well enough in the languages you already know because they introduce things that go against the single owner enforcement that Rust has, whereas somebody with less experience will simultaneously accept restrictions as "just the way it is" and not seek out more performant constructs that can be much harder to understand or implement.

> Rust has a curse (it has many, but this one is critical): inefficient code is generally visible. Experienced developers hate to notice that their code is inefficient. They will recoil at seeing Arc>, but won't bat an eye at using Python. I know because I have the same instinct! This makes it much harder to learn Rust for experienced developers because they start with the "simple Rust code that will work but is slightly inefficient" and in an effort to improve it they land squarely in parts of the language they haven't yet developed a mental model for.

TL;DR: Keep Calm and Call .clone()

[1]: https://youtu.be/Z6X7Ada0ugE?t=705

Re: Rust Is Hard, Or: The Misery of Mainstream Programming

#120

Post by josephg »

nicoburns wrote: post #19
adeon wrote: post #10

I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I like Rust's wide ecosystem with high quality packages, the nice type system, traits, the idea that my code generally runs pretty fast even if I'm being lazy about writing good code, and my code usually working correctly if it compiles. I care about speed and correctness but Rust makes me also care about ownership an…

Swift is by far the closest from a language point of view, but alas the ecosystem is all-but-nonexistent outside of the Apple systems.

This is a shame.

Swift could be a lovely general purpose language. I like the balance swift strikes between ease of use, expressiveness and performance. Like, swift has an equivalent of Option - but there’s syntax sugar for it. Rust has String / &str / Etc. To get a SSO string you need to pull in an external crate. Swift just has a built in, good, general purpose SSO string as part of the language.

But adding random half baked features to swift seems to be on the promotion path at Apple. Nothing is well documented. The language doesn’t feel stable and there isn’t much of a broad community like there is with rust, javascript and python. It’s a pity!

Post reply on HN