301–310 of 459 posts
Rust is pain when you want to be super basic with your types. This is actually a learning lesson for the user to understand that the bugs one has seen in languages like c++ are inherent to using simple types. The author goes about mentioning python. If you do change all your types to python equivalents, ref counted etc. Rust becomes as easy. But you don’t want to do that and so it becomes pain, but pain with a gain.…
Earlier quoted context omitted.
Agreed. As a comparison Golang was sold as "CSP like Erlang without the weird syntax" but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages. The actual core of OTP was the supervisor tree but that's too complicated so Golang is basically just more concise Java. I don't think this is a bad thing but it's a funny consequence that to become mainstream you ha…
[flagged]
Most programmers are "lousy programmers" because most of the are not researchers and have no interest in theory.
I can write in Go or Rust (or anything else given some time) but I won't ever use Rust to write any kind of business logic for my company - and this is what I do most of the time I actually write code.
Why? Because Rust is terrible for the job (at least if we are talking about real life scenario where the job should be done in hours and not weeks)
Earlier quoted context omitted.
Whoah, hold on, the author isn't comparing writing graph structures in Rust to writing it in memory-unsafe languages --- they're comparing it to writing it in other memory-safe languages . You can't force a false dichotomy between Rust and C to rebut them.
I think it's reasonable enough. The author already argued that there are reasons for non GC languages to exist, even if the performance doesn't matter to them. One interpretation of the article is just the author doesn't personally like the borrow checker, but another interpretation is the author saying the borrow checker is just a bad abstraction. So under the assumption that we don't have a GC available, what else…
You encounter borrowchecker issues? Well, you're just a beginner or not skilled enough. Rust makes you jump through hoops? No it doesn't, it just makes you pay upfront what you otherwise would have. It slows development? No, studies show it doesn't, you must be imagining it.
This is extremely annoying to be on the receiving end of. Even though it comes from a good place (mostly just excitement), it can feel like gaslighting.
I used Rust for about an hour and immediately ran into an issue I found amusing. The compiler changed the type of my variable based on its usage. Usage in code I didn't write. There was no warning about this (even with clippy). The program crashed at runtime. I found this amusing because it doesn't happen in dynamic languages, and it doesn't happen in languages where you have to specify the types. But Rust, with its…
One of his examples of a borrow checker excess: struct Id(u32); fn main() { let id = Id(5); let mut v = vec![id]; println!("{}", id.0); } isn't even legit in modern C++. That's just move semantics. When you move it, it's gone at the old name. He does point out two significant problems in Rust. When you need to change a program, re-doing the ownership plumbing can be quite time-consuming. Losing a few days on that is…
(Emphasis mine.)
I just had a thought! It might make languages like Rust more ergonomic if movement could also update the reference to the new location so that moving a local variable into a container could also update the variable to reference the target also.
The "broken" example can be trivially fixed:
fn main() {
let id = Id(5);
let mut v = vec![id];
let id = v[0].0; // just use the new name!
println!("{}", id );
}
Something like:
let mut v = vec![@id]; // Some new symbol
I don't use Rust much, but I agree with the thrust of the article. However, I do think that the borrowchecker is the only reason Rust actually caught on. In my opinion, it's really hard for a new language to succeed unless you can point to something and say "You literally can't do this in your language" Without something like that, I think it just would have been impossible for Rust to gain enough momentum, and also…
Agreed. As a comparison Golang was sold as "CSP like Erlang without the weird syntax" but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages. The actual core of OTP was the supervisor tree but that's too complicated so Golang is basically just more concise Java. I don't think this is a bad thing but it's a funny consequence that to become mainstream you ha…
There are some artificial limitations, but I love the upside: I don't need defensive programming! When my function gets an exclusive reference to an object, I know for sure that it won't be touched by the caller while I use it, but I can still mutate it freely. I never need to make deep copies of inputs defensively just in case the caller tries to keep a reference to somewhere in the object they've passed to my funct…
I love how this very real problem can be solved in two ways:
1. Avoid non-exclusive mutable references to objects
2. Avoid mutable objects
Former approach results in pervasive complexity and rigidity (Rust), latter results in pervasive simplicity and flexibility (Clojure).
Earlier quoted context omitted.
Agreed. As a comparison Golang was sold as "CSP like Erlang without the weird syntax" but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages. The actual core of OTP was the supervisor tree but that's too complicated so Golang is basically just more concise Java. I don't think this is a bad thing but it's a funny consequence that to become mainstream you ha…
But gorutines are better than threads when you need you need many (say >100K) of them. Lightweight threads are not unique to Go but in Go they are easy to use and the default way to build network applications. Java is catching up with project Loom but it would never be as easy as Go to use.
Stackless coroutines are even more efficient for that case, and Rust makes them comparatively easy. (And slated to get even easier in future versions, as the async support is improved further.)
Moreover stackful coroutines/fibers as used in Golang also makes it infeasible to have seamless FFI with the standard C API/ABI, which cuts you off from the bulk of the ecosystem. There are other issues too with having fibers in a C-like systems programming language - see https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p13... for a nice summary of them.
Earlier quoted context omitted.
The "X is like Y but Z" game w languages is pretty fun, and kind of illuminating as to what one thing you pick. Go is like C but with concurrency/strings/GC/a good stdlib Go is like C++ but simpler/fast compilation/no generics/a good stdlib Go is like Python but statically typed/multithreaded/fast/single executable Go is like Java but native/no OO --- One thing Go haters rarely reckon with is that Go is the only popu…
> One thing Go haters rarely reckon with is that Go is the only popular modern language (ie from this millennium). This requires you to squint so that "popular" happens to identify only a handful of languages but conveniently catches Go and not say Swift or Rust. It's not difficult to do this, but it's not very honest to yourself.
Earlier quoted context omitted.
Idiomatic programming in a functional language requires garbage collection. There is a reason languages like OCaml and Haskell have a garbage collector. Without it, programming in these languages would be completely different. If you look at it from that perspective, then Rust is the hobby language.
> Idiomatic programming in a functional language requires garbage collection. Rust has functional programming features and no garbage collection, because the borrow checker can tell when a closure will outlive the references in its captured environment. We used to think that would not be feasible other than perhaps in very special cases - hence the need for GC to keep that environment around - but Rust proved that wr…