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

61–70 of 323 posts

Re: My “grand vision” for Rust

#61

Post by russdill »

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…

I think part of the idea is you and to make it impossible to misuse an underlying API. This can make development much less complex.

Re: My “grand vision” for Rust

#62

Post by Cpoll »

throwaway27448 wrote: post #41
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…

> You can go way overboard with templates/macros/traits/generics. You can go overboard on any language concept imaginable, but conflating all these mechanisms makes it sound like you haven't interacted much with non-C++ languages—particularly since rust doesn't have templates or anything like templates, traits are an entirely unrelated composition mechanism, and macros are entirely unrelated to the type discussion in…

Agreed. Generics are in most modern typed languages, and traits are essentially interfaces. Maybe templates means C++ templates, which are essentially generics?

Re: My “grand vision” for Rust

#63

Post by tensor »

wofo wrote: post #30
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…

Thanks for posting this! As a long-time Rust user (and contributor, in the good old days), the thing that has always fascinated me about Rust is the healthy balance it strikes between academic brilliance and industry pragmatism. Radical changes like the ones suggested by the OP risk damaging that balance IMO. I'd rather put up with some language quirks and see Rust achieve "boring technology" status... But who knows,…

How are these suggestions not pragmatic? You don't have to use them, but if you need them they are there. From a security point of view I can see many of these being incredibly useful.

Re: My “grand vision” for Rust

#64

Post by aw1621107 »

pjmlp wrote: post #52
aw1621107 wrote: post #51

Earlier quoted context omitted.

> when mixing crates from various editions and how changes interact together. Could you elaborate more on this? It's not obvious to me right now why (for example) Crate A using the 2024 edition and Crate B using the 2015 edition would require both full access to both crates' source beyond the standard lack of a stable ABI.

Because in order to have standard library breaking changes across editions, if those types are exposed in the crate public types, or change their semantics across editions, the compiler has to be able to translate between them when generating code. See the Rust documentation on what editions are allowed to change, and the advanced migration guide on examples regarding manual code migration. Not so much what has happe…

What you're describing sounds more like a potential issue with editions if/when they allow breaking stdlib changes more than a problem with editions as they exist today, which is more what I took the original comment to be talking about.

Re: My “grand vision” for Rust

#65

Post by usrusr »

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…

Counterpoint: if any language could thrive in that valley of despair between pragmatic and theoretical excellence you're referring to, it would be Rust. Because so much of the cost is already paid for once you have satisfied the borrow checker. At least that's what I'd imagine, I could certainly be wrong.

Re: My “grand vision” for Rust

#66

Post by Animats »

wofo wrote: post #30
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…

Thanks for posting this! As a long-time Rust user (and contributor, in the good old days), the thing that has always fascinated me about Rust is the healthy balance it strikes between academic brilliance and industry pragmatism. Radical changes like the ones suggested by the OP risk damaging that balance IMO. I'd rather put up with some language quirks and see Rust achieve "boring technology" status... But who knows,…

The lack of use cases in that document is a concern. They're all "nice to have" features, but is the payoff there for real work? The "effects" section mentions properties useful for a proof system. But it's not part of a proof system. If it were, most of those could be found automatically by static analysis, without bothering the programmer. (I was doing that decades ago in a very early proof of correctness system.) Getting programmers to annotate items is tough. Just getting C++ programmers to use "const" enough is hard.

"View types" are interesting. But how much of that generality is really needed? We already have it for arrays, with "split_at_mut" and its friends. That's a library function which uses "unsafe" but exports a safe interface. The compiler will already let you pass two different fields of a struct as "&mut". That covers the two most pressing cases.

Re: My “grand vision” for Rust

#69

Post by usrusr »

tensor wrote: post #63
wofo wrote: post #30

Earlier quoted context omitted.

Thanks for posting this! As a long-time Rust user (and contributor, in the good old days), the thing that has always fascinated me about Rust is the healthy balance it strikes between academic brilliance and industry pragmatism. Radical changes like the ones suggested by the OP risk damaging that balance IMO. I'd rather put up with some language quirks and see Rust achieve "boring technology" status... But who knows,…

How are these suggestions not pragmatic? You don't have to use them, but if you need them they are there. From a security point of view I can see many of these being incredibly useful.

If it slows down Rust development it's not pragmatic. And if it creates a cultural schism between full commitment and pragmatic approaches, it's also trouble. Remember Scala?

Re: My “grand vision” for Rust

#70

Post by mihaelm »

Cpoll wrote: post #62
throwaway27448 wrote: post #41

Earlier quoted context omitted.

> You can go way overboard with templates/macros/traits/generics. You can go overboard on any language concept imaginable, but conflating all these mechanisms makes it sound like you haven't interacted much with non-C++ languages—particularly since rust doesn't have templates or anything like templates, traits are an entirely unrelated composition mechanism, and macros are entirely unrelated to the type discussion in…

Agreed. Generics are in most modern typed languages, and traits are essentially interfaces. Maybe templates means C++ templates, which are essentially generics?

My guess is they meant metaprogramming in general (templates/generics, macros), but traits are not quite like the others.
Post reply on HN