Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My “grand vision” for Rust

blog.yoshuawuyts.com

Post reply on HN
Print view View original

151–160 of 323 posts

Re: My “grand vision” for Rust

#151

Post by awesan »

sam0x17 wrote: post #127
QuantumNoodle wrote: post #94

I write production Rust code that becomes critical infra for our customers. I got tired of nil checks in Go and became a squeaky wheel in incident retros, where I finally got the chance to rewrite parts of our system in Rust during a refactor. I admit the skill issue on my part, but I genuinely struggled to follow the concepts in this article. Working alongside peers who push Rust's bleeding edge, I dread reviewing t…

I feel you, but hear me out. OP is right. I've wanted pretty much everything he's talking about here for years, I just never thought of all of this in as quite a formal way as he has. We need the ability to say "this piece of code can't panic". It's super important in the domains I work in. We also need the ability to say "this piece of code can't be non-deterministic". It's also super important in the domains I work…

IMO rust started at this from the wrong direction. Comparing to something like zig which just cannot panic unless the developer wrote the thing that does the panic, cannot allocate unless the developer wrote the allocation, etc.

Rust instead has all these implicit things that just happen, and now needs ways to specify that in particular cases, it doesn't.

Re: My “grand vision” for Rust

#153

Post by ChadNauseam »

ozgrakkurt wrote: post #137
pornel wrote: post #111

It's hard to see features through the programming language theory jargon, but solid theoretical foundations have worked well for Rust so far. Jargon terms like "sum types" or "affine types" may seem complicated, but when you see it's actually "enums with data fields", it makes so much sense, and prevents plenty of state-related bugs. Proposed "effects" mean that when you're writing an iterator or a stream, and need t…

What worked for rust is having enums, sane-ish error handling, having sane integer types and the borrow checker, good tooling. The rest is just not that useful compared to how much garbage it creates

You didn't mention parametric polymorphism, which is incredibly useful and important to the language. I'm guessing you intentionally excluded async, but to describe it as "not that useful" would just be wrong, there is a large class of programs that can be expressed very simply using async rust but would be very complicated to express in sync rust (assuming equivalent performance).

Re: My “grand vision” for Rust

#154

Post by usrnm »

simonask wrote: post #79
phplovesong wrote: post #67

async rust is the worse async out there. I prayed that rust did not include a async at all. But the JS devs pushed it thru. That pretty much sealed my rust use. Im still salty.

You know what, I’ve heard people say this and thought “OK, maybe these other languages with GCs and huge runtimes really do something magical to make async a breeze”. But then I actually tried both TypeScript and C#, and no. Writing correct async code in those languages is not any nicer at all. What the heck is “.ConfigureAwait(false)”? How fun do you really think debugging promise resolution is? Is it even possible…

Try golang, where they did the only sane thing: everything is async from the very beginning, no function colouring

Re: My “grand vision” for Rust

#155

Post by ChadNauseam »

rapnie wrote: post #145
sam0x17 wrote: post #127

Earlier quoted context omitted.

I feel you, but hear me out. OP is right. I've wanted pretty much everything he's talking about here for years, I just never thought of all of this in as quite a formal way as he has. We need the ability to say "this piece of code can't panic". It's super important in the domains I work in. We also need the ability to say "this piece of code can't be non-deterministic". It's also super important in the domains I work…

Perhaps there are similarities to Scala, from my anecdotal observation. Coming from Java and doing the Scala coursera course years ago, it feels like arriving in a candy shop. All the wonderful language features are there, true power yours to wield. And then you bump into the code lines crafted by the experts, and they are line for line so 'smart' they take a real long time to figure out how the heck it all fits toge…

I honestly just don't believe that Rust is more complex to onboard to compared to languages like Python. It just does not match my experience at all. I've been a professional rust developer for about three years. Every time I look at python code, it's doing something insane where the function argument definition basically looks like line noise with args and kwargs, with no types, so it's impossible to guess what the parameeters will be for any given function. Every python developer I know makes heavy use of the repl just to figure out what methods they can call on some return value of some underdocumented method of a library they're using. The first time I read pandas code, I saw something along the lines of df[df["age"] Don't get me wrong, rust has plenty of "weird" features too, for example higher rank trait bounds have a ridiculous syntax and are going to be hard for most people to understand. But, almost no one will ever have to use a higher rank trait bound. I encounter such things much more rarely in rust than in almost any other mainstream language.

