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

761–770 of 811 posts

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

#761

Post by ncmncm »

dgunay wrote: post #698
curun1r wrote: post #620

Earlier quoted context omitted.

I feel like Go was built with primary design considerations that are often not considered publicly and often at odds with what programmers want out of a language. I saw one of the first public talks from the creators at Google I/O and they stressed two things: compilation speed and new developers coming up to speed quickly. From what they said, Google had a few C++ projects with multi-hour compilation times that, whe…

I agree, I've mostly made peace with what Go is and I still enjoy using it. It just tantalizes me because of how close it is to my ideal general-purpose programming language. There is a large middle ground between the minutes-long compile times of Rust and the seconds-long compile times of Go.

If such a compromised process produced something close to your ideal, that should worry you deeply.

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

#762

Post by ncmncm »

mftb wrote: post #100
0des wrote: post #23

Earlier quoted context omitted.

Go and Hare are rust-adjacent with just a touch of crayon involved. I highly recommend both especially Go since you mention rust with GC

Just wacky I had to scroll this far to see Go mentioned. In certain contexts Rust is very impressive, in others Go is a much better choice. I'm really starting to hope that we'll see some of the important advancements in Rust packaged up in a better language.

Go is very deliberately designed for when you depend on a team with sharply limited skills.

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

#763

Post by mftb »

ncmncm wrote: post #762
mftb wrote: post #100

Earlier quoted context omitted.

Just wacky I had to scroll this far to see Go mentioned. In certain contexts Rust is very impressive, in others Go is a much better choice. I'm really starting to hope that we'll see some of the important advancements in Rust packaged up in a better language.

Go is very deliberately designed for when you depend on a team with sharply limited skills.

These one-liners aren't super-constructive, my own comment was hardly in-depth, so whatever...

On any team or in a community your most likely to have a range of skill levels across members. A language can be many things, a powerful tool or a strong barrier.

When I first heard about Rust I thought we were on the verge of getting some real advancements across a much larger community of developers and scope of projects. Instead I think we're headed further down a path of at least 3 major groups of PL (scripting, memory-managed, precise semantics). Who knows, maybe it's for the best. If so we better get busy improving the inter-op.

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

#764

Post by timcavel »

0des wrote: post #656
justinsaccount wrote: post #640

Earlier quoted context omitted.

As someone that writes a bunch of go but has never really gotten off the ground with rust: * Option? I don't mind if err != nil, but sure, it would simplify some things. * Result and real tuples? awesome. * real enums? sign me up. If that was all added to go I wouldn't mind at all. But what does any of that have to do with impl Execute for Dispatcher where H: Fn(&'a Update) -> Fut + Send + Sync + 'a, Fut: Future + Se…

Shit like this makes my brain hurt

No post body was provided.

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

#765

Post by [deleted] »

avidphantasm wrote: post #434
roblabla wrote: post #333

Earlier quoted context omitted.

> Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast. This is so interesting to me. I'm a Rust programmer by trade (as in - I'm not a hobbyist, I actually write Rust for work). We've found that, while the feature work is a bit slower in Rust than in other languages the company used to use (mostly Python), they tend to requ…

I’m still learning Rust, but the idea of having to use unsafe features to implement something as simple as a linked list seems “wrong” to me. What am I missing?

[deleted]

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

#766

Post by pas »

purkka wrote: post #385
pas wrote: post #334

Earlier quoted context omitted.

Rust is young, very ambitious, of course general purpose enough to do everything in it, but its ecosystem has serious gaps. (And some of those are dependent on planned language level features.) ... I spent a lot of time reading r/rust, various blog posts before going beyond helloworld in it. To me it's in the same category as Scala (ZIO) or TypeScript. Both are very powerful, a joy to work with them, until the low-le…

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

Oh I don't think the performance is bad, the JVM is an amazing technological platform, but it uses a lot of RAM, it's GC pauses are bad for latency, and the Scala/Java/JVM ecosystem is simply not that high quality as Rust's. (See all the security issues, log4j2, jdk ecdsa rewrite, just to name the few that come to mind in the last few months.)

And for TS I don't think I have to mention the quality of the underlying JS ecosystem :)

On the other hand, of course Rust is still on 1.x, GAT is still on the roadmap (though the RFC recently entered into final comment period (or how it's called), yaay!, and then a bunch of legitimate criticism was submitted..., so it might still take year(s))

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

#767

Post by hazz99 »

lenkite wrote: post #478
hazz99 wrote: post #330

Earlier quoted context omitted.

I don’t think it’s true that any given “basic” design pattern should should necessarily be simple in every language. Certain things are short and elegant in Rust. Certain things are short and elegant in Python. Each optimises for different things. I also don’t believe it places “extraordinary complexity” on the shoulders of the programmer; this complexity is often a sign you’re doing something wrong, or working again…

Ok, what is wrong about the Rust solution given by the author of this article ? What is he doing wrong ?

They’re not doing anything wrong, but working with generics, traits and async code is very much against the grain of the 2018/2021 editions of Rust.

The async story hasn’t finished, and is definitely the area that needs most improvement in terms of developer experience. There are a number of gated features and RFCs that propose solutions to these problems (e.g. GATs), but they haven’t been moved into the core language yet.

That doesn’t mean Rust is inherently bad or difficult, only that we’re working with an early version. Rust is young! We didn’t have futures until 2019, iirc.

Lots of core Rust concepts (lifetimes, ownership, references) need to be rethought for how they fit into asynchronous programming, and how to make everything compose well together.

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

#768

Post by foldr »

mumblingdrunk wrote: post #757
foldr wrote: post #660

Earlier quoted context omitted.

>Unsafe in rust means you are skirting guarantees given by the language. It doesn't mean the code will blow up when run. It's just an explicit way to tell the compiler you are operating at your own risk. I'm fully aware of this. That's why I put 'unsafe' in quotes. However, it's surely fair to point out that you can't implement doubly linked lists or mutable iterators in Rust without giving up Rust's usual guarantee…

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 don’t ‘get’ Rust.

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

#769

Post by gjvnq »

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.

But Go still doesn't have enuns with data like in Rust.

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

#770

Post by preseinger »

ngrilly wrote: post #650
foldr wrote: post #621

Earlier quoted context omitted.

I'm 100% sure that I understand what safe means in this context. All modern GCed languages are memory safe and will not access invalid memory regions unless you use specifically unsafe features. > One common example is modifying a vector element by reference. If you grab a reference to an item, push something else to the vector, then try to access through that reference, the vector may have re allocated during the pu…

> 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?
Post reply on HN