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

561–570 of 811 posts

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

#561

Post by HWR_14 »

hirrolot wrote: post #507
iex_xei wrote: post #426

Another data point: After writing / (re)writing 20K+ lines of code as a CLI side project in Rust (without touching async), I think I can say it's the best language for me after 20+ years of experience in other languages. I like the compiler, and I learn a lot from clippy. The "hard" part about Rust is you have to "unlearn" some of the basic mechanisms like scope and ownership that you bring from other languages. It d…

> without touching async The pain comes from async. Over time, I came up to this conclusion: if someone tells me that Rust is nice and you only need to change your mind, this person doesn't write async code. Or he/she writes very-very straightforward, if not primitive async code and doesn't touch HOFs, traits, and similar stuff at all. However, when you write networking code, you typically use async. The worst role i…

> The pain comes from async. Over time, I came up to this conclusion: if someone tells me that Rust is nice and you only need to change your mind, this person doesn't write async code.

Async code is a pain in almost any language. Certainly any language that differentiates between async code and non-async code has the async code be a pain.

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

#562

Post by accountofme »

hirrolot wrote: post #507
iex_xei wrote: post #426

Another data point: After writing / (re)writing 20K+ lines of code as a CLI side project in Rust (without touching async), I think I can say it's the best language for me after 20+ years of experience in other languages. I like the compiler, and I learn a lot from clippy. The "hard" part about Rust is you have to "unlearn" some of the basic mechanisms like scope and ownership that you bring from other languages. It d…

> without touching async The pain comes from async. Over time, I came up to this conclusion: if someone tells me that Rust is nice and you only need to change your mind, this person doesn't write async code. Or he/she writes very-very straightforward, if not primitive async code and doesn't touch HOFs, traits, and similar stuff at all. However, when you write networking code, you typically use async. The worst role i…

You might be right on this. I have written a lot of rust and a fair bit of network code, but I never went near async. I'm not exactly sure what my problem with it is, but I started writing rust before async was a thing and always felt more comfortable with finite state machines and polling for network code (I guess I am atypical).

Anyway, I am sorry that you have to use async.

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

#563

Post by ModernMech »

gspr wrote: post #298
ModernMech wrote: post #121

Earlier quoted context omitted.

I do it because the toolchain is so nice. I just do wasm-pack build --target web And it builds a little wasm file and some js shim, and that's all it takes to get a Rust website up and running.

I find that part a hurdle, actually, despite loving Rust. I'm struggling with magic tools like wasm-pack that take over the build process. Cargo is fine – I know what Cargo does and how and why it calls rustc. But finding out what wasm-pack and friends do has been an uphill battle for me. Why can't I just compile to wasm32 with Cargo? What's missing?

As far as I know you can using the wasm32-unknown-unknown target. I think wasm-pack does extra stuff like supporting different targets like a nodejs module or a webpack compatible format, which is outside of the scope of something like cargo imo.

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

#564

Post by Hirrolot »

native_samples wrote: post #379
roblabla wrote: post #333

Earlier quoted context omitted.

> Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast. This is so interesting to me. I'm a Rust programmer by trade (as in - I'm not a hobbyist, I actually write Rust for work). We've found that, while the feature work is a bit slower in Rust than in other languages the company used to use (mostly Python), they tend to requ…

This feels like a common pattern. Languages like Rust and Go seem to pick up a lot of users from the world of dynamic languages, who then incorrectly associate the productivity gains of static typing with the specific language they picked. A lot of programs written in Rust would almost certainly be better off being written in Kotlin. The one in the article is a good example. Why are they writing a messenger bot in Ru…

Well, the dispatcher problem is applicable outside of messenger bots too. But your point is right. I think it was a mistake that teloxide is written in Rust. I just wanted to learn a new language so I was like, why not writing such a library in Rust. Don't make my mistakes.

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

#565

Post by lumost »

