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

551–560 of 811 posts

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

#551

Post by mikebenfield »

ncmncm wrote: post #273
mikebenfield wrote: post #237

Earlier quoted context omitted.

To me C++ is much, _much_ harder than Rust. Maybe in C++ it's easier to get a program to compile, but it's dramatically harder to make sure you've checked all the boxes you're supposed to check to make sure your code is safe and complies with best practices. For instance, consider the rules of 5 [1]. There are so many rules like this in C++, so much complicated stuff you're supposed to know to write anything at all,…

Rule of 5 was a C++11 thing, maybe even mainly a C++03 thing. Your complaints about C++ have aged badly. C++20 is not the same language as C++11, which was not the same language as C++03. Rust's complexity is rapidly approaching C++'s. In 5 years, if Rust hasn't fizzled, it will get there. Only being used to it will make it seem any simpler.

> C++20 is not the same language as C++11, which was not the same language as C++03

This is not a good thing. In fact, it's a shockingly bad thing. C++ is basically 40 years old, and still every few years the C++ community feels like, "OK, now we know how to get C++ right; yeah the old C++ was a mess, but now we just need to add these 12 new features and it'll all be good."

Unfortunately many of the problems with C++ are due to mistakes in its early design. It was wrong from the beginning.

I've been programming Rust for 6 years. C++ for over 20. I'll take Rust every day of the week and twice on Sunday.

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

#553

Post by baq »

pkolaczk wrote: post #460
baq wrote: post #351

Earlier quoted context omitted.

1. garbage collection is amazing for developer productivity if you can afford it. 2. if you don't know if you can afford it, you can.

> 1. garbage collection is amazing for developer productivity if you can afford it. Probably not for everybody. I haven't noticed any significant productivity boost when coming from C++ to Java years back, and then I also can't see any significant productivity decrease when switching from Java to Rust. I feel the unavailability of GC is widely offset by other features that make Rust more productive than Java. Surely,…

> coming from C++ to Java

if you were a competent C++ programmer, yeah, i can absolutely see that; nowadays, most people start with a GC-ed language and get tripped up all the time if things they take for granted aren't there. unsurprisingly.

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

#554

Post by drogus »

hawski wrote: post #516
drogus wrote: post #344

Earlier quoted context omitted.

Just use `Arc`, it's fine, it will be plenty fast.

I always wonder about code bases using bolt-on reference counting. I would count C++ shared_ptr and Rust's Arc among them. At this point wouldn't it be better to just use a regular GC language? What I don't like in modern C++ is that almost everything seems to be heap allocated, when it certainly doesn't need to be. In case of GC language you at least get fast allocations and heap compaction. But it is true that reso…

> At this point wouldn't it be better to just use a regular GC language?

No, because you wouldn't slap `Arc` on every single variable. The example from the blog post is a dispatcher and `Arc` is then needed for dispatched functions. The same might be true for queues and other stuff where you need to move stuff between threads, but other than that it would be mostly `Arc` free.

As an example: when you write a web service in one of the frameworks like Actix, you typically use `Arc` for stuff that you need to share between all of the handlers like DB connections, queues, counters etc. All of the other stuff would be relatively straightforward Rust without much consideration for lifetimes.

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

#555

Post by MauranKilom »

spoiler wrote: post #518
synergy20 wrote: post #501

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…

Unless you change header files deeply engrained into your code base (or your entire code is templates), incremental builds should not reach 10 minutes, not to mention hours...

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

#556

Post by drogus »

ThePhysicist wrote: post #367
drogus wrote: post #344

Earlier quoted context omitted.

Just use `Arc`, it's fine, it will be plenty fast.

That's what I ended up doing, Arc > for sharing stuff between threads, works really well.

I have recently written a blog post about `Arc` and `Mutex` if you want to get an in-depth view on using them: https://itsallaboutthebit.com/arc-mutex/

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

#557

Post by jandrewrogers »

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++.

That is not true of C++. There are many valuable things that are much easier to express in C++ than Rust, owing to C++ being a significantly more expressive language. Rust also doesn't make it easy to write software where ownership is intrinsically ambiguous and must be algorithmically resolved at runtime without wrapping the object, a common case e.g. for high-performance storage.

I would agree that everything is harder in C, though.

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

#558

Post by Hirrolot »

sph wrote: post #451
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).…

Unpopular opinion but the whole memory safe idea is more niche than HN commenters would have us believe. Most of us are writing web apps and services that do not have strict memory requirements nor catastrophic failure modes. Dynamic languages and GC'd languages cover most of what our employers are paying us for: web apps, backend services. It is ironic to build super safe software, then deploying them on kubernetes,…

Completely agree! When you need to compute numbers or deal with raw bytes, you have C. When you need to be high-level, you have Python, Java, C#, etc. Rust is applicable only in areas where you need both a high-level and systems language. Examples include interpreters, operating systems, browsers, game engines, etc. The hype of Rust just exceeds its problem domain.

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

#559

Post by kaba0 »

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.

> Did scala 3 finally clean up the syntax

Well, they didn’t break the existing language, so not sure. It depends on what do you find readable/difficult. Because contrary to the usual opinion on the language, I believe it is not “difficult” - it has much fewer exceptional rules than Java for example. Sure, some features are more expressive and that comes with big responsibility, but to actually answer your question, some implicit usage is indeed cleaned up making it much less magical-looking.

But scala 3 has been a very huge update, including having a new compile flag that will turn to language “null-safe” (so a nullable String will have String | Null as a type). So it might be worth it to have a new look at the language.

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

#560

Post by logicchains »

crabbygrabby wrote: post #539
logicchains wrote: post #535

Earlier quoted context omitted.

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.

>you can adopt easier patterns to async

Can I do this without having to wrap half the libraries in the ecosystem if I want to use them without worrying about async? C# has that issue: the ecosystem buys heavily into async, so it can be hard to avoid it.

Post reply on HN