9 ms·

What a better Rust would look like

37 points by asimpletune 5y ago

dontlaugh 5y ago
Sound like you may enjoy Swift.
x-shadowban 5y ago
C++ but with standardized, gradually-opted-in lifetime analysis
- pjmlp 5y ago
  Visual C++ and clang tidy already offer something into that direction, based on the core guidelines, it isn't fully there due to the language's complexity.
PaulHoule 5y ago
Macro assembler + Theorem prover
adamnemecek 5y ago
> In 2022, a standard library should at least contain the following packages: No it really, really shouldn’t.
tmpfs 5y ago
I disagree with all the points in the article with the exception of lifetimes which i do find cumbersome at times due to the way they have to be propagated which makes refactoring to references awkward. I think the larger standard library of a language like Go is appealing but Rust is a community effort and doesn't have Google scale resources to maintain a large standard library. I particularly abhor Go style uppercase for public visibility and much prefer Rust's explicit syntax. In addition, i find Rust's module system very enjoyable and prefer it to any other language i have used once i got familiar with it.
- ncmncm 5y ago
  Just making borrow checker violations into warnings for debug builds would go a long way to making the language more tolerable to the overwhelming majority of programmers not already committed to it. Wanting to ship without violations does not mean you are not interested in getting your algorithm working, first. Often enough, you will abandon your laboriously borrow-safed code without shipping it, because you figured out a better way. But! you had to borrow-safe the new way, too, before you could even try it out. Rust has already penetrated a good fraction of places that will tolerate it as it is now. To find wider usage, the user experience will have to get much better. Without finding enormously wider usage, it will fizzle. It will have fizzled: you only know after it is too late. Fizzling is absolutely the normal fate of any new language. It takes absolutely phenomenal adoption to generate a lasting ecosystem. Even phenomenal adoption is not always enough. We once thought Ruby had legs, and Ada.
  - eminence32 5y ago
    > Just making borrow checker violations into warnings for debug builds This is an interesting idea. I wonder what class of borrowck problems could be ignored like. Some of them can't be ignored, I think, because they would allow catastrophic things like use-after-free. But are there other violations that aren't as serious?
    - ncmncm 5y ago
      If they are catastrophic, you may have to fix them to make progress. But most are not, and you can make other progress. Leaks are not. Cargo should not be dictating your work schedule.
      - sfvisser 5y ago
        I think this is valid reasoning. Allowing to turn errors into warnings for dev builds would probably allow for fixing issues faster. Given the UX is good. I use todo!() a ton when building as well. Sketching out data types and signatures before diving into implementation details.
verdagon 5y ago
> ... from a programmer's perspective, I would love to see a mix of compile-time lifetime analysis, Automatic Reference Counting (like in the lobster programming language), and manual memory management (marked as unsafe) for when extreme performance is needed. Surprisingly, such a thing is actually possible. We can use borrow-checker-like static analysis layered on top of shared mutability (such as RC). It involves selectively making certain sub-graphs ("regions") immutable, thus getting the borrow checker's zero-cost memory safety, without the architectural restrictions the borrow checker normally imposes. The core insight is that a borrow checker doesn't need every object to be completely affine, all it needs is some notion of what objects are reachable from what others. This has recently been prototyped in the research languages from Forty2 ("capsules") [0] and from Milano, Turcotti, Myers [1]. Pony's "iso" [2] has shown that it can work remarkably well in production, and Vale [3] is making it work with single ownership. In my (biased!) opinion, it's one of the most promising areas in language research. If we can get the speed and safety benefits of Rust while being more ergonomic and intuitive, I'd consider that a big step forward for the field. An exciting time to be in language design! [0] http://forty2.is/ http://forty2.is/ [1] https://www.cs.cornell.edu/andru/papers/gallifrey-types/gallifrey-types.pdf https://www.cs.cornell.edu/andru/papers/gallifrey-types/gall... [2] https://tutorial.ponylang.io/reference-capabilities/reference-capabilities.html#isolated-data-is-safe https://tutorial.ponylang.io/reference-capabilities/referenc... [3] https://verdagon.dev/blog/zero-cost-refs-regions https://verdagon.dev/blog/zero-cost-refs-regions
MrBuddyCasino 5y ago
I don’t know how to put it any other way, this reads to me like a poorly thought out critique from someone who might be happier using Golang.
- kortex 5y ago
  I totally agree. Literally every point is "what if Rust did this thing that bugs me the Golang way?" Granted, it's a sort list, but it seems like the patterns are precisely golang influenced.
  - noitpmeder 5y ago
    There is nothing wrong with proposing changes from what, in your opinion, is a better implementation or workflow. Most of every language was implemented somewhere else first.
    - kortex 5y ago
      Sure, it's absolutely great to learn from other languages. I guess what rubs me the wrong way is every point is explicitly or implicitly the Golang way of doing things. There's no real representation from other languages. That combined with being a relatively short list makes the whole article underwhelming. Article> It's the fruit of my experience working with C, Python, TypeScript, Go, and Rust and my frustrations with the latter. I don't really see the influences from anything other than Go here. Don't get me wrong, I love both Go and Rust, for very different reasons.
