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

71–80 of 323 posts

Re: My “grand vision” for Rust

#71

Post by jltsiren »

pkal wrote: post #44

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

It's the jargon, I think. PL research is in an awkward position, where the jargon is not shared with the much wider community of people using programming languages daily. From the other side, it looks like there is a small body of theoreticians using impenetrable language for discussing topics I'm supposed to be familiar with, because they are a core part of my day job. It's much easier to accept jargon, when it's used in a clearly separate field.

Some of the terminology is just unfortunate. For example, I have an intuitive understanding of what a type means. The meaning used in PL theory is somehow wider, but I don't really understand how.

And then there is my pet peeve: side effect. Those should be effects instead, because they largely define the observable behavior of the program. Computation, on the other hand, is a side effect, to the extent it doesn't affect the observable behavior.

But then PL theory is using "effect" for something completely different. I don't know what exactly, but clearly not something I would consider an effect.

Re: My “grand vision” for Rust

#72

Post by nesarkvechnep »

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?

In C++, concepts are essentially generics where templates are more like weird macros.

Re: My “grand vision” for Rust

#73

Post by bitwalker »

wolvesechoes wrote: post #43
LiamPowell wrote: post #15

Earlier quoted context omitted.

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

AIUI, that is what the MIR formalization work is about, and it seems to be moving along fine. My impression is that covers essentially all the interesting parts of Rust worth specifying formally.

Re: My “grand vision” for Rust

#74

Post by voxl »

jltsiren wrote: post #71
pkal wrote: post #44

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

It's the jargon, I think. PL research is in an awkward position, where the jargon is not shared with the much wider community of people using programming languages daily. From the other side, it looks like there is a small body of theoreticians using impenetrable language for discussing topics I'm supposed to be familiar with, because they are a core part of my day job. It's much easier to accept jargon, when it's us…

Man who uses arithmetic upset at research mathematicians for using words like R-module when they clearly do not mean a module in C++

More at 11

Re: My “grand vision” for Rust

#75

Post by wtetzner »

jstanley wrote: post #36
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.

https://xkcd.com/927/

Can you explain how this is relevant here?

Re: My “grand vision” for Rust

#76

Post by Conscat »

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…

> I understand that Boost is now deprecated.

Huh?? Boost is used basically everywhere.

Re: My “grand vision” for Rust

#77

Post by Conscat »

pjmlp wrote: post #3

Reposting my comment from Reddit, I had some Scala 3 feelings when reading the vision, I hope Rust doesn't gets too pushy with type systems ideas. That is how we end with other ecosystems doubling down in automatic memory management with a good enough ownership model for low level coding, e.g. Swift 6, OxCaml, Chapel, D, Linear Haskel, OCaml effects,... Where the goal is that those features are to be used by experts,…

My understanding is that Scala 3 came with many large breaking changes that made adoption difficult. I at least hadn't heard users complain that new features weren't desired.

Re: My “grand vision” for Rust

#78

Post by simonask »

Animats wrote: post #66
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,…

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

I would also have liked to see some motivational examples, but I think the most interesting upside of an effect system is composability.

Rust is actually really unique among imperative languages in its general composability - things just compose really well across most language features.

The big missing pieces for composability are higher-kinded types (where you could be generic over Option, Result, etc.), and effects (where you could be generic over async-fn, const-fn, hypothetical nopanic-fn, etc.)

The former becomes obvious with the amount of interface duplication between types like Option and Result. The latter becomes obvious with the number of variants of certain functions that essentially do the same thing but with a different color.

Re: My “grand vision” for Rust

#79

Post by simonask »

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 to contain heap/GC pressure when every `await` allocates?

Phooey. Rust async is doing just fine.

Re: My “grand vision” for Rust

#80

Post by pjmlp »

Rusky wrote: post #55
pjmlp wrote: post #52

Earlier quoted context omitted.

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…

Or put another way, a hypothetical feature that you made up in your head is the thing that requires source access. Editions do not let you change the semantics of types. To be fair, Rust tooling does tend toward build-from-source. But this is for completely different reasons than the edition system: if you had a way to build a crate and then feed the binary into builds by future compilers, it would require zero addit…

Exactly, hence why people should stop talking about editions as if they sort out all Rust evolution problems, in your own words it doesn't allow changing type semantics
Post reply on HN