How much faster can the compiler be? This is the top issue with rust IMHO - compile times are real bad.
For someone who hasn’t written any larger rust programs. Is the compile time worse than c++?
Thoughts on what a next Rust compiler would do
121–130 of 147 posts
Re: Thoughts on what a next Rust compiler would do
#122Earlier quoted context omitted.
For backend APIs it absolutely makes sense, not only for the safety guarantees but also its type system which makes data flows much easier to reason about. I recommend the book Zero To Production in Rust in particular for learning about this, I finished it recently and at the end I had a production-ready backend API. https://zero2prod.com
Rust isn’t as safe as GCed language and you don’t need systems level speed on a backend API. Rust’s safety is better than C/C++, but memory vulnerabilities are found in cargo packages because of unsafe code.
> Rust isn’t as safe as GCed language
Safe rust should be. And C# is a notable example of a GCed language that also has 'unsafe'. Along with most of the GCed languages with FFIs.
Re: Thoughts on what a next Rust compiler would do
#123Earlier quoted context omitted.
For what it’s worth, I agree with the GP comment when it comes to network services and for quickly prototyping things out. I’ve been writing in rust almost exclusively for the last few years, but I still reach for typescript from time to time. JS/TS just requires fewer decisions per line of code. As a pithy example, in javascript I don’t have to decide whether I want a String / &str / SmartString / Rc , etc. It’s jus…
Rust programs take more effort to write initially, but less effort throughout the software lifecycle. Unless you're writing code just to throw it away and not even run it once (which practically doesn't ever happen, at least not intentionally) Rust front-loading the effort is the right trade off. Never mind that some of these choices you can just avoid by thinking in general terms and deferring optimization for later…
Huh? Rust is better if I ever run my program even once? Even when it takes significantly more effort to write? Hard disagree on that.
> Just passing String and FnMut everywhere will be a lot more efficient than whatever the JS translates to on the machine.
I can’t comment on the performance of FnMut, but I’ve seen rust code run slower than the equivalent javascript because the rust code in question allocates everywhere without thinking about it (via Vec, String and Box).
In my mind, javascript and friends are good languages to build things fast. Rust is a good language to build things right. For plenty of software (eg websites), good enough is good enough.
Re: Thoughts on what a next Rust compiler would do
#124Earlier quoted context omitted.
Rust isn’t as safe as GCed language and you don’t need systems level speed on a backend API. Rust’s safety is better than C/C++, but memory vulnerabilities are found in cargo packages because of unsafe code.
> Rust isn’t as safe as GCed language Safe rust should be. And C# is a notable example of a GCed language that also has 'unsafe'. Along with most of the GCed languages with FFIs.
Safe rust can still use crates with unsafe rust, so no. Unless it’s safe rust and uses no outside code or none of its dependency tree has unsafe rust.
It’s pretty crazy how many people will argue this point and downvote comments about it. It’s like a C++ dev claiming they never write memory bugs. I love rust, but the community pretending like memory safety bugs are impossible is as annoying as people claiming memory safety isn’t important.
EDIT: And GC languages “can” call unsafe is not the same as a language that has unsafe in it. It’s laughable if you are claiming there are the same memory bugs in say Elixir as there are in Rust.
Re: Thoughts on what a next Rust compiler would do
#125Earlier quoted context omitted.
Rust isn’t as safe as GCed language and you don’t need systems level speed on a backend API. Rust’s safety is better than C/C++, but memory vulnerabilities are found in cargo packages because of unsafe code.
> you don’t need systems level speed on a backend API. I do, actually. > but memory vulnerabilities are found in cargo packages because of unsafe code. Forbid unsafe in your config and you're good.
Correct me if I am around, but Forbid unsafe does not include dependencies, which can and do have unsafe rust.
Re: Thoughts on what a next Rust compiler would do
#126Earlier quoted context omitted.
> Rust isn’t as safe as GCed language Safe rust should be. And C# is a notable example of a GCed language that also has 'unsafe'. Along with most of the GCed languages with FFIs.
Safe rust can still use crates with unsafe rust, so no. Unless it’s safe rust and uses no outside code or none of its dependency tree has unsafe rust. It’s pretty crazy how many people will argue this point and downvote comments about it. It’s like a C++ dev claiming they never write memory bugs. I love rust, but the community pretending like memory safety bugs are impossible is as annoying as people claiming memory…
> Unless it’s safe rust and uses no outside code or none of its dependency tree has unsafe rust.
If you already know what you want, why pretend there is no solution?
But you skipped the other half of the post, where I explained that the average GCed language either has unsafe code or can easily call unsafe code or both, just like Rust.
Re: Thoughts on what a next Rust compiler would do
#127Earlier quoted context omitted.
Safe rust can still use crates with unsafe rust, so no. Unless it’s safe rust and uses no outside code or none of its dependency tree has unsafe rust. It’s pretty crazy how many people will argue this point and downvote comments about it. It’s like a C++ dev claiming they never write memory bugs. I love rust, but the community pretending like memory safety bugs are impossible is as annoying as people claiming memory…
> Unless it’s safe rust and uses no outside code or none of its dependency tree has unsafe rust. If you already know what you want, why pretend there is no solution? But you skipped the other half of the post, where I explained that the average GCed language either has unsafe code or can easily call unsafe code or both, just like Rust.
If you are doing web backends, you are using crates with unsafe code. Again, I could write C code without memory violations hypothetically the same way I could use no crates, so I guess all rust rewrites are no longer necessary?
As I said in the edit, GC languages are safer than an unsafe language like rust, even if you could find and call unsafe code.
Again, I don’t know why to someone that uses rust I need to make that point. If a C++ dev argued using C++ is fine cause all GC languages can call unsafe code, would you agree? Cause if you do then we might as well end rust now, it’s not adding any safety. All language are unsafe!
Re: Thoughts on what a next Rust compiler would do
#128Earlier quoted context omitted.
My personal issue with Rust isn't the borrow checker. I actually find it quite intuitive. What I don't like is the extreme complexity of everything. There's just so much... stuff. What I want is a Rust, but with almost everything stripped away. Complexity similar to Go.
It's worth pointing out that if you say "Go except with Rust's guarantees for thread safety", a _lot_ of the complexity comes back. You need to pull in lifetimes and move semantics and the no-mutable-aliasing rule. You need the Send and Sync traits. You probably want Deref-based smart pointers too. (And you'd need to make extensive use of the new generics features that are already in Go.)
That's not what I'm saying. I want rust, but with the simplicity of go. I want a compiler that's super portable and it itself compiles in a few minutes. I want a straightforward build system that doesn't leave me confused. I want less language features.
I also want a more lightweight syntax but beggars can't be choosers.
Re: Thoughts on what a next Rust compiler would do
#129Earlier quoted context omitted.
In fairness, I don’t think rust in web dev makes any sense outside of personal hobby projects. I’m not surprised there’s lots of abandoned and unfinished projects there. That’s not an important area.
For backend APIs it absolutely makes sense, not only for the safety guarantees but also its type system which makes data flows much easier to reason about. I recommend the book Zero To Production in Rust in particular for learning about this, I finished it recently and at the end I had a production-ready backend API. https://zero2prod.com
This is a good book. Very hands on and goes all the way.
Re: Thoughts on what a next Rust compiler would do
#130Earlier quoted context omitted.
Safe rust can still use crates with unsafe rust, so no. Unless it’s safe rust and uses no outside code or none of its dependency tree has unsafe rust. It’s pretty crazy how many people will argue this point and downvote comments about it. It’s like a C++ dev claiming they never write memory bugs. I love rust, but the community pretending like memory safety bugs are impossible is as annoying as people claiming memory…
> Unless it’s safe rust and uses no outside code or none of its dependency tree has unsafe rust. If you already know what you want, why pretend there is no solution? But you skipped the other half of the post, where I explained that the average GCed language either has unsafe code or can easily call unsafe code or both, just like Rust.
That's trivially true. But a web backend will preferably use:
- A std library that provides much of the stuff you need to write web servers.
- A few select well established, stable libraries to fill the gaps
- A battle hardened database like SQLite, MySQL or Postgres
- Maybe additional libraries and generators to program against specific, open protocols, standards and over the wire schemas, like json-schema/OpenAPI/GraphQL/Protobuf etc. Which are typically tested against a common test-suite.
- Maybe additional components like message queues and key value stores and object storage in order to scale.
You get the drift. It's not like these things are some random libs and tools that are maybe "unsafe" (whatever that means).
A good thing about Rust is that unsafe is always explicit. And if you're not using the keyword, then satisfying the type checker gives a "if it compiles, it runs" feel, because runtime assertions can be avoided.
But saying "anything is unsafe anyways" is missing the point. The language itself can nudge you towards a certain outcome, but I trust some of the mentioned technologies above, not because of the languages they use, but because they are well designed, stable and full of old battle scars.