Ericson2314 5y ago
This person has no idea what they are talking about on the advanced point. The other points are a critique of Cargo not Rust, or just plain superficial nonsense.
edflsafoiewq 5y ago
> Using the case (lowercase for private, uppercase for public) of the first letter of the identifier is perfect for lazy developers like me Similar to Python's _foo. I don't like it because if you want to change the visibility you must change the name at all current use-sites.
- simondotau 5y ago
  Forcing you to change all usages seems like a win, making it harder to accumulate code smells and encouraging you to audit variable use — however briefly — when they change type.
- tayo42 5y ago
  the _ thing in python ime has been pointless, people will use those functions anyway if they need to. it just makes code ugly and harder to read. i rarely ever prefix a function with an _
  - noitpmeder 5y ago
    I like it because it's an easy way to signal intent. Sure someone can still use it if they want, but it effectively communicates my desire that you _should not_ use this. I'm open to other suggestions for how to effectively communicate the public interface without maintaining some separate documentation.
matxip 5y ago
At first, I was a little put off by how "batteries not included" the standard library was in rust, but I ended up preferring it. The quality of the rust community has generally made library selection pretty easy. There's usually a tacit first choice and often one or more optimized alternative for a particular situation or preference. When there is community disagreement and library churn, I think it ends up evolving better, more liked solutions; I truly believe this wouldn't happen as easily if it was enshrined in the std. Case and point, I've seen standard library implementations in C++ and python that just rot away. The case sensitive visibility/privacy sound terrible to me. I dislike having to type pub as much as I do, but that seems worse for readability and clarity on top of throwing a wrench into the established rustfmt naming system. About "Memory management", they already made some progress with non-lexical lifetimes in the past which did indeed improve the end user experience. I think "Polonius" aims to reduce the friction further, but I haven't looked into the specific improvements it might bring in user experience.
- oxff 5y ago
  I think it has plenty enough of batteries for building things that can be used to build things. Very good abstractions for the most part, with mostly good implementations (ie. cases like parking_lot mutex show where it fails, and the `async` stuff is bit sketch). Don't understand and don't support initiatives that want to stuff it full of actual applications and stuff (like http server, async runtime) etc. Just use I don't know, something else at that point.
- tayo42 5y ago
  > When there is community disagreement and library churn, I think it ends up evolving better, more liked solutions; That's an optimistic way of thinking about. I feel hesitant to pull in libraries because you don't know when or why the community is going decide to change. Then your that fool using that old code, stuck with sudden tech debt. It also makes stuff like stackoverflow weird to use where you get different answers depending on the year. I think the biggest problem is with libraries that try to make things more ergnomic. Learning about pin and how to use it is weird, everyone keeps recommending some higher level library.
Sophistifunk 5y ago
I fail to see how decentralised package sources can possibly reduce the chances of a supply chain attack (from outsiders). Now instead of one repo needing to be secure and up to date, thousands must.
- room271 5y ago
  I encourage you to read this then: https://go.dev/blog/supply-chain https://go.dev/blog/supply-chain. Edit: along with the authors own blog explaining their take: https://kerkour.com/supply-chain-attacks-and-backdoored-dependencies https://kerkour.com/supply-chain-attacks-and-backdoored-depe.... The short version is, it's better to have a centralised (though proxyable, and opt-outable) central store of hashes of module content, but then provide flexibility over distribution. The concern is that a central package manager adds complexity and opportunity for security vulnerabilities without adding much value.
