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

11–20 of 323 posts

Re: My “grand vision” for Rust

#11

Post by satvikpendem »

arrty88 wrote: post #5

I would love to have a use case to learn and write rust today. But i am deep in node and go services for my employer. Previously wrote java and c#. What are people writing in rust today?

Whatever I used to use Node for, like web servers, I now use Rust. It's pretty nice, with a strong OCaml-like type system which I've used before (better than TypeScript even in some cases), plus it's much faster and more memory efficient such that I can run way more services on my 5 dollar Hetzner box with Dokploy compared to Node or Java or C#.

Re: My “grand vision” for Rust

#12

Post by satvikpendem »

jadenPete wrote: post #6

I couldn’t disagree more. Most of my company’s backend code is written in Scala, and most of our engineers dislike it because the language is difficult to understand, has way too many features, and has many ways to solve the same problem. I don’t want Rust to continue down this path, and I already worry with some of the syntactic sugar and type system additions being discussed that it already has. A language’s type s…

There is a middle ground. People seem to use Haskell and OCaml just fine and both are as expressive, so maybe it is just Scala having shoved in too many things. Based on what the article shows, it doesn't seem like they're making ten different ways to do the same thing but rather one way to (optionally) get more type safety out. I doubt everyone will be writing dependent type contracts for every single function, it's more for certain pieces of the codebase.

Re: My “grand vision” for Rust

#13

Post by satvikpendem »

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

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 single function (maybe LLMs will, but that's an orthogonal discussion).

Re: My “grand vision” for Rust

#14

Post by satvikpendem »

xiphias2 wrote: post #8
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…

The main problem I see is adding things slowly instead of automatic rewrites. I remember adding lifetimes in some structs and then wanted to use generics and self pointing with lifetimes because that made sense, and then it didn't work because the composition of some features was not yet part of Rust. Another thing: there are annotations for lifetimes in function signatures, but not inside the functions where there i…

The edition mechanism covers your last paragraph.

Re: My “grand vision” for Rust

#15

Post by LiamPowell »

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…

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.

Re: My “grand vision” for Rust

#16

Post by satvikpendem »

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.

Yes, however how many of them are used in production to some level of scale (not even to the scale of Rust)? Stroustrup's quote and all that.

Rust's development process is also design by committee, interestingly enough.

Re: My “grand vision” for Rust

#17

Post by MrBuddyCasino »

satvikpendem wrote: post #12
jadenPete wrote: post #6

I couldn’t disagree more. Most of my company’s backend code is written in Scala, and most of our engineers dislike it because the language is difficult to understand, has way too many features, and has many ways to solve the same problem. I don’t want Rust to continue down this path, and I already worry with some of the syntactic sugar and type system additions being discussed that it already has. A language’s type s…

There is a middle ground. People seem to use Haskell and OCaml just fine and both are as expressive, so maybe it is just Scala having shoved in too many things. Based on what the article shows, it doesn't seem like they're making ten different ways to do the same thing but rather one way to (optionally) get more type safety out. I doubt everyone will be writing dependent type contracts for every single function, it's…

Ah yes Haskell, the reasonable centrist position in language design.

Re: My “grand vision” for Rust

#18

Post by metaltyphoon »

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.

> I know people here hate design-by-committee, but historically it's led to some very cohesive languages.

C++ is not cohesive at all

Re: My “grand vision” for Rust

#19

Post by jcranmer »

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…

You're not wrong here. Not that I'm entirely up-to-speed on all of the deep Rust discussions, but the sense I have of the language evolution is that while there is definitely a loud contingent of people pushing for a lot of the complexity of full effect systems or linear types, these sorts of proposals aren't actually all that likely to actually move forward in the language.

(I should note that of all of the features mentioned in this blog post, the only one I actually expect to see in Rust someday is pattern types, and that's largely because it partially exists already in unstable form to use for things like NonZeroU32.)

Re: My “grand vision” for Rust

#20

Post by satvikpendem »

MrBuddyCasino wrote: post #17
satvikpendem wrote: post #12

Earlier quoted context omitted.

There is a middle ground. People seem to use Haskell and OCaml just fine and both are as expressive, so maybe it is just Scala having shoved in too many things. Based on what the article shows, it doesn't seem like they're making ten different ways to do the same thing but rather one way to (optionally) get more type safety out. I doubt everyone will be writing dependent type contracts for every single function, it's…

Ah yes Haskell, the reasonable centrist position in language design.

Compared to the other languages listed in this thread, it definitely is, and it has production systems unlike them.

https://news.ycombinator.com/item?id=47259148

Post reply on HN