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

541–550 of 811 posts

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

#541

Post by logicchains »

whazor wrote: post #386
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.

Rust makes it easier and faster to create certain classes of applications, specifically applications that originally would be written in C and C++. Things that are hard in Rust, are even harder in C and C++. So Rust is liberating and 'rewriting' complicated applications can be satisfying because you can move faster. For me personally I am playing with Wayland and display streaming and it is very satisfactory so far t…

>Things that are hard in Rust, are even harder in C and C++

This is absolutely not true. Something hard in Rust but almost trivial in C++ (via fold expressions): mapping or folding a function or operator over a tuple of heterogeneous types. E.g. to sum over a tuple of arbitrary numeric types:

    auto mySum = std::apply([](auto... x){ return (x + ...); }, myTuple);

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

#542

Post by fizzynut »

crabbygrabby wrote: post #508
karmakurtisaani wrote: post #441

Earlier quoted context omitted.

I kind of hit a wall with Rust after realizing that something like doubly linked lists are difficult because when two nodes are referring to a node between them, you don't have a clear owner. So basically all situations where you have two or more references to an object need to be thought out carefully, and for me it was a bit of a let down (even though I fully understand the reasoning behind it and why it's useful).…

So here's a weird thought, why should you ever write your own doubly linked list? Why shouldn't you use one that a community of people has vetted and juiced for performance instead? In C what I just said is for some reason heresy. But yes you are right, anytime you have two or more accesses to a data structure you do have to think a little harder about it. Usually you just want to use a reference to that object, some…

Writing your own data structures allows you to write it to suit the specific needs/constraints of your problem/domain. Typically that means you get something that is significantly simpler, faster and with a different feature set.

Libraries are typically optimized for generic use, so are often more complex, slow, and difficult to extend with new features (both coding wise or the features might not be suitable / have trade offs for other people).

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

#543

Post by gwbas1c »

I've been toying with Rust on and off for a few years. I find it very difficult to be productive for many of the same reasons that TFA lists.

> Finally, imagine that Rust’s issues dissapear, it is high-level, and has uniform feature set. That would presumably be close to the theoretical ideal of a high-level, general-purpose programming language for the masses. Funnily enough, designing such a language might turn out to be a less intimidating task than original Rust, since we can hide all low-level details under an impenetrable shell of a language runtime.

Holy smokes yes. Rust introduces some extremely powerful features that other languages seriously need. Matching on an enum (although Rust's also needs a more traditional enum,) is awesome. Rust's error handling, IMO, is a step in the right direction away from exceptions. I even like the fact that I can enforce single ownership of an object; or have methods that take ownership of an object. And, differentiating between mutable versus immutable without needing different types is infinitely valuable.

Furthermore: My favorite feature of Rust is that it's 100% compiled with no need for a framework or runtime.

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

#544

Post by api »

Hirrolot wrote: post #160
api wrote: post #140

Earlier quoted context omitted.

Rust is like C++ in the following way: it has many features and a complex type system, but that doesn't mean you should use all its features all the time! Dancing around with lifetimes can be premature optimization. Yes you can write very efficient code that way but if you find yourself spending tons of time fighting the borrow checker you might be overdoing it. I tend to use Arc a lot in async code. It makes things…

> Rust is like C++ in the following way: it has many features and a complex type system, but that doesn't mean you should use all its features all the time! ... Until third-party libraries push you to use specific features.

I get the async frustration, but keep in mind that there are really only three possible ways of handling this:

(1) Async in the core language and do async I/O.

(2) A fat runtime like Go that implements lightweight concurrency.

(3) Everyone hand-rolls their own implementations of select, kqueue, epoll, etc. loops as well as optimizations like io_uring for every single application.

Rust chose (1) because (2) is off the table as it's a systems language and (3) is more painful and bug-prone than (1).

As for how to implement async: I am having trouble thinking of a significantly better model than Rust and the fact that the Rust community hasn't dramatically improved async shows that a bunch of people who are way smarter than me about languages and type systems are also having a tough time here. Doing async natively in a systems language with virtually no inherent overhead is some seriously difficult stuff.

I personally think the biggest oops with Rust async is the absence of a runtime in the standard library, forcing everyone to pick a third party library and causing fragmentation around which one to use. Tokio seems like the clear winner but having played with both Tokio and Smol I really think the latter is better designed. Tokio does not implement structured concurrency and makes dealing with lifetimes harder. If we used Smol there would be less of a temptation to just throw Arc everywhere and less memory leak bugs around forgotten-about tasks.

(For those curious about the latter: Smol JoinHandles abort when dropped while Tokio just forgets about tasks and leaves them running when handles are dropped.)

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

#545

Post by gwbas1c »

logicchains wrote: post #535
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…

People talk about C++ suffering from its commitment to zero-cost abstraction, but the same thing applies to Rust async. While async may theoretically be the fastest possible way to write asynchronous code, it feels like an order of magnitude more painful than the CSP/channel-based approached used in languages like Go and Clojure (and the upcoming Java Loom). Personally if I had to write async code that required anyth…

I made the mistake of trying to learn Rust while doing async programming.

IMO, when it comes to concurrent, it's a matter of picking your poison:

Threaded Rust: No overhead of a GC, but overhead of context switches and multiple stacks.

NodeJS: No overhead of context switches and multiple stacks, but the overhead of a highly optimized GC. (And I suspect that the GC can do tricks like run when the process is waiting on all tasks.)

Some real data would be very interesting.

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

#546

Post by capableweb »

gwbas1c wrote: post #543

I've been toying with Rust on and off for a few years. I find it very difficult to be productive for many of the same reasons that TFA lists. > Finally, imagine that Rust’s issues dissapear, it is high-level, and has uniform feature set. That would presumably be close to the theoretical ideal of a high-level, general-purpose programming language for the masses. Funnily enough, designing such a language might turn out…

Minor correction: Rust does need a runtime (normally), it's just very small and embedded in the binary, so it mostly seems nonexistent, but it's there :) More info: https://prev.rust-lang.org/en-US/faq.html#does-rust-have-a-r...

