34
Who's working on a "smaller Rust"?
(programming.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 11 Jan 2024
34 points (87.0% liked)
Rust
6133 readers
43 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 2 years ago
MODERATORS
If you think that's convenient, then I fear you may never have experienced a convenient language.
What is a convenient language exactly?
Although I think the arguments are not exactly pro-Rust (they already show complexity with something like
Box).Sure hacking something quickly together with python is quite a bit faster/easier/less mental overhead.
But long-term and IDE experience IMO Rust is the most convenient language (mind you I programmed in ~10-20 languages, and the whole DX is best with Rust IMO (cargo, rust-analyzer etc.)), as it forces you to write a clean architecture and the strong type system keeps it maintainable. While refactoring can feel cumbersome, I almost always had a clean and working/correct (often without tests) code afterwards (when all the compiler errors are fixed).
That said Rust is of course not perfect, all the strong-typing, zero-cost (async is certainly not something I would recommend beginners) systems-programming features make it complex at times (and the type-system can get in the way at times, e.g. trait-object-safety, or not "simple" higher-kinded types). So when that is annoying and control over the exact memory is not that important, something like OCAML or Haskell may be better.
"Faster/easier/less mental overhead" is indeed exactly what I mean by "convenient".
Maintainability is very different from "convenience", and I think we're both in agreement that Rust makes the correct tradeoff by favoring maintainability over convenience. But that doesn't mean that maintainability implies convenience!
I strongly prefer to write Rust versus "convenient" languages such as Python, Ruby, and (my least favorite, but the one I use most often professionally) Go. But that doesn't stop me from appreciating the benefits of "convenience"; and I think that there is room in the language design space for a slightly different tradeoff: something that isn't usable everywhere Rust is (e.g. it presumably wouldn't ever be a candidate for inclusion in the Linux kernel) but still has many of the same maintainability advantages.
“Faster/easier/less mental overhead” is indeed exactly what I mean by “convenient”.
How different the conception of convenient is :P
I think it's super convenient to just do
cargo new, start hacking, have superb tooling/expressiveness/performance etc. And it works remarkably well and fast if the problem space is not self-referential etc. or a lot of mutability is in play (I'm probably faster in Rust now than in python, but that probably has to do with the amount of time I'm spending with it...). But I get your point, and I think there's certainly better languages for certain problems (and I even started one myself some time ago, because I wanted something like Nix but with strong typing (anonymous sum/union types/sets etc. similar as typescript))You agree with me so strongly that you started designing your own language?? Then why didn't you lead with that, since the post was asking for neolang recommendations??
Well the project never left its roots, it's a still a simple system-f implementation, and a lot of ideas. I've put it on ice, after seeing how much involved there is with questionable outcome (and I need to dedicate a good amount of time to get the theory right, it's not that I have year long research experience background in type-theory etc.). There's more concrete problems than designing yet another language... Maybe I'll come back to that project at some time.
Anyway the idea was to have something like Nix but more general (including derivations, possibly controlled side-effects). Closest to that currently would be typescripts object type, Haskell (overall static typing), crystal-langs union type and nickel (which is less ambitious (probably for good reason)).
I guess we're coming at this with different opinions on what is convenient. Python is extremely easy and quick to write - but then writing more code for tests than the actual program itself because the compiler catches next to nothing and still dealing with the occasional runtime error is highly inconvenient to me. I look at the "ease of use" - or painlessness if you will - of a programming language over the whole lifecycle of the program, not just initially writing it.
Initial development is like 2% of the total effort over the whole lifecycle of a program, at most. The vast majority of time is refactoring, troubleshooting, changing, testing, building, deploying, monitoring.... and so on. With Rusts strong type system, I will probably spend 30% more time developing than with an easier language like Python/Go/Kotlin, but I will save 300% of time debugging, troubleshooting, deploying. Moreover, writing code is something I enjoy, while debugging is something I'd rather avoid. Any language that enables me to spend less time teoubleshooting runtime errors and debugging edge cases is a desirable language for me.
What would you consider a convenient language, and why?
I completely agree with almost everything you wrote (though from my limited experience of Kotlin it seems much less prone to the types of bugs you're describing than Python and Go). That's why, of the languages I know, I prefer Rust for pretty much every task (except shell scripting, for which I honestly don't like any of the available options).
But I think Boats is right that there's room in the language design space for a language that does make some sacrifices in favor of convenience, while still maintaining most of the correctness benefits of Rust.
Consider the case of
async: Rust's design was constrained by the need to not have an execution runtime built into the language, and a desire to be able to use async code in embedded environments without an allocator. The result is honestly an engineering marvel, and amazingly ergonomic given those constraints. But it's full of rough edges and tricky corner-cases: on the language user side, execution engines have fractured the ecosystem, and on the implementation side, it's a slow and arduous process to make all the other Rust language features play nicely with async (as evidenced by the fact that we only just recently got support for async in traits, and it's still very limited).Those difficult requirements are not due to Rust's goal of being highly reliable and maintainable; they're due to the separate goal of Rust being usable anywhere C or C++ is usable. So what would a language look like that values maintainability strongly (maybe not quite as strongly as Rust, but nearly so), without being required to work on all embedded platforms or run without a garbage collector?