Rust Is Hard, Or: The Misery of Mainstream Programming • Hacker News Board

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

#771

Post by preseinger » Sun, Jun 05, 2022, 6:17 PM UTC

crabbygrabby wrote: post #497

jstx1 wrote: post #311

Earlier quoted context omitted.

No, it's a selection effect. The stackoverflow most loved metric is people_who_want_to_keep_using_the_language / people_who_have_used_it_in_the_past_year Since Rust is so early in its adoption and there are few jobs, many of the responders are hobbyists who are into Rust, like it and want to keep using; not necessarily people who use it for work. And since you only take into account the people who have used it in the…

Its so hard for me to think someone actually thinks this. Rust really is a great programming language that solves a lot of other problems other languages don't. It does so by introducing a pretty clever paradigm. The rust community is the least toxic programming community I've ever seen. Leaps and bounds away from go lang, python, and light years away from c, etc. Like use your head, is vba therefore the language whi…

> Rust really is a great programming language that solves a lot of other problems other languages don't. It does so by introducing a pretty clever paradigm.

Rust's "pretty clever paradigm" lifts a large set of low-level concerns into the application domain, and consequently makes them the responsibility of the application programmer.

This makes sense for a subset of programming contexts, where the application programmer needs to have and assert specific positions in those domains, in order to produce viable programs.

The problem is that, overall, very few programming contexts actually benefit from this level of specificity. An HTTP service implementing a business-level capability absolutely does not give a shit about ownership lifetimes. The fact that Rust "solves" this category of issues is completely irrelevant to this class of program.

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

#772

Post by preseinger » Sun, Jun 05, 2022, 6:32 PM UTC

crabbygrabby wrote: post #531

lenkite wrote: post #440

Earlier quoted context omitted.

"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 la…

"Correct" isn't a boolean condition of a program.

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

#773

Post by preseinger » Sun, Jun 05, 2022, 6:40 PM UTC

taneq wrote: post #89

yeputons wrote: post #15

Earlier quoted context omitted.

> I care about speed and correctness but Rust makes me also care about ownership and lifetimes even when I don't really want to care about that stuff. I don't think one can care about speed and correctness without caring about lifetimes and ownership. Even if you do not care about memory ownership and use garbage collection, there are plethora of other things that you take care of. For example, if you've juts sent an…

I feel this fact is grossly underappreciated. Caring about speed and correctness but not ownership and lifetimes (and thread safety and race conditions and...) is like caring about road safety but not caring about headlights. You're not avoiding ownership and lifetime problems, you're just avoiding looking at them.

Thread safety, and memory model safety, and all this important stuff, is important! But ownership and lifetimes are models of reality that Rust asserts as part of its domain language, which, like all models, are approximations of reality, not reality itself. They're useful to the extent that they help to solve a given problem. And not all problems fit into the assumptions that they assert.

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

#774

Post by preseinger » Sun, Jun 05, 2022, 6:45 PM UTC

CraigJPerry wrote: post #725

skohan wrote: post #715

Earlier quoted context omitted.

I think this is less clear than. The rust/ swift version.

That’s fascinating, what would you say obscures clarity? Go: https://go.dev/play/p/s4TTZeo7Gse Rust: https://play.rust-lang.org/?version=stable&mode=debug&editio... For me, i reckon the Go type machinery is more verbose in this case, e.g. the isShape method to tag Circle as a shape - that just feels awkward to me. The cyclomatic complexity is identical for both though.

This Go code is wildly non-idiomatic. Type assertions via `.(type)` are a tool of last resort, not something that an application developer should turn to as a solution to a problem, and certainly not post-1.18, which permits generics.

edit: e.g. https://go.dev/play/p/wDO5J8CElSC

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

#775

Post by nimrody » Sun, Jun 05, 2022, 6:54 PM UTC

adgjlsfhk1 wrote: post #719

crabbygrabby wrote: post #654

Earlier quoted context omitted.

That is an option, or if you don't want to deal with a GC because it's eating 70% of your clock cycles under load you can use rust get performance gains and still be writing safe code...

if your GC eats 70% is your clock cycles, your language has a broken GC. in modern Java/C#, GC time is rarely more than 10%

To get to a low GC overhead in Java (and perhaps other languages too) you have to pay with an increase in memory consumption. Sometimes as much as 100% additional RAM to avoid frequent full GC scans.

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

#776

Post by ngrilly » Sun, Jun 05, 2022, 7:45 PM UTC

preseinger wrote: post #770

ngrilly wrote: post #650

Earlier quoted context omitted.

> I can assure you that you cannot access undefined memory regions by doing this in Go. Current implementation of slices and interfaces in Go is not memory safe in presence of data races: https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...

Data races are violations of the memory model; of course any code which produces data races cannot be understood as memory safe?

As far as I remember, some languages like Java are memory safe even if the code produces data races. That means you can't have a reference to a value supposed to be of type A being actually of type B.

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

#777

Post by mumblingdrunk » Sun, Jun 05, 2022, 7:54 PM UTC

foldr wrote: post #768

mumblingdrunk wrote: post #757

Earlier quoted context omitted.

It seems you are slightly misunderstanding the point of 'unsafe' as a concept. And no, memory safety is a huge deal, it is just that the borrow checker cannot verify the soundness of certain code, meaning you have to provide the guarantees normally given to you outside 'unsafe' blocks. Yes, this means that a few data structures require 'unsafe', but you should be creating safe wrappers around these structures; 'unsaf…

> it is just that the borrow checker cannot verify the soundness of certain code And I was just proving examples of such code for someone who asked. Honestly, some Rust folks get so defensive it makes them very prone to misinterpret simple factual statements about Rust as criticism. Apparently you don’t disagree with any of the factual statements that I’m making. You just have some vague unsubstantiated feeling that…

I'm not fighting your claim that the borrow checker has perfectly reasonable situations it can't deal with. That's why 'unsafe' exists. I've already said that.

You're adding other claims and statements that make me question if you actually understand the thing you are criticising.

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

#778

Post by int_19h » Mon, Jun 06, 2022, 2:13 AM UTC

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…

Async in something like C# is much less painful precisely because it doesn't try to be a zero-cost (or at least as low cost as possible) abstraction. When the language can allocate stack frames on the heap implicitly as needed, and there's GC to clean them up, things "just work".

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

#779

Post by int_19h » Mon, Jun 06, 2022, 2:15 AM UTC

hirrolot wrote: post #569

HWR_14 wrote: post #561

Earlier quoted context omitted.

> 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#…

I'm not sure if C# async was derived from F#, but it definitely looks very similar. The main difference is that in F# async is vastly more customizable (but also slower, because the compiler can't make certain assumptions due to said customizability.

https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...

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

#780

Post by int_19h » Mon, Jun 06, 2022, 2:19 AM UTC

Aardwolf wrote: post #734

AnIdiotOnTheNet wrote: post #731

Earlier quoted context omitted.

For a variety of reasons, Zig doesn't do warnings. Personally I don't get the big deal with unused variables being errors, from either direction. I'm not sure what it accomplishes to make them errors and I'm not sure why people complain so much about having to comment them out.

If you comment out a statement, you cannot know for sure how many unused variables this caused unless you visually scan the entire previous code, which can cost time. So the only way to find out is to compile and then have the compiler tell you that it refuses to continue because there's an unused variable at line X. So now you needed to do not one but 2 compiles, to do something that should have taken 1 compile, whi…

I think that one thing that we really need to revisit in PLs is sorting out different kinds of comments. Like, in most languages, a comment is just whitespace, with no semantic distinctions. More recently, docstrings got some special handling. But what's really needed is a kind of comment that's specifically about commenting out code; ideally, working on syntax tree level (so you can comment out one entire {...} block, say), and with the compiler being aware that the stuff inside is code, and handling it accordingly for purposes such as these.