Live data from Hacker News

My “grand vision” for Rust

blog.yoshuawuyts.com

81–90 of 323 posts

Re: My “grand vision” for Rust

#81
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…

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.

Exactly because they don't allow it, they don't cover all scenarios regarding language evolution

Re: My “grand vision” for Rust

#82

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…

How does it compare to Kotlin async? I find Kotlin generally hits a good balance across the board.

Re: My “grand vision” for Rust

#83
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,…

> I had some Scala 3 feelings when reading the vision, I hope Rust doesn't gets too pushy with type systems ideas.

I don't know if it is true or not, but my feeling is that Scala brought a lot of new ideas. But as I read somewhere, "Scala was written by compiler people, to write compilers", and I can understand that feeling.

Kotlin came after Scala (I think?) and seems to have gotten a lot of inspiration from Scala. But somehow Kotlin managed to stay "not too complex", unlike Scala.

All that to say, Rust has been innovating in the zero-cost abstraction memory safe field. If it went the way of Scala, I wonder if another language could be "the Kotlin of Rust"? Or is that Zig already? (I have no idea about Zig)

Re: My “grand vision” for Rust

#85
I used to hate Golang for not having generics and how verbose getting basic things done was. Then I read posts like this and realise, my god, Rob Pike was so, so right.

Do these people ever ship anything? Or is it just endless rearranging of deckchairs?

Re: My “grand vision” for Rust

#86
post #66

Earlier quoted context omitted.

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

Some uses of higher-kinded types (though not all of them) can be addressed by leveraging Generic Associated Types (GAT).

Part of the problems is that the "things just compose really well" point becomes gradually less and less applicable as you involve the lower-level features Rust must be concerned with. Abstractions start to become very leaky and it's not clear how best to patch things up without a large increase in complexity. A lot of foundational PL research is needed to address this sensibly.

Re: My “grand vision” for Rust

#87
post #69
post #63

Earlier quoted context omitted.

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?

Rust is nowhere near the complexity of Scala wrt. seemingly arbitrary high-level features. There's a low-level, systems programming featureset that involves quite a bit of complexity but that's also less arbitrary when comparing across similarly low-level languages.

Re: My “grand vision” for Rust

#88
post #83
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,…

> I had some Scala 3 feelings when reading the vision, I hope Rust doesn't gets too pushy with type systems ideas. I don't know if it is true or not, but my feeling is that Scala brought a lot of new ideas. But as I read somewhere, "Scala was written by compiler people, to write compilers", and I can understand that feeling. Kotlin came after Scala (I think?) and seems to have gotten a lot of inspiration from Scala.…

> I wonder if another language could be "the Kotlin of Rust"?

Some people would say that Swift is that language since it's potentially memory safe like Rust and is described as friendlier to novices. There's some room for disagreement wrt. the latter point.

Re: My “grand vision” for Rust

#89

I used to hate Golang for not having generics and how verbose getting basic things done was. Then I read posts like this and realise, my god, Rob Pike was so, so right. Do these people ever ship anything? Or is it just endless rearranging of deckchairs?

I already need a reference to read rust code, looks like I'll need a third reference sheet. The language is currently bordering on spaghetti

Re: My “grand vision” for Rust

#90
post #83

Earlier quoted context omitted.

> I had some Scala 3 feelings when reading the vision, I hope Rust doesn't gets too pushy with type systems ideas. I don't know if it is true or not, but my feeling is that Scala brought a lot of new ideas. But as I read somewhere, "Scala was written by compiler people, to write compilers", and I can understand that feeling. Kotlin came after Scala (I think?) and seems to have gotten a lot of inspiration from Scala.…

> I wonder if another language could be "the Kotlin of Rust"? Some people would say that Swift is that language since it's potentially memory safe like Rust and is described as friendlier to novices. There's some room for disagreement wrt. the latter point.

Well many languages are memory safe. Java has been memory safe forever. Rust is the one that is memory-safe with zero-cost abstractions, right?
Post reply on HN