Ive used Rust professionally for six years now and have done many quick hacks. It is really easy to do. Basically just don’t use references / clone everything to avoid lifetime and ownership issues, and use unwrap everywhere to avoid proper error handling. It’s really that easy almost all the time.
The nice thing about that is once you’re done with the prototype, just remove the unwraps and you can optimize stuff by removing the clones.
The borrow checker is useful for a lot more than memory safety. This is something I have been repeating for years, but unfortunately people new to the language don’t understand it yet.
E.g. Rust is the only mainstream language where it isn’t possible to read from a file handle after it’s been closed. There are numerous other common benefits of it that apply to general purpose programming, like not being able to mutate a collection while you’re iterating over it.
It’s a very common practice in Rust to enforce domain invariants using Rust’s ownership rules, and those things cannot be enforced at compile time in other languages that don’t have ownership.
The borrow checker is also usually pretty easy to get around with just a bit of experience in Rust.
What I’m curious about - this function was already const, so for stuff like this, is think there’d basically be a 100% chance the compiler would optimize this too so it implicitly.
AFAIK new feature is just for times when it isn’t an optimization, but more your own domain invariants. E.g. assertions.
But I couldn’t be wrong. I wonder if this can be used for actual optimizations in some places that the compiler couldn’t figure out by itself.
What I said isn’t even what I’d consider subjective. There is a very clear, logical, scientific reason for that. Not sure what you think I’m wrong about.
Can you give an example of why you think Rust just makes it needlessly hard to refactor?
Rust is probably great for systems that don’t have a lot of changing requirements, but fast iteration and big changes probably aren’t its strong suit.
I agreed up until this. Fearless refactoring is a huge benefit of Rust. If the type system of another language allows the refactoring more easily without as many compilation failures, it will probably surface more runtime bugs.
Hyper was the standard for Rust web servers way before it was used by curl for anything.
A lot of it is about moving problems from runtime to compile time. JS, for example, has most problems live in runtime.
Imagine you’re hiring an event planner for your wedding. It’s an important day, and you want it to go well and focus on the things that matter to you. Would you rather hire an even planner that barely interacts with you up until the wedding because they’re so “easy to work with”? Or one that gets a ton of info and meets with you to make sure they can get everything they need as early as possible?
Rust is like the latter. JS is like an even planner who is just lazy and says “we’ll cross that bridge when we come to it” all the time.
C++ is like a meth addict.
I didn’t say types. I said find references / go to definition / rename.
Types are not necessary at all.
Why would it just be best effort? To find references for a specific thing, it still would parse an AST, find the current scope, see it’s imported from some module, find other imports of the module, etc.
Rust still can have race conditions
Or even just clone. Depending on use case the performance cost would be negligible.
You can go to definition / find references / rename for dynamically typed languages too.
It’s not clear to me what the author considers “questionable choices” for Rust.
Wouldn’t distributed moderation kind of remove distribution in a sense? Your impl sounds like it’s distributing compute, but more central in control. E.g. Lemmy mods can only mod their own instances, so power is distributed more than if they could mod any instance.
That hasn’t been my experience at all, and it’s been for both large refactors as well as complete rewrites.
Rust does care about some things like not having self referential structs or recursive types, but those are super easy to fix. Rust pushes you to not write code in the same way as other languages, and IMO that’s a very good thing. It’s not at all about systems stuff or memory layouts.
Rust’s ownership system is used to simply enforce correct usage of APIs. Memory safety is simply a subset of correctness. Many other languages, Java for example, don’t enforce thread safety, so you have to be really careful when parallelizing your code. In Rust, you could hire an intern fresh out of high school and I can know 100% that they’re not making mistakes with sending data across threads that isn’t thread safe.
Another example is file handles. Rust is the only mainstream language where it’s not possible to read from a file handle after it’s been closed. That has nothing to do with memory layout or systems concerns. That’s a basic invariant across all languages, and Rust stops you from making a mistake. Same with things like mutating an iterator during iteration and all kinds of other stuff.
That does mean it is more painful upfront, but that’s a good thing. You’ll run into many of the same problems in other languages, but at runtime, which is much worse.
As for graphs, I doubt the vast majority of programmers need to build custom graph structures.
You’re of course free to disagree. Just weighing in with my perspective.
Extremely hard disagree on the last statement. It certainly has tradeoffs, but they are almost all very valuable to many general applications which don’t need performance at all. I’ve been using it professionally for a very long time now and migrated multiple companies from JS, Python, Java, and C# to Rust and it brought huge advantages.
I didn’t love that article - Rust isn’t strictly a systems language. It’s general purpose, and a lot of the mechanics are very useful for general programs.
That’s a sad attitude to have. Rust is really great, but it does have a learning curve. If you do want to give it a shot, just reach out online and there are many people who can help with suggestions.