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

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

#601

Post by foldr » Fri, Jun 03, 2022, 4:45 PM UTC

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

There seems to be a myth that Rust is unusual in being memory safe. All modern GCed languages are memory safe (assuming you don't do anything obviously unsafe like manipulate raw pointers, which some languages might let you do if you really want to).

>It is ironic to build super safe software, then deploying them on kubernetes, written in a GC'd language prone to nil dereference errors.

Nil dereference errors don't demonstrate an absence of memory safety. If the runtime checks for a nil reference before dereferencing and then raises an exception, that's perfectly safe.

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

#602

Post by foldr » Fri, Jun 03, 2022, 4:47 PM UTC

shric wrote: post #573

Georgelemental wrote: post #515

Earlier quoted context omitted.

> Rust only limits you from writing nonsense code This is the ideal, but not always the reality. The Rust borrow checker isn't perfect, so sometimes it rejects code that should work perfectly fine. Hopefully as the language matures (Polonius, GATs, HRTBs…) these cases will become rarer.

Is there a simple example you can point to of rejected code that should work perfectly fine?

A doubly linked list is a classic example. To implement this in Rust you need to use unsafe code.

Come to think of it, an even simpler example is a mutable iterator for a typical data structure. Such iterators usually require 'unsafe' code to implement, even though they are perfectly safe to use. https://stackoverflow.com/questions/63437935/in-rust-how-do-...

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

#603

Post by pjmlp » Fri, Jun 03, 2022, 4:48 PM UTC

NoGravitas wrote: post #593

pjmlp wrote: post #305

Earlier quoted context omitted.

Actually something like traits (as concept) is what powers COM, WinRT, the basis of Objective-C protocols that influenced interfaces in more common OOP languages. Also the basis for one programming language that used to be widespread in the enterprise for quick and dirty solutions, VB and its ecosystem of OCX libraries. It is more widespread that people think, because when many argue about OOP, they miss the full spe…

Traits seem, to me, a lot like generic functions and methods in CLOS (Common Lisp). It's just that CLOS doesn't bundle a group of generic functions into a trait, they're a la carte.

Yes they do, they are called protocols.

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

#604

Post by gary17the » Fri, Jun 03, 2022, 4:48 PM UTC

blub wrote: post #594

gary17the wrote: post #403

While the article is an absolutely excellent analysis of Rust from the low, PL-level ergonomics point of view, it seems to largely miss (or, intentionally, skip) the bird's eye point of view of complexity inherent to software development. I was recently tasked with developing a fragment of a mobile app written in Objective-C++ (an awesome PL powerhorse, BTW) that mixed multi-threaded (multiple dynamic UI layers, mult…

Rust is not an appropriate solution for iOS, I don’t think it’s even possible to use it except through some hacks. So the options aren’t buggy Objective-C++ vs inelegant but safe Rust. It’s having a product vs. not having one and the latter guarantees a lack of commercial success.

I'm not sure what you mean - I mentioned Objective-C++ mobile development only as an example of how challenging multi-threaded/async programming can be. The problem is analogous on other platforms and can be simplified by Rust on the platforms that Rust supports. Also, it wasn't Objective-C++ that was buggy, it was my brain that was bug-prone :). (BTW, when it comes to iOS development, I consider Swift to be significantly more complex than Rust.)

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

#605

Post by WuxiFingerHold » Fri, Jun 03, 2022, 4:57 PM UTC

iex_xei wrote: post #426

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…

> It doesn't allow you to build quick and easy solutions that allows you to lie to yourself

You can write perfectly fine solutions in a GC language without lying to yourself.

> my trust level to my Rust code is around 10x more than my Python code for the same problem

Python as a dynamically typed language is not the mark. Rust has a great static type system, but other GC languages offer that as well.

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

#606

Post by throwaway17_17 » Fri, Jun 03, 2022, 4:59 PM UTC

rfiat wrote: post #494

adastra22 wrote: post #241

Earlier quoted context omitted.

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

