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

141–150 of 323 posts

Re: My “grand vision” for Rust

#141

Post by jibal »

Ygg2 wrote: post #56
Animats wrote: post #24

This may be too much advanced type theory for a useful language. You can go all the way to formal verification. This is not enough for that. Or you can stop at the point all memory error holes have been plugged. That's more useful. You can go way overboard with templates/macros/traits/generics. Remember C++ and Boost. I understand that Boost is now deprecated. I should work some more on my solution to the back-refere…

> This may be too much advanced type theory for a useful language. Maybe but: - Move fixes Pin - Linear types, prevent memory leaks - potentially effects simplify so many things Each of these functionalities unlock capabilities people have complained about Rust. Namely async, gen blocks, memory leaks.

Yes. The appalling level of ignorance in the comments here and failure to understand the article is disturbing and a little scary ... hopefully it won't get in the way of actually simplifying and unifying the language, generalizing special cases, removing limitations and roadblocks, etc. as outlined in the article.

Re: My “grand vision” for Rust

#142

Post by chirsz »

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…

You can see:

* no-panic: https://docs.rs/no-panic/latest/no_panic/

* Safe Rust has no undefined behavior: https://news.ycombinator.com/item?id=39564755

Re: My “grand vision” for Rust

#143

Post by chiffaa »

simplesocieties wrote: post #122

The rust maintainers need to learn from the mistakes of the c++ design committee and understand that not adding a feature at all is in itself a desirable feature. For example, your section on effects: > Functions which guarantee they do not unwind (absence of the panic effect) * I actually don’t see how this is any more beneficial than the existing no_panic macro https://docs.rs/no-panic/latest/no_panic/ > Functions…

There are ways to handle these effects without bloating up normal applications. For example, using attributes implemented as intrinsics, which wouldn't really affect anything that isn't using them.

The thing is, some of these things are very useful in specific domains, and all these domains are closely related to the ideas of safety. Nondeterminism and IO are important for purity/referential transparency, which is a fairly important effect for business logic IMO. Guaranteed termination matters for formal verification. Unwind removal matters for embedded. I don't think wishing for these things is really all that unwarranted

> I actually don’t see how this is any more beneficial than the existing no_panic macro

no_panic and similar macros are doing a very hacky workaround which isn't really a great static guarantee. The simple fact that building with panic = abort makes the macro useless is an annoyance in and of itself. dtolnay did great when figuring out some path forward but it's somewhat shaky

Re: My “grand vision” for Rust

#144

Post by brabel »

Horusiath wrote: post #130
nemothekid wrote: post #112

Earlier quoted context omitted.

I've been on both sides of the fence here - I've bounced between two camps: 1. Go with a better type system. A compiled language, that has sum types, no-nil, and generics. 2. A widely used, production, systems language that implements PL-theory up until the year ~2000. (Effects, as described in this article, was a research topic in 1999). I started with (1), but as I started to get more and more exposed to (2), you s…

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

Re: My “grand vision” for Rust

#145

Post by rapnie »

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…

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

People say "Rust is more complex to onboard to, but it is worth it", but a lot of the onboarding hurdle is the extra complexity added in by experts being smart. And it may be a reason why a language doesn't get the adoption that the creators hoped for (Scala?). Rust does not have issues with popularity, and the high onboarding barrier, may have positive impact eventually where "Just rewrite it in Rust" is no more, and people only choose Rust where it is most appropriate. Use the right language for the tool.

The complexity of Rust made me check out Gleam [0], a language designed for simplicity, ease of use, and developer experience. A wholly different design philosophy. But not less powerful, as a BEAM language that compiles to Erlang, but also compiles to Javascript if you want to do regular web stuff.

[0] https://gleam.run

Re: My “grand vision” for Rust

#146

Post by anon291 »

ozgrakkurt wrote: post #139
undeveloper wrote: post #120

I'm not sure why people are so deeply scared. these are all pretty neat features for people who will need them (off rip seemingly mostly in the embedded world). It's not like the inclusion of these forces you to use them — I've never had to deal with unsafe rust for shipping web stuff, and I highly doubt I'd have to deal with most of these. For modeling's sake it would be nice to have pattern types and view types, I…

People will push this crap into production codebases and link to these articles when you say you don’t want complexity. Best way to manage is to not make it possible, like go. You indirectly deal with this kind of thing when compiling web server code too. It compiles super slow and can have weird errors. This is because the people who build the web stack in rust used a million traits/generics/macros etc. Even if you…

3 lines of code that may need to change is much more complex than a macro that signals intent.

Re: My “grand vision” for Rust

#147

Post by widdershins »

olalonde wrote: post #135
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…

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.

https://gleam.run

Re: My “grand vision” for Rust

#148

Post by chiffaa »

wewewedxfgdf wrote: post #68

No-one ever has the "Grand Vision" to cut something down to it's essential 25% and delete the rest.

You can't cut down a language without breaking changes. And there fairly often are internal changes to simplify the compiler and the tooling. Just in the latest release, annotation internals were finally fully unified between rustc, cargo, clippy and other tools. This was a fairly considerable effort in deduplicating code. Borrow checker is being rewritten to move to tree borrows, trait resolution is being refactored for a variety of reasons. Code is being simplified where possible, but this doesn't mean Rust doesn't have areas to improve in, especially if there is a goal of replacing Ada/SPARK

Re: My “grand vision” for Rust

#149

Post by chadaustin »

I write Rust for embedded systems and both effects and linear types would be meaningful improvements. Effects especially: if you have multiple cores in a coherent memory domain AND you run with interrupts enabled, you have to deal with three types of mutex:

- data accessed by multiple cores and interrupt handlers must be modified under a spin lock and with interrupts disabled

- data accessed by multiple cores but not interrupt handlers only needs the spin lock

- data accessed by one core but maybe interrupt handlers only needs to pay for disabling interrupts

Depending on your core and how performance sensitive the code is, the costs of the above can vary significantly. It would be nice to encode these rules in the type system.

(Ordered types might be useful for “critical sections” — that is, areas where interrupts are disabled and the interrupt disablement guard absolutely must be dropped in order.)

Re: My “grand vision” for Rust

#150

Post by mastermage »

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.

Odin is more of an alternative C than Go. V is inspired by Go has like nearly the same syntax as Go and alot of Goodies. Like Error Types, Sum Types and more.
Post reply on HN