brundolf 5y ago
If we're making wish-lists, I'd like a variant of Rust exactly as-is except with implicit boxing/GC instead of lifetimes and proper borrow-checking. The real version of Rust that has borrow-checking serves a more unique and important niche for many use-cases out there, but for most of my own personal use-cases I'd rather make this particular tradeoff while keeping everything else
Luker88 5y ago
I find I don't really care about that list, aside maybe trying to resolve the namesquatting problem in cargo. My reduced list includes only: * Strong typesafe wrapper types. We had a few RFCs, always dropped. This would actually change how I program, and would increase typesafety a lot. I don't even need fancy wrapping with the ability to select which traits to expose and which not, just wrap+automatic expose would change my life a lot * Let me compile to shared libraries. I get it, all-static has its pros. But refusing to support shared libraries is asinine. It's fine if I have to always use the same rust compiler version! just give me the possibility!
- ModernMech 5y ago
  > Let me compile to shared libraries. I compile Rust to shared .dll and .so libs all the time. Is this what you're looking for? --crate-type=dylib, #[crate_type = "dylib"] - A dynamic Rust library will be produced. This is different from the lib output type in that this forces dynamic library generation. The resulting dynamic library can be used as a dependency for other libraries and/or executables. This output type will create *.so files on Linux, *.dylib files on macOS, and *.dll files on Windows. https://doc.rust-lang.org/reference/linkage.html https://doc.rust-lang.org/reference/linkage.html
  - Luker88 5y ago
    No, I guess I wrote the message too quickly and explained poorly, my bad. I meant compiling a program and linking the crates as shared libraries. Kinda like a normal C/C++ program, and how the whole linux wolrd works. ...and I guess even the strong newtype wrapper is actually there with `struct Newtype(type);`, but I end up having way too many `.0` everywhere that I really dislike I'll try not to post before my morning coffee next time :p
    - ModernMech 5y ago
      > I meant compiling a program and linking the crates as shared libraries. Okay I see. You can kind of get this from the libloading crate. https://docs.rs/libloading/latest/libloading/ https://docs.rs/libloading/latest/libloading/ It works but it’s not great.
singularity2001 5y ago
A better rust would get rid of useless explicit verbosity and make Result an implicit first class citizen concept: ``` pub fn horror()->Result{Ok(Result(mut &self))} ``` ``` pub fn better()->self ``` Swift is a better Rust.
stillkicking 5y ago
Every time someone argues something based on the merits of Go, I can't take them seriously anymore.
musicmatze 5y ago
After reading this article I think the author just wanted to trigger everyone or that this is all some strange form of sarcasm/irony. No need to give it a second thought I guess...

37 points by asimpletune 5y ago

dontlaugh 5y ago

Sound like you may enjoy Swift.

x-shadowban 5y ago

C++ but with standardized, gradually-opted-in lifetime analysis

pjmlp 5y ago
Visual C++ and clang tidy already offer something into that direction, based on the core guidelines, it isn't fully there due to the language's complexity.

PaulHoule 5y ago

Macro assembler + Theorem prover

adamnemecek 5y ago

> In 2022, a standard library should at least contain the following packages: No it really, really shouldn’t.

tmpfs 5y ago

I disagree with all the points in the article with the exception of lifetimes which i do find cumbersome at times due to the way they have to be propagated which makes refactoring to references awkward. I think the larger standard library of a language like Go is appealing but Rust is a community effort and doesn't have Google scale resources to maintain a large standard library. I particularly abhor Go style uppercase for public visibility and much prefer Rust's explicit syntax. In addition, i find Rust's module system very enjoyable and prefer it to any other language i have used once i got familiar with it.

ncmncm 5y ago
Just making borrow checker violations into warnings for debug builds would go a long way to making the language more tolerable to the overwhelming majority of programmers not already committed to it. Wanting to ship without violations does not mean you are not interested in getting your algorithm working, first. Often enough, you will abandon your laboriously borrow-safed code without shipping it, because you figured out a better way. But! you had to borrow-safe the new way, too, before you could even try it out. Rust has already penetrated a good fraction of places that will tolerate it as it is now. To find wider usage, the user experience will have to get much better. Without finding enormously wider usage, it will fizzle. It will have fizzled: you only know after it is too late. Fizzling is absolutely the normal fate of any new language. It takes absolutely phenomenal adoption to generate a lasting ecosystem. Even phenomenal adoption is not always enough. We once thought Ruby had legs, and Ada.
- eminence32 5y ago
  > Just making borrow checker violations into warnings for debug builds This is an interesting idea. I wonder what class of borrowck problems could be ignored like. Some of them can't be ignored, I think, because they would allow catastrophic things like use-after-free. But are there other violations that aren't as serious?
  - ncmncm 5y ago
    If they are catastrophic, you may have to fix them to make progress. But most are not, and you can make other progress. Leaks are not. Cargo should not be dictating your work schedule.
    - sfvisser 5y ago
      I think this is valid reasoning. Allowing to turn errors into warnings for dev builds would probably allow for fixing issues faster. Given the UX is good. I use todo!() a ton when building as well. Sketching out data types and signatures before diving into implementation details.