As the sibling commentor said, syntax highlighting is only one example meant to illustrate Go's sometimes unnecessarily frustrating design. In case it wasn't clear, the example wasn't that Rob Pike doesn't like syntax highlighting. The example was that Go's playground doesn't have syntax highlighting (even as an option) for a reason as arbitrary as "because I said so". That is why I find Rust and Go to be dissimilar.…

I don't agree with your framing. You are stating a 'moral' proposition, i.e. Rust == Good Ideas AND Go == Bad Ideas, and then applying the 'moral' position to the language as a whole. So you end up saying, in brief (and acknowledging that I do not think you are actually making a moral claim about the qualities of these languages) you are saying Rust is Good, Go is Bad and therefore they are dissimilar. I don't think the reasoning your putting forward actually says anything about the language and there similarity/dissimilarity.

I am not saying that Go and Rust are similar or not. I don't really agree with GP's comment where Go should be in the running for a Rust-with-GC/slightly-higher-level-Rust, but the frankly dismissive Rust Good therefore not similar to Go Bad is not justified. Although the conclusion regarding similarity is probably correct.

Also, this is a little off topic, but I have seen multiple people say that Go 'was designed with a very specific brief - "we want C but with GC and easy concurrency"' and then go on to complain about the lack of things like generics, destructuring match syntax, functional concepts, etc. But, all of those discussion, including your comment, start out with what seems to be an acknowledgement that Go's design had a very specific target. I agree that Go is basically the fulfillment of the brief you gave, i.e. C with GC and easy concurrency. So, when the target is C with two unique things, why does everyone then seem confused that Go doesn't have all of these extra 'good ideas and common sense'.

I'm not trying to turn this into a thread on Go's merits or lack thereof. I just don't understand why so many people seem to think that Go somehow didn't do exactly what it set out to do. You don't have to think what they decided to design was a worthwhile language, but to expect a lion to be a shark, or an apple be a steak, is just illogical.

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

#607

Post by crabbygrabby » Fri, Jun 03, 2022, 5:00 PM UTC

kaba0 wrote: post #559

crabbygrabby wrote: post #534

Earlier quoted context omitted.

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, s…

Null safety sounds great. My big gripe was all of the symbols and how they had different meanings in different contexts. That said, in most cases it's not a real problem, but with a team you can end up with some messy stuff.

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

#608

Post by WuxiFingerHold » Fri, Jun 03, 2022, 5:02 PM UTC

gwbas1c wrote: post #545

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…

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…

Unless you really need the best performance possible there're pretty good alternatives. Mainly C# or Go and soon JVM with Loom.

Some numbers: https://web-frameworks-benchmark.netlify.app/result?l=rust,g...

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

#609

Post by WuxiFingerHold » Fri, Jun 03, 2022, 5:07 PM UTC

HWR_14 wrote: post #561

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…

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

No, C# or Typescript is way easier, as a GC does the memory management for us. Lifetimes in async Rust are one the hardest things.

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

#610

Post by ncmncm » Fri, Jun 03, 2022, 5:08 PM UTC

Diggsey wrote: post #409

ncmncm wrote: post #276

Earlier quoted context omitted.

> Writing widely useful, performant, reusable, correct and stable libraries is very hard. Correct. > Rust is the easiest language to do that in. Wrong. Rust provides very substantially less support to library designers than C++ does. Anyone creating ambitious libraries finds Rust a big step down. Rust might get more of what C++ offers library designers as it matures, but only at the cost of whatever simplicity it can…

> Rust provides very substantially less support to library designers than C++ does. Anyone creating ambitious libraries finds Rust a big step down. Before I used Rust my main language was C++ where I specialized in writing libraries, and this is a ridiculous statement. It's only recently that the C++ standard library has gained enough functionality to do even some basic things in a portable way, so you're relying on…

What makes UB in C++ is spelled out in its International Standard; there is no specification for Rust, just an implementation. It has been many years since C++ preprocessors differed notably from one implementation to the next. Nothing in C++ is global except what you choose to make global.

In fact today C++ lifetimes are expressed in the type system, and this is an example of what C++ enables a library to provide.

If, working as a library designer, Rust was not a big step down, you were neglecting to provide users of your libraries much of the value you could have offered. Your remarks suggest that libraries you delivered were closer to C than C++.