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

41–50 of 323 posts

Re: My “grand vision” for Rust

#41

Post by throwaway27448 »

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

This isn't really "advanced type theory" so much as picking up programming language developments from the 90s. I suppose it's "advanced" in the sense that it's a proper type system and not a glorified macro ala templating, but how is that a bad thing?

Re: My “grand vision” for Rust

#43

Post by wolvesechoes »

LiamPowell wrote: post #15
satvikpendem wrote: post #10

Earlier quoted context omitted.

It doesn't have too many features, it arguably does not have enough. The issue is that the current features don't play nicely with each other, so much of the work has been in making sure they do, such as with async traits as an example: there is no reason why you can make a function async but not inside a trait, and this was the case until very recently. Beyond that, what the article shows is exactly what I want, I w…

This inevitably happens when the approach to language design is "try it and see". I know people here hate design-by-committee, but historically it's led to some very cohesive languages.

> design-by-committee

I don't think it is about having committee, but rather having a spec. And I mean spec, not necessarily ISO standard. There should be a description of how specific features work, what is expected behavior, what is unexpected and should be treated as bug, and what is rationale behind specific decision.

Coincidentally people here hate specs as well, and that explains some things.

I know there is some work on Rust spec, but it doesn't seem to progress much.

Re: My “grand vision” for Rust

#44

Post by pkal »

From the historical sources I could find online, it appears that Rust's borrow system was independently invented, or at least they don't mention linear logic or anything substructural. This is kind of interesting to me, especially given the reactions in this thread, and ties into the general difficulty of PL research to find acceptance among practitioners, especially when presented by researchers (which I think is regretful, I like the ideas in the article!). Perhaps we really should stick to terminology like "function colors" to make effect systems more popular (or not, because the color framing makes it sound bad to have different colors in a program, IIRC).

Re: My “grand vision” for Rust

#45

Post by SkiFire13 »

pjmlp wrote: post #31
zozbot234 wrote: post #9

Earlier quoted context omitted.

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

It has clang tidy, -std=lang-version, and preprocessor that is version aware. Rust editions don't cover all use cases that one can think of regarding language evolution, and requires full access to source code.

> requires full access to source code

What do you mean? Editions don't require full access to source code. Rust in general relies heavily on having access to source code, but that has nothing to do with how editions work

Re: My “grand vision” for Rust

#46

Post by SkiFire13 »

satvikpendem wrote: post #10
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…

It doesn't have too many features, it arguably does not have enough. The issue is that the current features don't play nicely with each other, so much of the work has been in making sure they do, such as with async traits as an example: there is no reason why you can make a function async but not inside a trait, and this was the case until very recently. Beyond that, what the article shows is exactly what I want, I w…

Re: async in traits, the feature was delayed because it relied on the "Generic Associated Types" and "Impl Trait in Traits" features. If Rust delayed the whole `async` feature for working on those pretty type-theoretic features what would you have thought?

Re: My “grand vision” for Rust

#47

Post by zozbot234 »

SkiFire13 wrote: post #45
pjmlp wrote: post #31

Earlier quoted context omitted.

It has clang tidy, -std=lang-version, and preprocessor that is version aware. Rust editions don't cover all use cases that one can think of regarding language evolution, and requires full access to source code.

> requires full access to source code What do you mean? Editions don't require full access to source code. Rust in general relies heavily on having access to source code, but that has nothing to do with how editions work

You can write a binary library that exposes a C ABI using Rust (which is indistinguishable from an ordinary C/C++ library) and then provide source for a Rust wrapper crate that provides a "safe" interface to it, much like a C header file.

Re: My “grand vision” for Rust

#48

Post by pjmlp »

SkiFire13 wrote: post #45
pjmlp wrote: post #31

Earlier quoted context omitted.

It has clang tidy, -std=lang-version, and preprocessor that is version aware. Rust editions don't cover all use cases that one can think of regarding language evolution, and requires full access to source code.

> requires full access to source code What do you mean? Editions don't require full access to source code. Rust in general relies heavily on having access to source code, but that has nothing to do with how editions work

Yes they do, when mixing crates from various editions and how changes interact together.

Re: My “grand vision” for Rust

#49

Post by satvikpendem »

pjmlp wrote: post #32
satvikpendem wrote: post #13

Earlier quoted context omitted.

I doubt those languages would have the same level of traction as Rust, especially now that Rust has already gotten said traction over the past decade with even the Linux kernel using them. It's more likely that Rust will be written as today and then these extra features are added for more type safety in certain functions as like I said in another comment I doubt people are going to write type contracts for every sing…

Apparently you missed Swift. Linux kernel adoption of Rust hasn't been a smooth ride, exactly because of its type system among C folks. It is only happening because the likes of Google and Microsoft want to see it through.

Swift is not really for systems level programming like Rust and interestingly some projects like Ladybird have moved away from Swift towards Rust.

Re: My “grand vision” for Rust

#50

Post by satvikpendem »

SkiFire13 wrote: post #46
satvikpendem wrote: post #10

Earlier quoted context omitted.

It doesn't have too many features, it arguably does not have enough. The issue is that the current features don't play nicely with each other, so much of the work has been in making sure they do, such as with async traits as an example: there is no reason why you can make a function async but not inside a trait, and this was the case until very recently. Beyond that, what the article shows is exactly what I want, I w…

Re: async in traits, the feature was delayed because it relied on the "Generic Associated Types" and "Impl Trait in Traits" features. If Rust delayed the whole `async` feature for working on those pretty type-theoretic features what would you have thought?

Well in practice the async_trait crate worked just fine. If Rust delayed the whole async feature I'd have thought they'd have better been able to handle the function coloring problem via something like OCaml's algebraic effects rather than following the trend of JS and C# back then, as OCaml's came along much later after more research into the model.
Post reply on HN