verdagon 5y ago

> ... from a programmer's perspective, I would love to see a mix of compile-time lifetime analysis, Automatic Reference Counting (like in the lobster programming language), and manual memory management (marked as unsafe) for when extreme performance is needed. Surprisingly, such a thing is actually possible. We can use borrow-checker-like static analysis layered on top of shared mutability (such as RC). It involves selectively making certain sub-graphs ("regions") immutable, thus getting the borrow checker's zero-cost memory safety, without the architectural restrictions the borrow checker normally imposes. The core insight is that a borrow checker doesn't need every object to be completely affine, all it needs is some notion of what objects are reachable from what others. This has recently been prototyped in the research languages from Forty2 ("capsules") [0] and from Milano, Turcotti, Myers [1]. Pony's "iso" [2] has shown that it can work remarkably well in production, and Vale [3] is making it work with single ownership. In my (biased!) opinion, it's one of the most promising areas in language research. If we can get the speed and safety benefits of Rust while being more ergonomic and intuitive, I'd consider that a big step forward for the field. An exciting time to be in language design! [0] http://forty2.is/ http://forty2.is/ [1] https://www.cs.cornell.edu/andru/papers/gallifrey-types/gallifrey-types.pdf https://www.cs.cornell.edu/andru/papers/gallifrey-types/gall... [2] https://tutorial.ponylang.io/reference-capabilities/reference-capabilities.html#isolated-data-is-safe https://tutorial.ponylang.io/reference-capabilities/referenc... [3] https://verdagon.dev/blog/zero-cost-refs-regions https://verdagon.dev/blog/zero-cost-refs-regions

MrBuddyCasino 5y ago

I don’t know how to put it any other way, this reads to me like a poorly thought out critique from someone who might be happier using Golang.

kortex 5y ago
I totally agree. Literally every point is "what if Rust did this thing that bugs me the Golang way?" Granted, it's a sort list, but it seems like the patterns are precisely golang influenced.
- noitpmeder 5y ago
  There is nothing wrong with proposing changes from what, in your opinion, is a better implementation or workflow. Most of every language was implemented somewhere else first.
  - kortex 5y ago
    Sure, it's absolutely great to learn from other languages. I guess what rubs me the wrong way is every point is explicitly or implicitly the Golang way of doing things. There's no real representation from other languages. That combined with being a relatively short list makes the whole article underwhelming. Article> It's the fruit of my experience working with C, Python, TypeScript, Go, and Rust and my frustrations with the latter. I don't really see the influences from anything other than Go here. Don't get me wrong, I love both Go and Rust, for very different reasons.

Ericson2314 5y ago

This person has no idea what they are talking about on the advanced point. The other points are a critique of Cargo not Rust, or just plain superficial nonsense.

edflsafoiewq 5y ago

> Using the case (lowercase for private, uppercase for public) of the first letter of the identifier is perfect for lazy developers like me Similar to Python's _foo. I don't like it because if you want to change the visibility you must change the name at all current use-sites.

simondotau 5y ago
Forcing you to change all usages seems like a win, making it harder to accumulate code smells and encouraging you to audit variable use — however briefly — when they change type.
tayo42 5y ago
the _ thing in python ime has been pointless, people will use those functions anyway if they need to. it just makes code ugly and harder to read. i rarely ever prefix a function with an _
- noitpmeder 5y ago
  I like it because it's an easy way to signal intent. Sure someone can still use it if they want, but it effectively communicates my desire that you _should not_ use this. I'm open to other suggestions for how to effectively communicate the public interface without maintaining some separate documentation.

matxip 5y ago

At first, I was a little put off by how "batteries not included" the standard library was in rust, but I ended up preferring it. The quality of the rust community has generally made library selection pretty easy. There's usually a tacit first choice and often one or more optimized alternative for a particular situation or preference. When there is community disagreement and library churn, I think it ends up evolving better, more liked solutions; I truly believe this wouldn't happen as easily if it was enshrined in the std. Case and point, I've seen standard library implementations in C++ and python that just rot away. The case sensitive visibility/privacy sound terrible to me. I dislike having to type pub as much as I do, but that seems worse for readability and clarity on top of throwing a wrench into the established rustfmt naming system. About "Memory management", they already made some progress with non-lexical lifetimes in the past which did indeed improve the end user experience. I think "Polonius" aims to reduce the friction further, but I haven't looked into the specific improvements it might bring in user experience.

