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

191–200 of 811 posts

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

#191

Post by c-cube »

0des wrote: post #23
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…

Go and Hare are rust-adjacent with just a touch of crayon involved. I highly recommend both especially Go since you mention rust with GC

Hare is not rust adjacent, sorry. It can't even represent the (small) stdlib of rust since it lacks generics, RAII... Not to mention the memory safety. It belongs in a different class of languages.

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

#192

Post by voidhorse »

cmrdporcupine wrote: post #69

I've been doing a lot of Rust the last two weeks. Like others have said, if you stay away from async, it's not that bad. But I also have plenty of experience in OCaml and Standard ML and Scala, and also C++. Still, I'm finding my C++ experience is more hindrance than help most times. Async & Tokio is pure hell if you have any kind of shared mutable state. And also it's tough to fight 20-30 years of programming experi…

couldn’t agree more. I’ve been thinking a bit about rust recently and why it’s hard to write when starting out, and I think needlessly verbose syntax is about 10% of the problem and not enough syntax around borrowing/the memory model is 90% of the problem. In other words, Rust syntax is minimalist in all the wrong places.

A lot of borrow checking related stuff in rust forces you (until you internalize how it works) into a check/compile-fix loop that is horribly inefficient and tedious. if performing moves had special syntax it’d be palpably obvious to even new rust programmers that a move is happening and that assignment does not work as it does in about 99% of other programming languages (in most cases).

also important things that then invert or alter this behavior should also have special syntax. for example, I’m still not sure how any client code is supposed to know that some library type implements Copy (which complicates things further by inverting rusts inversion of typical semantics). seems like the only way is “try it and see” or read the docs. I guess the idea is that you shouldn’t necessarily need to know this, but I do think rust would have benefited from making borrow and memory handling more transparent and obvious with special syntax around it (beyond lifetimes, at point of use, not just in signatures). As it stands it seems to want to give users the control that comes with manual memory management with the sort of “hiding away” of details that GCs traditionally afford

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

#193

Post by voidhorse »

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…

I don’t buy it. To write meaningful C that you actually understand requires all the same knowledge of how computers work, yet C is a tremendously simpler language than rust and has an easy to comprehend memory model.

The difference is all the stuff Rust adds on top of fundamentals to make it easier to write correct code with respect to memory usage (in other words, it’s a sophisticated system to make sure you always pair one malloc with one free and don’t make any of the other mistakes C permits partly as a result of its simplicity)

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

#194

Post by encoderer »

This is not a critique of rust but my experience is that I needed to build something that was distributed cross platform as a statically linked binary. So, I narrowed my choices to Golang and Rust. I wanted to learn rust and was only so/so on golang and really tried. I knew this project would go slower because I’d be picking up a new language but as I was still being brain hurt by rust I peeked at go and it can get a little convoluted but overall it’s a readable language where I felt like I could start writing decent code within days.

Since it was mostly about building something for users and not just my own learning I had to go with go.

Not sure if I will ever learn rust but it would have to be for a hobby project or solve a problem for me that is fundamental to the desired outcome that go, python etc could not.

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

#195

Post by AndrewGaspar »

Hirrolot wrote: post #169
mwcampbell wrote: post #156

Earlier quoted context omitted.

> So much of this pain is caused by premature optimization. Part of the problem is that Rust itself has such lofty aspirations to do it all (particularly "abstraction without overhead"), and is largely successful at that. So if I compromise on efficiency, it feels like my code is unworthy of the language it's written in. Also, it's easy to feel that the slightest inefficiency puts us on a slippery slope to the bloat…

I agree; if you use dynamic `Arc`s almost everywhere in your code, what's the point in a systems PL whose essence is in managing static lifetimes? Sometimes people use Rust just because many other languages suck; they are choosing between two evils: tedious programming in Rust or inadequacies of another language. It should not be like this. This is why I think we need a high-level, no-BS version of Rust.

> This is why I think we need a high-level, no-BS version of Rust.

F# is probably what you're looking for if you want functional-lite programming with a strong type system, but don't want to deal with the pains caused by static resource management.

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

#196

Post by Hirrolot »

jen20 wrote: post #176
Hirrolot wrote: post #169

Earlier quoted context omitted.

I agree; if you use dynamic `Arc`s almost everywhere in your code, what's the point in a systems PL whose essence is in managing static lifetimes? Sometimes people use Rust just because many other languages suck; they are choosing between two evils: tedious programming in Rust or inadequacies of another language. It should not be like this. This is why I think we need a high-level, no-BS version of Rust.

Which parts of Rust would you give up to make this happen? And how would this be implemented?

Hide memory management under a language runtime. Make a single Fn trait/string type instead of multiple ones. Add effect polymorphism to deal with function colours. Remove async/.await and express it using algebraic effects, do the same for streams and iterators.

How it'd be designed and implemented is probably a theme for a separate blog post, not a HN comment.

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

#197

Post by jandrewrogers »

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?

C++ templates are an inscrutable nightmare, the reputation is deserved. Rust is a bit different.

Any software engineer that doesn't have a love/hate relationship with C++ templates is lying. On one hand they are extremely opaque and not user friendly, unnecessarily so. On the other hand, mastery of that dark art allows metaprogramming that you could only dream of in other systems languages -- the modern C++ template facility is extremely powerful. The number of C++ software engineers that achieve this level of metaprogramming mastery is quite small. In fairness, the C++ language has been intentionally evolving to make metaprogramming much easier than it used to be, and it has made massive strides in that direction.

Rust lacks the expressiveness of C++ template metaprogramming facilities in significant ways. However, it is plausible that it will gain them eventually. The question is if it is possible to support advanced metaprogramming without the train wreck that is C++. I think it is eminently possible to do better, the question is how long it will take other systems languages to have metaprogramming expressiveness similar to current incarnations of C++.

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

#198

Post by jjnoakes »

tick_tock_tick wrote: post #126
megous wrote: post #79

Earlier quoted context omitted.

Re: fearless concurrency... Would Rust prevent you in general from writing code that could deadlock, btw? Thread1: takes lock A, ..., tries to take lock B Thread2: takes lock B, ..., tries to take lock A Looks like you should be able to pass Mutex and Mutex to both threads otherwise what's the point of mutex if there's no way to share data protected by it, so it doesn't look like it prevents you from hitting this sce…

I'm pretty sure "fearless concurrency" is just a meme at this point since Rust does very little to make concurrency "fearless".

Very little except statically removing an entire class of bugs that plague other languages in the same design space you mean.

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

#199

Post by DeathArrow »

>So why Rust is so hard?

Rust is a systems language. To be a systems PL, it is very important not to hide underlying computer memory management from a programmer. For this reason, Rust pushes programmers to expose many details that would be otherwise hidden in more high-level languages. Examples: pointers, references and associated stuff, memory allocators, different string types, different Fn traits, std::pin, et cetera.

Rust is a static language. This is better explained in my previous essay “Why Static Languages Suffer From Complexity”. To restate, languages with static type systems (or equivalent functionality) tend to duplicate their features on their static and dynamic levels, thereby introducing statics-dynamics biformity. Transforming a static abstraction into its dynamic counterpart is called upcasting; the inverse process is called downcasting. Inside push_handler, we have used upcasting to turn a static handler into the dynamic Handler type to be pushed to the final vector.

C and C++ are both systems languages and static typed languages (I don't know of any systems language which is dynamic typed) and don't feel to me so hard.

C# has "pointers, references and associated stuff, memory allocators, different string types" as features but it is at the same time a higher level language and you make use of those features only when you need to deal with low level stuff, no pain implied.

So, to me, these reasons don't quite explain why "Rust is hard".

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

#200

Post by jjnoakes »

jjtheblunt wrote: post #188
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…

> There are almost no active / popular libraries related to network IO that haven't switched over. wouldn't Go afficianados say Go is a counterexample right under every Rust programmer's nose?

How is go a counterexample to the rust library situation?
Post reply on HN