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

21–30 of 323 posts

Re: My “grand vision” for Rust

#21

Post by satvikpendem »

jcranmer wrote: post #19
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…

Yoshua works directly on developing the language, and mentions he is working on these features specifically (he is part of the effects initiative), I'm not sure you won't see these features in Rust.

Re: My “grand vision” for Rust

#22

Post by TeamDman »

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?

I use Rust for command line applications.

I find that CLI is a great way to model problems. When I find myself doing something that has graduated beyond a comfortable amount of PowerShell, Rust is there for me.

I have a template I've been evolving so it's super easy to get started with something new; I just copy the template and slam Copilot with some rough ideas on what I want and it works out.

https://github.com/teamdman/teamy-rust-cli

Just today used it to replace a GitHub stats readme svg generator thing that someone else made that was no longer working properly.

https://github.com/TeamDman/teamy-github-readme-stats

Decomposes the problem very nicely into incrementally achievable steps

1. `fetch ` to get info from github into a cache location 2. `generate ` to load stats and write an svg 3. `serve` to run a webserver to accept GET requests containing the username to do the above

Means that my stuff always has `--help` and `--version` behaviours too

Re: My “grand vision” for Rust

#23

Post by scrubs »

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.

Well ok ... experiment but maybe unlike c++ we could have added N keywords removed M keywords for arguably net-simpler language.

Geez I'd hate to be in rust dev shoes if I can't remove something later when I have a better better min/max. I guess this could be done off main, stable.

Re: My “grand vision” for Rust

#24

Post by Animats »

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-reference problem in Rust. The general idea is that Rc/Weak/upgrade/downgrade provide enough expressive power for back references, but the ergonomics are awful. That could be fixed, and some of the checking moved to compile time for the single owner/multiple users case.

Re: My “grand vision” for Rust

#25

Post by LiamPowell »

metaltyphoon wrote: post #18
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.

> I know people here hate design-by-committee, but historically it's led to some very cohesive languages. C++ is not cohesive at all

I didn't say this applies to every committee, but I do think the opposite applies to almost every "try it and see" language.

Examples of cohesive languages designed by committees would be Ada and Haskell.

Re: My “grand vision” for Rust

#26

Post by MrBuddyCasino »

satvikpendem wrote: post #20
MrBuddyCasino wrote: post #17

Earlier quoted context omitted.

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

You got a point there.

Re: My “grand vision” for Rust

#27

Post by LiamPowell »

satvikpendem wrote: post #16
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.

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.

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

Sure, but it's still quite informal and they just add things as they go instead of writing a complete standard and figuring out how everything interacts before anything is added to the language. Design-by-committee was probably not the best term to use.

Re: My “grand vision” for Rust

#28

Post by Starlevel004 »

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.

Rust is also design-by-committee.

Re: My “grand vision” for Rust

#29

Post by selfmodruntime »

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…

After working with Rust for half a decade I‘m afraid I have to agree. A lot of the newer features have weird edge cases with promises for fixes stuck in bikeshedding hell for years (looking at you const generics). Alternatively feature authors wait on dependecies that will never ship.

Re: My “grand vision” for Rust

#30

Post by wofo »

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, maybe the "academic brilliance" from the article is more pragmatic than I give it credit for. I sure hope for it if these changes ever go through.

Post reply on HN