Earlier quoted context omitted.
Out of curiosity, can you share examples of popular libraries that were difficult to get working correctly?
One example - clap, which is by far the most commonly recommended cli args parsing library. Plain uses of the derive api are simple enough, but I found it a huge time suck to figure out how to do anything remotely different from the docs' examples. On my first 'real' Rust project, it took nearly half my time just figuring out how to deal with cli args. In retrospect I probably should have either used the Builder api…
Rust 2024 the Year of Everywhere?
91–100 of 206 posts
Re: Rust 2024 the Year of Everywhere?
#92Earlier quoted context omitted.
That's why I don't think it's worth dropping modern C++ for it. Only major thing C++ was missing that I wanted is modules. Yeah you have to have high enough agency to use a subset of the language, but so what? I dont plan on having 300 interchangeable human NPCs smashing keys on it, like Go was designed for.
I can imagine a very similar argument being made for punch cards.
That's 90% of the difference between pre-c++11 and post-c++11 best practices. And a couple other "dont do this" rules.
Re: Rust 2024 the Year of Everywhere?
#93Earlier quoted context omitted.
Unsafe Rust is just Rust, but there's a few extra things you can do inside unsafe blocks that you can't normally do outside them (because they're unsafe). I wouldn't call it a different language.
See my response to 'kibwen. We can nitpick all day about whether it's really a separate language; I think it satisfies at least one important definition of "language" by having its own separate syntax and semantics that aren't accessible to Safe Rust.
Re: Rust 2024 the Year of Everywhere?
#94My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. You see this relentlessly in the JavaScript ecosystem where waves of too-complex tools get rapidly replaced with something else, only to be swept away again when someone finds an even more simple way to do the same thing. This must be the fate of Rust - eventually it will be replaced with a langua…
Writing Rust/Actix for server code is a breeze. There's zero complexity. It's practically Java, just with a more Ruby-like syntax. Entirely depends on what you're building. Edit: You can have a small Actix app up over the weekend and never touch "lifetimes" until you're ready.
Re: Rust 2024 the Year of Everywhere?
#95Earlier quoted context omitted.
Writing Rust/Actix for server code is a breeze. There's zero complexity. It's practically Java, just with a more Ruby-like syntax. Entirely depends on what you're building. Edit: You can have a small Actix app up over the weekend and never touch "lifetimes" until you're ready.
I could not disagree more. The moment you need to do something remarkably simple, such as string concatenation, you are confronted with the reality that Rust is a much lower level language.
https://play.rust-lang.org/?version=stable&mode=debug&editio...
I usually use concat() though.
https://play.rust-lang.org/?version=stable&mode=debug&editio...
Re: Rust 2024 the Year of Everywhere?
#96I'm just sitting here learning c++.
I am relearning c++, much has changed in last 12 years! I tried Rust, but when doing a data driven app, I found myself using unsafe way too much!
Re: Rust 2024 the Year of Everywhere?
#97Earlier quoted context omitted.
See my response to 'kibwen. We can nitpick all day about whether it's really a separate language; I think it satisfies at least one important definition of "language" by having its own separate syntax and semantics that aren't accessible to Safe Rust.
What syntax is different with unsafe?
[1]: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
Re: Rust 2024 the Year of Everywhere?
#98Earlier quoted context omitted.
I have primarily worked on kernels written in C during my career, but I read through the official Rust book and wrote a small microkernel using Rust and my opinion is that Rust is already everything I hate about C++. It's already a huge language with a large upfront learning curve and there's no hope of mastering it as it's already grown so large that it could never fit in one person's head. Instead of focusing on so…
I agree that Rust is a large language, but I think you're overstating the complexity: it's been my experience that you don't need to know all (or even most) of the "clever" stuff to write large, performant Rust programs. It's generally true that you can spin engineers up quickly on C, because it looks like a simple language. But that's because C translates static program properties into dynamic ones, and expects engi…
Re: Rust 2024 the Year of Everywhere?
#99Consider a different language with three orthogonal features. You could think of its 'design space' as a cube, where each feature corresponds to a dimension, and where code that uses some features are a point in the space. If the implementors of this hypothetical language didn't know exactly how all three features should interact together but they could figure out how pairs of features would work, you could imagine their initial implementation as the same cube with a chunk missing out of the corner. Later, after users and implementors gather experience about how the language feels, they make a big proposal: The next release will be a full cube instead of a cube with a corner missing! Wow! Now the big question: did this release make the language "more complex"? Well, it is more capable. But it doesn't add any new orthogonal concepts, it just filled out the full space that was implied by the original three. And arguably "cube" is simpler than "cube with a corner missing".
The design of Rust is the cartesian product of about five primary orthogonal features on top of some basic concepts that might be familiar to C programmers. Maybe they are: lifetimes, generics, traits, enums, unsafe. (Argue away if you choose a different five.) When these features were chosen all the way back in 2015 the designers did their best to consider what might happen if you tried to use various combinations of them at once; but crucially, large portions of the corners of this 'space' were left unimplemented simply because it was too hard to do all at once [1]. 65 releases later, Rust has added very few new features -- as in orthogonal concepts -- [2] but has made a lot of progress filling in bits of the design space that was unimplemented but implied by the original five.
And that's literally what this whole article is about: Niko's vision for filling in Rust's implied design space that was left unimplemented for practical reasons, "Making Rust feel simpler by making it more uniform".
[1]: At some point after you've laid the foundation for a big idea it's better to let your idea tell you how it wants to work instead of forcing it, and that requires time and experience with it.
[2]: async, and that's it?
Re: Rust 2024 the Year of Everywhere?
#100My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. You see this relentlessly in the JavaScript ecosystem where waves of too-complex tools get rapidly replaced with something else, only to be swept away again when someone finds an even more simple way to do the same thing. This must be the fate of Rust - eventually it will be replaced with a langua…
"Is it possible to create a truly safe language without the dizzying complexity?" Yes! The good news is, they even already exist. There's even at least two variants of them: Pure immutable values (Haskell, Erlang) and languages that aren't pure functional but involve lots of little execution units that can't send mutable references between the units (Elixir, Pony) which when used even slightly properly makes unaccoun…
Am thinking here of the relationship between Python and Numpy/Pandas. Lots of companies use Numpy heavily but wouldn't dream of trying to hack on it or build such a thing themselves from scratch.
Similar story with places which do things like ban writing their own template code, but permit the use of std container classes.