Not to take away from your overall point, which I agree with.

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

#547

Post by [deleted] »

crabbygrabby wrote: post #534
kaba0 wrote: post #402

Earlier quoted context omitted.

I don't have too deep knowledge of Scala compilers, but Scala 3 is a huge revamp so I wouldn't be surprised to see it change. Though both of the mentioned cases seems to be easy to "fix" by the JIT compiler -- the JVM is really good at inlining and short-lived objects are almost free.

Did scala 3 finally clean up the syntax. Scala is a difficult language because there are so many ways to do things. I ran away from it after dealing with it professionally off and on for a year. Which is a shame because I did a hobby project with it and it was super fun and liberating compared to old java.

[deleted]

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

#548

Post by spoiler »

synergy20 wrote: post #538
spoiler wrote: post #518

Earlier quoted context omitted.

In my experience this is untrue... I've worked with C++ on and off (albeit, sometimes reluctantly, so maybe I'm projecting some misery) and a lot of errors in C++ can not be caught until it starts pasting the templates. Sometimes it also fails when linking. Sure, you can always go through the whole build/compile process, but for serious C++ projects that's impractical (even with stuff like (s)ccache) because of how l…

I tried rust on and off, since I do not need it for work I never had time to fully dive into it. The news about rust on the web just seems too good to be true, are there any "cons" against modern c++? yes the cargo and tools etc are great, but I can set up a full c++ build env quickly too, not as good but enough for daily coding.

A big con is that the ecosystem is young still. You can generally find stuff for almost anything at this point (even enterprisey stuff like OData client generators), but they're not "established" the same way their C++ equivalents would be.

GUI and Game dev spaces in Rust are very inovativne and in how they solve some problems, and I'm fairly enthusiastic about both spaces, but I'd be reluctant to recommend them for production, because they're still immature/developing compared to anything in C++

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

#549

Post by crabbygrabby »

crabbygrabby wrote: post #508
karmakurtisaani wrote: post #441

Earlier quoted context omitted.

I kind of hit a wall with Rust after realizing that something like doubly linked lists are difficult because when two nodes are referring to a node between them, you don't have a clear owner. So basically all situations where you have two or more references to an object need to be thought out carefully, and for me it was a bit of a let down (even though I fully understand the reasoning behind it and why it's useful).…

So here's a weird thought, why should you ever write your own doubly linked list? Why shouldn't you use one that a community of people has vetted and juiced for performance instead? In C what I just said is for some reason heresy. But yes you are right, anytime you have two or more accesses to a data structure you do have to think a little harder about it. Usually you just want to use a reference to that object, some…

Won't let me reply to fizzynut, but this is a reply to you.

Yes making data structures is important, and the reality of that is, there are people in the ecosystem creating fancy ones which can be leveraged for your use case.

If that doesn't exist then yea you have to write them. Sometimes that's difficult(you need to use unsafe), sometimes it's easyish and you can use all safe(I did this for a graph type). It can be done(lots of people are doing it), but I think what it shows is, data structures can be difficult to do correctly.

In a worst case scenario you could write it in asm inside rust if you really need a low level control, or write it in C/unsafe rust and ffi or just write it in.

Basically worst case scenario in rust is writing something closer to C.

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

#550

Post by drogus »

dgb23 wrote: post #375
drogus wrote: post #349

Earlier quoted context omitted.

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…

As @therockhead replied already: you won't put every single variable behind `Arc`. It will only be for shared state: queues, handlers that you need to move between threads/tasks etc.
Post reply on HN