Live data from Hacker News

Rust Is Hard, Or: The Misery of Mainstream Programming

hirrolot.github.io

531–540 of 811 posts

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

#531
post #386

Earlier quoted context omitted.

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++." Incorrect. This handler-dispatcher problem illustrated in the article is utterly trivial in C++ and many programming languages. No need to struggle and stretch your brain as if you are in the Math olympiad. I am learning Rust myself and I think Rust fans are spreading misinformation and propaganda by saying Rust makes things easier than other languages. No…

Would you agree that it is "easier to do it correctly?" Because rust makes lifetimes explicit? I think that's what rustaceans are trying to say generally.

I don't think anyone is trying to claim that rust is some trivial language. It's not. But it makes systems level concerns explicit, flying blind is much harder in my opinion. The complexity is technically the same, but the language has training wheels that other languages don't.

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

#532

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…

IMHO the time for doing analysis like this is before submitting code, not before compiling it. Ideally you want code without unused variables, implicit type casts, ... in a repository. But when you are locally testing out code you're in progress of writing, it is very unproductive if you have to care about unused variables because you're commenting out one line to see the difference, or change casts everywhere becaus…

Earlier in Rust, I saw people recommending `#![deny(warnings)]` (always turn warnings into errors) but I think the community has shifted since then because I feel like I don't see that as much and instead see people disabling warnings in CI.

Speaking of warnings, something I appreciate about Rust is you only see warnings for your own code and not for your dependencies so you can crank up the warnings to whatever level you want without being blocked by dependencies (minus macros). Granted, there could be times where looking at high risk warnings for dependencies could be important.

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

#533
post #170

The author is 17 and writing code (and posts) at this level? The kids are all right.

> The author is 17 and writing code (and posts) at this level? The kids are all right.

He is a talented kid from Kazakhstan. So nice to see this here after all that Borat nonsense badmouthing Kazakhstan just for cheap gigs.

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

#534
post #402
post #385

Earlier quoted context omitted.

Totally agree. Scala and TypeScript are both usually wonderful to write. Though I might argue that one of Scala's biggest issues in my eyes, performance, is mostly _not_ a JVM limitation. For example, a Scala for-loop calls functions on each iteration, and immutable containers need to be garbage collected for each modification. Both of these could be compiled away in many common cases (like C++ or Rust do, but Scala'…

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.

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

#535

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…

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 anything other than the absolute minimum possible latency, I'd prefer to write Go, and I say that as someone who thinks Go's lack of generics was an absolutely terrible idea.

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

#536
post #355

Earlier quoted context omitted.

This is not the case if you are designing a library. Much of what is routinely used to capture semantics into mainstream C++ libraries is wholly impossible to express in Rust. (C is not even a participant, here.) This is not about template metaprogramming, just ordinary stuff. Most of that difference is in things that happen at compile time, so this is not a question of Turing completeness.

> Much of what is routinely used to capture semantics into mainstream C++ libraries is wholly impossible to express in Rust. (C is not even a participant, here.) This is not about template metaprogramming, just ordinary stuff. Do you have any examples?

All above languages are turning complete, so if you can express it in one you can express it in another. The question isn't can you write it, the question is how hard is it to do, and how performant the code will be.

The heart of C++ is destructors: a bit of code that you can write and the compiler will ensure runs when code goes out of scope/is deleted. You can do this in C by remembering to manually call the right code when doing clean up, but it is easy to forget and thus error pron. (I think Rust has this too?)

C++ gives you the ability to do a virtual base class interface, which - as most people know - just means it writes a vtable behind the scene for you. Sometimes people write a vtable by hand in C: it is just a struct of function pointers, but the syntax to do it in C++ is a lot nicer. If you need an interface of some sort the win goes to C++ because the syntax is a lot nicer. (I'm not sure what Rust does about interfaces, I think it has something)

C++ gives you control over copying structs. In C structs are only copied member wise, if the struct has a pointer you need to keep track of both copies so you don't free it early. In C++ you write a copy function that will make a copy of the pointer. You can do this in C by remembering to call the right function when copying a struct, but the default is the wrong thing. (I'm not sure what rust has here, but at the very least the borrow checker will stop you from making a mistake)

C++ gives you move objects - a way to express that a struct is going out of scope, but only after a different one is taking over the contents. This is a variation of the previous, except that you know the original doesn't need valid data anymore and so you just copy pointers and null them in the original. C doesn't have this concept, you can get around it with use of pointers and manual copying of structs in the right places, but the code is ugly. (again, I'm not sure what rust does, if nothing else the borrow checker should allow the compiler to make some optimizations on this lines)

There are a lot more areas where C++ gives you syntax to write correct code that C does not. Rust intentionally doesn't have some of them (class inheritance has been abused often, but I still find it useful enough in a few cases that I think rust is wrong for throwing it out), and in other cases has come up with a better syntax. Overall I don't know enough about Rust to judge it, but I'll take C over C++ anyday.

Note, the above is about the advantages of C++ over C. C++ has a lot of warts that are out of scope for that discussion. I am not claiming C++ is perfect. If you are starting a new project you should seriously consider your language options - including some not mentioned here)

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

#537

Earlier quoted context omitted.

I am interested in Rust because of its safeguards around multithreaded programming. This is is my main motivation to learn it. What I've found good about rust is its modern toolchain and documentation.

The documentation to get started is outstanding with Rust

The advanced documentation is also incredible and crystalized a lot of cs concepts for me. There is no impedance mismatch between the beginner docs and the advanced ones, they reference extra learning materials... Super greatful for everyone on the documentation team.

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

#538

Earlier quoted context omitted.

using c++17/c++20 with g++'s sanitizers(e.g. undefined behavior) and static analyzers, along with clangd the LSP, they too caught most if not all coding errors at editing time and compiling time. In recent two years once my c++ program compiles warning free, it seems bug-free at the same time.

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.

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

#539

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…

Go now has generics. The performance of using them is hit or miss it seems.

Your opinion is valid, but I would say, if you aren't juicing for the best performance, you can adopt easier patterns to async. There are comments on this post detailing how to go about doing that. Or yea use another language if you want.

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

#540
post #282

Earlier quoted context omitted.

Threads work OK for concurrency in many apps. The developer cost of async may not be worth it in many cases.

I would say that threads work _very well_ for concurrency in _most_ apps. Thread context switches have gotten much much cheaper over the years, and the idea that threads are heavyweight is very outdated.

True, java apps have comfortably run 10s of thousands of threads without issue historically.

Coroutines are nice as they allow trivially writing an app which scales to millions of concurrent operations. Rust is nice as it lets us write code for every occasion, async is awful as it poisons the entire ecosystem. The same result could have been achieved with a few tactically inserted yield statements for I/O and locking which are pretty much the only times that async or coroutines help.

Post reply on HN