Re: My “grand vision” for Rust

#156

Post by pansa2 »

brabel wrote: post #144
Horusiath wrote: post #130

Earlier quoted context omitted.

> 1. Go with a better type system. A compiled language, that has sum types, no-nil, and generics. I was looking for something like that and eventually found Crystal ( https://crystal-lang.org ) as a closest match: LLVM compiled, strong static typing with explicit nulls and very good type inference, stackfull coroutines, channels etc.

Crystal is a typed Ruby. The closer to Go language would probably be Odin.

Crystal’s syntax is similar to Ruby’s, but AFAIK the similarity more-or-less ends there.

Re: My “grand vision” for Rust

#157

Post by gignico »

QuantumNoodle wrote: post #94

I write production Rust code that becomes critical infra for our customers. I got tired of nil checks in Go and became a squeaky wheel in incident retros, where I finally got the chance to rewrite parts of our system in Rust during a refactor. I admit the skill issue on my part, but I genuinely struggled to follow the concepts in this article. Working alongside peers who push Rust's bleeding edge, I dread reviewing t…

I think the misunderstanding here is that the article was not intended to users but to other language designers.

As a user, using a feature such as pattern types will be natural if you know the rest of the language.

Do you have a function that accepts an enum `MyEnum` but has an `unreachable!()` for some variant that you know is impossible to have at that point?

Then you can accept a `MyEnum is MyEnum::Variant | MyEnum::OtherVariant` instead of `MyEnum` to tell which are the accepted variants, and the pattern match will not require that `unreachable!()` anymore.

The fact someone does not know this is called "refinement types" does not limit their ability to use the feature effectively.

Re: My “grand vision” for Rust

#158

Post by hrmtst93837 »

zozbot234 wrote: post #9
ozgrakkurt wrote: post #4

This sounds insane at this point. The language already has too many features. Would be cool if all these people with amazing visions could move it elsewhere. Rust is fast tracking being as bad as c++ in terms of just garbage in it. IMO the worst thing about c++ isn't that it is unsafe but it is extemely difficult to learn to a satisfying degree. This is already kind of feels true for Rust and it will be surely true i…

> The language already has too many features. That's actually the point. Many of these additions can be phrased as unifying existing features and allowing them to be used in previously unusable ways and contexts. There's basically no real increase in user-perceived complexity. The Rust editions system is a key enabler of this, and C++ has nothing comparable.

[flagged]

Re: My “grand vision” for Rust

#159

Post by ozgrakkurt »

ChadNauseam wrote: post #153
ozgrakkurt wrote: post #137

Earlier quoted context omitted.

What worked for rust is having enums, sane-ish error handling, having sane integer types and the borrow checker, good tooling. The rest is just not that useful compared to how much garbage it creates

You didn't mention parametric polymorphism, which is incredibly useful and important to the language. I'm guessing you intentionally excluded async, but to describe it as "not that useful" would just be wrong, there is a large class of programs that can be expressed very simply using async rust but would be very complicated to express in sync rust (assuming equivalent performance).

Yes rust async isn’t good imo. You can do basically the same thing with stackfull coroutines.

Also the ecosystem is setup so you have to use tokio and everything has to be an Arc.

Re: My “grand vision” for Rust

#160

Post by hardwaresofton »

hardwaresofton wrote: post #105

Really excited for the possibilities here. People undoubtedly thought going for Affine types was too much, and even simple things like null safety or enums-with-values and the prevalence of Result saw debate with minimalists voicing concerns. A world where you could write a Rust program that is memory leak free with Affine types is one I want to live in. Haskell can do it now, but its just not easy and Rust has beat…

*linear types (the leak free future bit)

This description is also a good crystallization of why one would want linear types

Post reply on HN