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

261–270 of 323 posts

Re: My “grand vision” for Rust

#261

Post by QuantumNoodle »

abeppu wrote: post #235
QuantumNoodle wrote: post #226

Earlier quoted context omitted.

I have no argument against using the right tool for a job. Decorating a function with a keyword to have more compile-time guarantees does sound great, but I bet it comes with strings attached that affect how it can be used which will lead to strange business logic. Anecdotally, I have not (perhaps yet) run into a situation where I needed more language features, I felt rust had enough primatives that I could adapt the…

> Could you share a situation where the behavior is necessary? I am curious if I could work around it with the current feature set. But this kinda isn't about "behavior" of your code; it's about how the compiler (and humans) can confidently reason about your code?

Sorry I don't understand. The result we all want is at compile-time ensuring some behavior cannot happen during runtime. OP argues we need for features built into the language, I am trying to understand what behavior we cannot achieve with the current primatives. So far the only compelling argument is embedded applications have different requirements (that I personally cannot speak to) that separate their use case from, say, deploying to a server for your SaaS company. No doubt there are more, I am trying to discover them.

I am biased to think more features negatively impact how humans can reason about code, leading to more business logic errors. I want to understand, can we make the compiler understand our code differently without additional features, by weidling mastery of the existing primatives? I very well may be wrong in my bias. But human enginuity and creativity is not to be understated. But neither should lazyness. Users will default to "out of box" solutions over building with language primatives. Adding more and more features will dilute our mastery of the fundamentals.

Re: My “grand vision” for Rust

#262

Post by ozgrakkurt »

kibwen wrote: post #236
ozgrakkurt wrote: post #159

Earlier quoted context omitted.

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.

> You can do basically the same thing with stackfull coroutines. It's clear that you don't understand the use cases that async in Rust was designed to accommodate. > Also the ecosystem is setup so you have to use tokio and everything has to be an Arc. It's clear that you're not at all familiar with the Rust async ecosystem, including Embassy.

I understand what that is but I just don’t care. I am guessing the vast majority of people using rust also don’t care. Justifying the decision to create this mess by saying it is for embedded makes no sense to me.

Also don’t understand why you would use rust for embedded instead of c

Re: My “grand vision” for Rust

#263

Post by gignico »

thomasmg wrote: post #253
gignico wrote: post #157

Earlier quoted context omitted.

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

> the article was not intended to users but to other language designers. That might be true, but it shows the direction that Rust is talking: put in the kitchen sink, just like C++ and Scala did. And _that_ is very much important for users.

I'm not sure it shows that. Even basic features of Rust we take from granted come from concepts common users do not need to understand. Borrowing of lifetime draws from affine types, but nobody cares when writing Rust code. If in 2012 you read a similar article explaining borrow checking in academic terms you would have thought Rust would be unusably hard, which is not.

Also I do not think that adding features is always bad to the point of comparing with Scala. Most of the things the article mentions will be almost invisible to users. For example, the `!Forget` thing it mentions will just end up with users getting new errors for things that before would have caused memory leaks. What a disgrace!

Then, pattern types allow you to remove panics from code, which is super helpful in many critical contexts where Rust is used in production, even in the Linux kernel once they will bump the language version so far.

Re: My “grand vision” for Rust

#264

Post by olalonde »

secondcoming wrote: post #207
olalonde wrote: post #135

Earlier quoted context omitted.

Can we get a version of Rust that swaps lifetimes and ownership for a GC and a JS-style event loop? I love the DX of the language, but I don't always need to squeeze out every microsecond of performance at the cost of fighting the borrow checker.

Then why are you using rust for these tasks?

I'm not.

Re: My “grand vision” for Rust

#265

Post by VorpalWay »

ozgrakkurt wrote: post #159
ChadNauseam wrote: post #153

Earlier quoted context omitted.

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.

No, stackful coroutines requires a runtime. Not going to work on embedded, which is where async rust shines the strongest.

If you don't care about embedded that is fine. But almost all systems in the world are embedded. "Normal" computers are the odd ones out. Every "normal" computer has several embedded systems in it (one or more of SSD controller, NIC, WiFi controller, celular modem, embedded controller, etc). And then cars, appliances, cameras, routers, toys, etc have many more.

It is a use case that matters. To have secure and reliable embedded systems is important to humanity's future. We need to turn the trend of major security vulnerabilities and buggy software in general around. Rust is part of that story.

Re: My “grand vision” for Rust

#266

Post by VorpalWay »

ozgrakkurt wrote: post #262
kibwen wrote: post #236

Earlier quoted context omitted.

> You can do basically the same thing with stackfull coroutines. It's clear that you don't understand the use cases that async in Rust was designed to accommodate. > Also the ecosystem is setup so you have to use tokio and everything has to be an Arc. It's clear that you're not at all familiar with the Rust async ecosystem, including Embassy.

I understand what that is but I just don’t care. I am guessing the vast majority of people using rust also don’t care. Justifying the decision to create this mess by saying it is for embedded makes no sense to me. Also don’t understand why you would use rust for embedded instead of c

Embedded systems vastly outnumber classical computers. Every classical computer has several embedded systems in them. As does appliances, cars, etc. So yes they are an incredible important use case to secure our modern infrastructure.

Re: My “grand vision” for Rust

#268

Post by nmilo »

Rust is the wrong language for effects ironically because of its strict typing. They would probably decide that all effects have to be specified on every function or that any change in capabilities is a breaking change. Which is safest, but horrible for dev ex. Whereas Go most people would just be like “yeah, Hyrum’s law, sorry I broke your weird effect consumer, I don’t really care.”

Re: My “grand vision” for Rust

#269

Post by zozbot234 »

gignico wrote: post #263
thomasmg wrote: post #253

Earlier quoted context omitted.

> the article was not intended to users but to other language designers. That might be true, but it shows the direction that Rust is talking: put in the kitchen sink, just like C++ and Scala did. And _that_ is very much important for users.

I'm not sure it shows that. Even basic features of Rust we take from granted come from concepts common users do not need to understand. Borrowing of lifetime draws from affine types, but nobody cares when writing Rust code. If in 2012 you read a similar article explaining borrow checking in academic terms you would have thought Rust would be unusably hard, which is not. Also I do not think that adding features is alw…

> If in 2012 you read a similar article explaining borrow checking in academic terms you would have thought Rust would be unusably hard, which is not.

Ironically, Rust was unusably hard prior to the late-2018 edition. So now your academic article has to explain both the baseline borrow checker and non-lexical lifetimes, a vast increase in complexity.

Re: My “grand vision” for Rust

#270

Post by jandrewrogers »

ozgrakkurt wrote: post #159
ChadNauseam wrote: post #153

Earlier quoted context omitted.

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.

A stackfull coroutine is brittle and doesn't compose as cleanly as stackless coroutines. As a default language primitive, the latter is almost always the robust choice. Most devs should be using stackless coroutines for async unless they can articulate a technical justification for introducing the issues that stackfull coroutines bring with them.

I've implemented several stackfull and stackless async engines from scratch. When I started out I had a naive bias toward stackfull but over time have come to appreciate that stackless is the correct model even if it seems more complicated to use.

That said, I don't know why everyone uses runtimes like tokio for async. If performance is your objective then not designing and writing your own scheduler misses the point.

Post reply on HN