oxff 5y ago
I think it has plenty enough of batteries for building things that can be used to build things. Very good abstractions for the most part, with mostly good implementations (ie. cases like parking_lot mutex show where it fails, and the `async` stuff is bit sketch). Don't understand and don't support initiatives that want to stuff it full of actual applications and stuff (like http server, async runtime) etc. Just use I don't know, something else at that point.
tayo42 5y ago
> When there is community disagreement and library churn, I think it ends up evolving better, more liked solutions; That's an optimistic way of thinking about. I feel hesitant to pull in libraries because you don't know when or why the community is going decide to change. Then your that fool using that old code, stuck with sudden tech debt. It also makes stuff like stackoverflow weird to use where you get different answers depending on the year. I think the biggest problem is with libraries that try to make things more ergnomic. Learning about pin and how to use it is weird, everyone keeps recommending some higher level library.

Sophistifunk 5y ago

I fail to see how decentralised package sources can possibly reduce the chances of a supply chain attack (from outsiders). Now instead of one repo needing to be secure and up to date, thousands must.

room271 5y ago
I encourage you to read this then: https://go.dev/blog/supply-chain https://go.dev/blog/supply-chain. Edit: along with the authors own blog explaining their take: https://kerkour.com/supply-chain-attacks-and-backdoored-dependencies https://kerkour.com/supply-chain-attacks-and-backdoored-depe.... The short version is, it's better to have a centralised (though proxyable, and opt-outable) central store of hashes of module content, but then provide flexibility over distribution. The concern is that a central package manager adds complexity and opportunity for security vulnerabilities without adding much value.

brundolf 5y ago

If we're making wish-lists, I'd like a variant of Rust exactly as-is except with implicit boxing/GC instead of lifetimes and proper borrow-checking. The real version of Rust that has borrow-checking serves a more unique and important niche for many use-cases out there, but for most of my own personal use-cases I'd rather make this particular tradeoff while keeping everything else

Luker88 5y ago

I find I don't really care about that list, aside maybe trying to resolve the namesquatting problem in cargo. My reduced list includes only: * Strong typesafe wrapper types. We had a few RFCs, always dropped. This would actually change how I program, and would increase typesafety a lot. I don't even need fancy wrapping with the ability to select which traits to expose and which not, just wrap+automatic expose would change my life a lot * Let me compile to shared libraries. I get it, all-static has its pros. But refusing to support shared libraries is asinine. It's fine if I have to always use the same rust compiler version! just give me the possibility!

ModernMech 5y ago
> Let me compile to shared libraries. I compile Rust to shared .dll and .so libs all the time. Is this what you're looking for? --crate-type=dylib, #[crate_type = "dylib"] - A dynamic Rust library will be produced. This is different from the lib output type in that this forces dynamic library generation. The resulting dynamic library can be used as a dependency for other libraries and/or executables. This output type will create *.so files on Linux, *.dylib files on macOS, and *.dll files on Windows. https://doc.rust-lang.org/reference/linkage.html https://doc.rust-lang.org/reference/linkage.html
- Luker88 5y ago
  No, I guess I wrote the message too quickly and explained poorly, my bad. I meant compiling a program and linking the crates as shared libraries. Kinda like a normal C/C++ program, and how the whole linux wolrd works. ...and I guess even the strong newtype wrapper is actually there with `struct Newtype(type);`, but I end up having way too many `.0` everywhere that I really dislike I'll try not to post before my morning coffee next time :p
  - ModernMech 5y ago
    > I meant compiling a program and linking the crates as shared libraries. Okay I see. You can kind of get this from the libloading crate. https://docs.rs/libloading/latest/libloading/ https://docs.rs/libloading/latest/libloading/ It works but it’s not great.

singularity2001 5y ago

A better rust would get rid of useless explicit verbosity and make Result an implicit first class citizen concept: ``` pub fn horror()->Result{Ok(Result(mut &self))} ``` ``` pub fn better()->self ``` Swift is a better Rust.

stillkicking 5y ago

Every time someone argues something based on the merits of Go, I can't take them seriously anymore.

musicmatze 5y ago

After reading this article I think the author just wanted to trigger everyone or that this is all some strange form of sarcasm/irony. No need to give it a second thought I guess...