One area that I think we'll see some progress on soon is "Ease of use" in Rust. A major change in the last few months for the github trending repositories has been the appearance of full applications built in rust. As more full software products are written we should start to see what works and what doesn't work. IDE support in rust is getting better, but still has a long way to go.

What Rust will likely need is a set of libs similar to Guava, and Guice to make coding actually productive. We already see that starting to emerge with the Tokio ecosystem, however it would be helpful to have stronger support outside of the Async community.

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

#567

Post by logicchains »

HWR_14 wrote: post #561
hirrolot wrote: post #507

Earlier quoted context omitted.

> without touching async The pain comes from async. Over time, I came up to this conclusion: if someone tells me that Rust is nice and you only need to change your mind, this person doesn't write async code. Or he/she writes very-very straightforward, if not primitive async code and doesn't touch HOFs, traits, and similar stuff at all. However, when you write networking code, you typically use async. The worst role i…

> The pain comes from async. Over time, I came up to this conclusion: if someone tells me that Rust is nice and you only need to change your mind, this person doesn't write async code. Async code is a pain in almost any language. Certainly any language that differentiates between async code and non-async code has the async code be a pain.

Writing this kind of async code in Haskell (and to some extent OCaml) is much nicer, because you can abstract over the asyncness of code. This can't be done in Rust or C# because the type system isn't powerful enough (no higher-kinded types). To be fair, adding HKTs to Rust's existing type system is a challenging theoretical problem in itself.

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

#568

Post by mcronce »

paskozdilar wrote: post #368
mikojan wrote: post #260

Earlier quoted context omitted.

I've successfully replaced tokio with the lower-level mio in one such case. After all threads and async serve different purposes: Threads when you're computing a lot, async when you're waiting a lot, no?

> After all threads and async serve different purposes: Threads when you're computing a lot, async when you're waiting a lot, no? It doesn't have to be one or the other. Go uses coroutines and multiplexes them onto multiple OS-level threads (usually as many as there are cores).

That's what tokio does under the hood.

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

#569

Post by hirrolot »

HWR_14 wrote: post #561
hirrolot wrote: post #507

Earlier quoted context omitted.

> without touching async The pain comes from async. Over time, I came up to this conclusion: if someone tells me that Rust is nice and you only need to change your mind, this person doesn't write async code. Or he/she writes very-very straightforward, if not primitive async code and doesn't touch HOFs, traits, and similar stuff at all. However, when you write networking code, you typically use async. The worst role i…

> The pain comes from async. Over time, I came up to this conclusion: if someone tells me that Rust is nice and you only need to change your mind, this person doesn't write async code. Async code is a pain in almost any language. Certainly any language that differentiates between async code and non-async code has the async code be a pain.

> Certainly any language that differentiates between async code and non-async code has the async code be a pain.

Function colouring is not the only problem with async code. The difference is that concurrency in other high-level languages usually don't break down polymorphism and other language features. Also, they don't push you to deal with lifetimes, which is a serious issue in Rusty async.

Writing async code in C# is a lot easier to me than in Rust. Unfortunately, I didn't have a chance to write async in functional languages, such as Haskell or F#, because they are well-known for elegant concurrency.

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

#570

Post by zepearl »

ekidd wrote: post #60
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…

> 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. Even in regular Rust, trying to get too clever with lifetimes can cause serious pain. The usual culprit is complex code that tries to never allocate memory. "Oh, well this closure borrows this parameter from the parent function, and then stores a…

This fully hits what I experienced.

I'm using Rust since ~2 months. At the beginning I was trying to write my usual C/C++ code and I got completely entangled with lifetimes relationships and the code ended up becoming a mess.

Nowadays as soon as the compiler starts mentioning lifetimes I see that as a warning => I then take a step back and change approach/design => no problems.

I use a little bit of async (I create dedicated variables that are moved to the async functions) and classic multithreading (I use "mpsc" to exchange data between the main & subthreads) and so far I never had a single segfault nor any kind of weird behaviour, which is incredible if compared to some other languages at least for my programming skills :)

Post reply on HN