51–60 of 89 posts
I was a big fan of Rust at first, but I bailed out a while back.
I have a hard time believing that Rust's guarantees make it safer than easier statically typed languages like Java or Go. Rust is hard because it is solving a different problem, memory management without a garbage collector, not because it has the strongest correctness guarantees.
Rust doesn't have iterator invalidation issues or "ConcurrentAccessException" which are very nice for writing highly concurrent code at large scales. Throw in niceties like no null, result types for better error typing, and a culture of correctness and you've got a really nice language for writing correct software. Go and Java are certainly good at writing correct software too, especially compared to python or javasc…
It's not the borrow checker that the author considers a problem. It's move semantics and futures. The borrow checker was a huge breakthrough in language design. Some of the other new stuff is marginal. Trying to hammer Rust into a functional language via the template system was probably a mistake. Too many "see what cool things I can write in one line" features. I was a big fan of Rust at first, but I bailed out a wh…
> This is especially true when it comes to the more complicated ones like moves and futures, but also true for simpler ones like borrows. What I didn’t know when I wrote about it in frustration a month ago is that it doesn’t take a little longer longer to be effective in Rust compared to other languages, it takes 10 to 20 times longer.
I think futures might be exacerbating the authors problems. There was a recent post [0] that does a good job explaining why futures are so hard and how the in-progress async/await features fix it.
This is not at all specific to rust: OP is just grateful for the compiler to find lots of problems one would have to write tests for in dynamic languages.
The borrow checker is the primary reason I feel this way. A smaller aspect is how easy it is to write white box unit tests. I can have an equivalent of a C++ static function in Rust and run unit tests on it. For C++, I'd either have to hack up the source files for when building my unit tests or make turn the function from static to being exposed in a header so my tests can access it.
It's not the borrow checker that the author considers a problem. It's move semantics and futures. The borrow checker was a huge breakthrough in language design. Some of the other new stuff is marginal. Trying to hammer Rust into a functional language via the template system was probably a mistake. Too many "see what cool things I can write in one line" features. I was a big fan of Rust at first, but I bailed out a wh…
From the article > This is especially true when it comes to the more complicated ones like moves and futures, but also true for simpler ones like borrows. What I didn’t know when I wrote about it in frustration a month ago is that it doesn’t take a little longer longer to be effective in Rust compared to other languages, it takes 10 to 20 times longer. I think futures might be exacerbating the authors problems. There…
Rust started out with roughly the complexity level of C++, and it's become more complex from there.
I do think the difficulty of Rust is brushed aside by its proponents. This week I wrote a little script to read an XML file, get a path from it, read a file at that location, do some regexes on it, and then update the XML and write it back to disk. I'd estimate it took me about 10 times longer to implement in Rust than Python. And I don't exactly know Python well - it wasn't just extra time Googling how to do things.…
I've rarely found this the case for me but I came from C++ and am generally used to thinking in terms of lifetimes. Could you elaborate on how you ran into problems with borrows messing up code structure?
> Dealing with strings is another pain point. I get why there is `&str` and `String`. But that doesn't explain why I can't add two `String`s together using +.
I feel like the Rust stdlib takes after C++ in making costs obvious to people and not providing shortcuts for slow operations, causing the ergonomics to scale with performance.
Something that some of us in the CLI-WG have been talking about is creating a library that interops with the standard library but instead focuses on python-like semantics at the cost of performance. This will be a big benefit for "quick scripts" and people learning the language while allowing people to still fall back to high performance idioms as determined by a profiler.
Unfortunately, this is a little lower on our priority list for now.
Earlier quoted context omitted.
Because Rust is a systems language?
What does that cash out as that the programmer cares about though? A task like "read an XML file, get a path from it, read a file at that location, do some regexes on it, and then update the XML and write it back to disk" doesn't need any special systems-ness (and maybe Rust is only a suitable choice for problems where you need that systems-ness, but people seem to be writing a lot of ordinary code in it and advertis…
To address the heart of what you're getting at: I don't buy the fact that it took "10x" longer to read an XML file. I'll give you some amount of "longer" just by virtue of Rust's general strictness and lengthy semantics (like any systems language), but you can't just squash together your unfamiliarity with the language or its libraries and use that to determine the base line difficulty of implementation. To highlight this, consider a seasoned C# developer trying to read an XML file in python for the first time. It would probably take them "10x" longer in python too, and it won't be because the languages have different purposes/audiences or the languages' rules and conventions.
This is indeed very light in content. Also, while Rust fixes a whole set of problems, it doesn't mean that Rust fixes all possible problems. It is relatively easy to create a situation where you overflow your program. See here: https://github.com/rust-lang/rust/issues/50049 Googling around, there are many situations where bad code can lead to an overflow and your code breaking.
This is the equivelent of `~Foo() { Foo f; }` isn't it?
fn main() {
let a = 3;
assert(a == 2, "a should definitely be 2");
}
I have a hard time believing that Rust's guarantees make it safer than easier statically typed languages like Java or Go. Rust is hard because it is solving a different problem, memory management without a garbage collector, not because it has the strongest correctness guarantees.
In addition the explicit error handling (together with enum error types) allow the compiler to check that you have handled every error case.
Rust has enabled me to write programs that just don't contain bugs (after an initial testing period). This is certainly acheivable with other languages, but it involves a lot of discipline, writing tests, etc. Rust makes it easy.
Very much matches my experience with the last ~2.5 years of Rust. One of the really eye-opening ones for me was building a UI library on win32 and watching it just work on Linux, OSX, Android and WASM(with some Canvas work). Obviously each platform took some work to build out their respective rendering primitives but the core engine(including embedding Lua via gcc crate) just worked. As someone who's done x-platform…
I had the same experience with any programing language with a rich set of libraries since the 16 bit days.
Heck, C doesn't even guarantee that a byte is exactly 8 bits.
The point I was making is that I was able to do this without a single ifdef/platform specific code without even planning for it(since it was the first time I'd cross-compiled for more than one other platform). While that's common in the VM language space seeing that in a compiled language was refreshing.