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

371–380 of 811 posts

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

#371

Post by pjmlp »

jandrewrogers wrote: post #197
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…

True until C++17.

With C++17, if constexpr, static_assert and type traits provide some tools to make life better, C++20 concepts improve on that front.

Rust macros curently are harder to debug than what for example Visual C++ offers for template debugging.

We are back to primitive expand macro, like in the early Lisp days.

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

#372

Post by pjmlp »

ainiriand wrote: post #248
newuser46547 wrote: post #220

Earlier quoted context omitted.

>mastery of that dark art allows metaprogramming that you could only dream of in other systems languages Can you give an example for this?

Unreal Engine vs Unity. Unreal Engine has a visual editor that allows the developers to accomplish most task without the need of entering the code editor thanks to a visual scripting language, it mirrors the C++ counterpart 100%. I believe it is not possible to do that in C# (Unity language).

Unity is in the process of achieving parity via Unity Visual Scripting.

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

#373

Post by dgunay »

adastra22 wrote: post #241
rfiat wrote: post #101

Earlier quoted context omitted.

It's interesting that you find Go to be Rust-adjacent. Setting aside the USPs of each language (goroutines and borrow checker respectively) and just speaking about the general experience of writing code, I find Go painful for all the reasons that I find Rust pleasant. The best summary I can give of Rust is that it was designed by people who learned from the mistakes of the programming languages that came before it. T…

If your primary criticism of golang is that its creator doesn't like syntax highlighting, then it must be doing pretty good.

It is mostly an example of the mindset that I think GP is trying to illustrate.

Go has nil where Rust has Option.

Go has weird not-quite-tuple returns & if err != nil where Rust has Result.

Go has no real enum concept, where rust has its powerful enums and matching constructs.

Go has generics, but only after a decade of pressure from users (and even then, they are much much less useful than Rust's type system).

I like Go and I feel very productive in it, but its commitment to simplicity is dogmatic in many ways and it very much is missing milestone advancements in PLs from the past several decades. It could easily have been made in the 90s.

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

#374

Post by bkolobara »

I see a lot of people here saying something like "Just use Arc, it will be plenty fast".

As someone who does it all the time, I noticed that code becomes less readable and hard to comprehend that way. Important types stand much less out in function signatures once you have Arc>. Rust is already extremely verbose and adding additional layers to types doesn't help. Not even to mention that now every time you want to access the value you need to do dance with calling .lock().

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

#375

Post by dgb23 »

drogus wrote: post #349
HacklesRaised wrote: post #275

Is rusts most loved status simply Stockholm syndrome? I've really tried with rust, and we simply don't get on. I hear all the arguments about CVEs and wonder if rust will reduce the number of these problems simply by disabling the programmers that create them. I understand the draw, I want to love it, but i think I might not be smart enough.

No it's not. There are tradeoffs, definitely, and one of them is visible in the article: at the moment doing lifetimes and async is hard. But you don't have to do it, most of the time you use `Arc` or `Arc ` and call it a day. In async web frameworks you very rarely need explicit lifetimes, because the workload is mostly isolated - a handler gets an input from the request, you compute the output, you return it. Any s…

If you default to Arc everywhere, aren’t you essentially just implementing a slow GC?

This type of thing comes up of often when people try the language. They re-implement some part of a program, originally written in a fast GC language, and then wonder why it’s slower.

I feel like the power of the language comes through in specific workloads, or when you take the additional time to avoid naive code. That’s why it is so verbose and rich, it gives you more control. And this is something that advocates often clearly state.

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

#376

Post by erk__ »

jandrewrogers wrote: post #197
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…

I would argue that the meta-programming facilities that are in Rust are more expressive and can be used to implement things that are not possible in C++. For example embedded dsl and similar. There is likely some cases where templates can express something that cannot be expressed with generics though.

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

#377

Post by therockhead »

drogus wrote: post #349
HacklesRaised wrote: post #275

Is rusts most loved status simply Stockholm syndrome? I've really tried with rust, and we simply don't get on. I hear all the arguments about CVEs and wonder if rust will reduce the number of these problems simply by disabling the programmers that create them. I understand the draw, I want to love it, but i think I might not be smart enough.

No it's not. There are tradeoffs, definitely, and one of them is visible in the article: at the moment doing lifetimes and async is hard. But you don't have to do it, most of the time you use `Arc` or `Arc ` and call it a day. In async web frameworks you very rarely need explicit lifetimes, because the workload is mostly isolated - a handler gets an input from the request, you compute the output, you return it. Any s…

> In async web frameworks you very rarely need explicit lifetimes, because the workload is mostly isolated - a handler gets an input from the request

Was going to post the same comment. Most of my hobbyist Rust programming has been via the Actix Webframework and I only run into the most trivial of borrow checker issues. I guess my projects are not complex or interesting enough :).

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

#378

Post by FiberBundle »

411111111111111 wrote: post #287
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?

I'm just an average web developer, so I could be wrong here, but that's not my understanding of it. Your application has n threads to begin with, if you use async, these will be utilized to schedule tasks. You're basically trusting your language to properly pause and restart the procedures. If you spawn new threads, these will be managed by your kernel. If that kernel is Linux, that it already has a pretty good algor…

> If you spawn new threads, these will be managed by your kernel. If that kernel is Linux, that it already has a pretty good algorithm to pause and restart them, so you're not really wasting a lot of resources.

Thread context switches are pretty expensive. If you use an async runtime such as tokio, all your tasks will be spawned on a fixed number of threads and you won't have any context switches on a task switch.

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

#379

Post by native_samples »

roblabla wrote: post #333
wheelerof4te wrote: post #318

Earlier quoted context omitted.

This comment right here. For most people who program for a living, the hype over Rust means little. They need to use what is in the industry right now. Often, that is a tried and true language that is relatively easy to learn and use. 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.

> 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 Rust? That doesn't seem like the sort of use case Rust was targeted at. It's also a modern language with a lightweight syntax and pretty good static typing, great refactoring tools etc, but it's way more user friendly. There's no borrow checker because it's GCd, compile times are much faster (at least for the JVM version) etc.

You can also use Kotlin/Native or GraalVM native-image to produce standalone executables that don't need a full JVM, if that's a requirement for your use cases. The native images are astounding. They can start faster than programs written in C and their memory usage is also way less than a typical JVM app. Downside is of course compilation time but you can avoid that by just developing on the normal JVM and then AOT compiling at the end when it's time to release.

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

#380

Post by pkolaczk »

bkolobara wrote: post #374

I see a lot of people here saying something like "Just use Arc , it will be plenty fast". As someone who does it all the time, I noticed that code becomes less readable and hard to comprehend that way. Important types stand much less out in function signatures once you have Arc >. Rust is already extremely verbose and adding additional layers to types doesn't help. Not even to mention that now every time you want to…

Rust pro tip: use type alias. As for using lock() - you'd have to do it in any language in some way. If you have sharing and mutability, you need some kind of synchronization.
Post reply on HN