Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

People build libraries to solve real problems. Language features need to have proper motivations in order to be accepted; we have rejected more academic features that don’t have direct uses. For example, async/await solved a real pain point for our largest production users, and that’s why everyone has been talking about it.

Sometimes, these connections can be unclear from the outside. For example, there’s a lot of talk about “generic type constructors” and “generic associated types”, which sounds academic. However, it’s something the compiler needs to understand in order to implement a very simple user-facing feature: async functions in traits. From the outside it may look like “oh those folks are out of touch” but it’s directly connected to real user needs.

(As a further aside, these two features are identical, but “generic type constructors” focuses on the academic, and “generic associated types” focuses on the end-user benefit; we changed out terminology here specifically to focus on what users get out of the feature rather than the type theory implications.)

Furthermore, some people tweeting about things they’re excited about does also not preclude others who are heads down all the time. You wouldn’t see them for the same reasons, they’re not tweeting.

These kinds of swipes against other languages lower the discourse and promote animosity when there really should be none. I’d encourage you to consider if these kinds of attitudes help bring about more people who are interested in building cool things, or fan flame wars that distract folks from doing exactly that. Every minute spent arguing over whose language is better is also a distraction from building cool things as well.



What are some examples of features Rust has rejected for having no direct use? (I’m considering doing some language hacking just to learn the more arcane aspects of compiler theory, and it’d be nice to have a list of “exotic features you won’t usually find in a language because they don’t do much to help people” to explore.)


There was a contingent of folks who argued that we should not build async/await, but that we should instead build a generalized effect system, or figure out monads and do notation, because async/await is a specific form of those things and we should wait until we can get the more general feature first. Higher kinded types is sort of in this space, GATs will provide equivalent power someday...

We rejected a proposal for dependent/pi types; we’re still adding a limited form, and may get there someday, but we didn’t want to go fully into them at first because the difficulty was high, and the benefit less clear, than just the simple version. (Const generics)

There’s a few other other features that we had and removed too I can think of off the top of my head. We used to use conditions for error handling. We had typestate.

There was a battle over type classes vs ML style modules, type classes (traits) won in the end. That doesn’t mean modules are useless...

I think the answers to these questions are very relative to your langauge’s values and goals. All of these features have good uses in other languages, but couldn’t find a place in Rust for a variety of reasons. Your language should be different than Rust, so you may find some of these features useful, and not find some of ours useful.

I would encourage you to read TAPL, I think it would help with what you’re trying to do. Oh and check out https://plzoo.andrej.com/


> People build libraries to solve real problems.

Not always, some Rust community members in fact don't build any sort of applications with Rust at all, and only build libraries. I think it's reasonable to be skeptical of this.

I think the community can do better by promoting more talks involving applications written with Rust. As an outsider this is a puzzling omission to me as there seems to be more people using Rust than there is Firefox and Cloudfront engineers, so I'd like to learn more about where it's actually used.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: