9 ms·
Reflections on Rust, and the Sand Castle Metaphor
- fafhrd91 9y agoI like how author writes! And previous post on web dev in rust is very good as well https://brandur.org/rust-web https://brandur.org/rust-web
- jrq 9y agoDoesn't have any objective content whatsoever. Not particularly useful for anybody? Maybe I misunderstand
- vvanders 9y agoVery 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 stuff most of their career it was nothing short of incredible.
- weberc2 9y agoI have the same experiences with Go regarding xplat. I was particularly amazed that I could trivially cross compile by simply setting the GOOS and GOARCH env vars to the correct operating system and CPU architecture and then running `go build`. EDIT: Curious why people are downvoting this. Is it really so taboo to suggest that Go could be nearly as pleasant as Rust at something? Do I really need to roll out my Rust fanboy creds every time I participate in a thread on the language?
- vvanders 9y agohttps://crates.io/crates/gcc https://crates.io/crates/gcc is even more amazing, it will cross-compile your C dependencies(assuming you have the right compilers setup, which is mostly handled already via rustup or base install). For Android all I had to do was point it to the NDK(for both Rust and the crate) and I got all my C dependencies for basically free. Anyone who's had to work with the NDK knows how nice that is. That's also with zero changes to my build script/code/ifdefs/whatever.
- mastax 9y agoI upvoted you, but perhaps bringing up Go (or Nim, etc.) In every Rust thread is as annoying as bringing up Rust in every Go thread. This article is about comparing languages more or less, though.
- weberc2 9y agoThanks; I used Go because it was specifically referenced in the article. I don’t personally mind people bringing up Rust in Go threads; I do mind pretending there aren’t trade offs, however.
- mpweiher 9y agoHmm..I had the same experience with Objective-C. First on NeXTStep, later with GNUStep. And durability is pretty good, too. I am currently using code I wrote back in the late 90s. Whereas all of Apple's Swift sample code I tried (about non-Swift-specific features such as Apple pencil) would no longer compile. And of course Smalltalk images can be saved on one platform and restarted on another, but that's with a VM.
- pjmlp 9y agoI had the same experience with any programing language with a rich set of libraries since the 16 bit days.
- vvanders 9y agoOh come now, anyone who's worked with C or C++ knows there's a million pitfalls in porting code across platforms. 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.
- pjmlp 9y agoThere are more languages on this world that compile to native code, besides C and C++. It not my fault not everyone bothers to learn them.
- vvanders 9y agoYup, which you're happy to point out in every single thread about Rust. I can set my clock to a post from you about how another language did it first, it's about a useful as a comment saying "+1" these days. Why not celebrate that these concepts are making it into more and more languages? Languages that have rich, vibrant communities and ecosystems. Seems a lot more productive to me then yelling at the kids to get off your lawn.
- pjmlp 9y agoBecause many praise Rust as being the language that did those features first, as if they were re-writing history. Those misconceptions eventually become urban myths and lead to situations like many young devs nowadays thinking that C was the very first systems language, while we old timers know for fact we had plenty of other choices. Rust is a great language, just lets not pretend it is the first in many of its safety or portability features.
- IshKebab 9y agoI 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. A lot of it is just how restrictive the borrow checker is. Often you have to structure your code in a really weird way to satisfy it. 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 +. Another thing I've found is that because of the type inference it often gets really confusing whether a variable is a reference or not. Doesn't help that code completion basically doesn't work at all at the moment. I wish there were a simpler language, like Rust (no garbage collector, no runtime), but that was a little more helpful and willing to do implicit things even if they are slightly slower than the most optimised code possible.
- xboxnolifes 9y ago> 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. That doesn't surprise me at all. Writing it in C++ would probably take me a lot longer than writing it in Python too.
- lmm 9y agoWhy is that the comparison point though? How long would it have taken in, say, OCaml or Haskell, which would have given similar correctness guarantees to Rust?
- kadenshep 9y agoBecause Rust is a systems language?
- lmm 9y agoWhat 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 advertising it for non-systems uses).
- csomar 9y agoThis 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 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.
- bvinc 9y agoIt's even easier than that: let buf = [0u8; 810241024];
- urschrei 9y agoWho, ever, anywhere, has claimed that "Rust fixes all possible problems"? This is a straw man. As for bad code leading to overflows and crashes: yes, bad code causes overflows and crashes, definitionally. Rust does not, and has never claimed to protect against logic errors in this way. How could it?
- edflsafoiewq 9y agoThe language in the article is very strong. > Rust is another step into the beyond. When finishing a feature and its test suite I’ll run my program to see it in action, but just as a formality – I already know it works. I also know that it’s going to keep working because meticulousness of the compiler is so good at catching regressions.
- sargas 9y agoThis is a bold statement, specially because not many other languages have such high quality guarantees at compile time. > I already know it works This is the part I don't agree all of the time, but depending on the scope and size of the project, I've seeing this be true. And the compiler is really good at catching regressions, submitting PRs for Rust projects is not easy in the beginning, but it is very hard to insert a regression.
- 9y ago
- jlg23 9y agoThis 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.
- icebraining 9y agoIt's not even specific to compilers; it's any type-checker. Compilers just happen to include one.
- simias 9y agoWell it's more of a feature of the language really. The type of static type checking provided by Rust would be impossible to achieve in C or Python for instance, unless you add specific annotations to augment the language's type system.
- pjmlp 9y agoThe advantage is that it not possible to forget to use it.
- simias 9y agoI agree with you if we replace "dynamic language" by "not as strongly typed". C is not exactly dynamic but its type system is prehistoric compared to Rust. For instance C's equivalent of Rust's enum would be tagged unions, however the compiler cannot enforce the semantics of tagged unions and will gladly let you access random members regardless of the tag. Same story with the borrow checker compared to C's "whatever you say chief" approach to resource management. Rust is definitely not the only one to offer these guarantees and some languages even go further (such as Idris for instance). The reason Rust stands out is that it can be used basically anywhere you'd use C or C++, something few other languages can claim.
- jlg23 9y agoI agree, just did not consider it worth anyone's time to go into details the OP does not even touch. The article compares rust with js and ruby....
- guelo 9y agoI 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.
- iopq 8y agoOf course it's safer. It prevents you from doing a null pointer exception. That just by itself is a big enough win not to even use Go or Java ever again.
- vvanders 9y agoWhat Rust gives you over Java is determinism. Having a GC doesn't preclude you from leaking resources(file handles, textures, etc) and you're at the mercy of whenever the finalizer decides to run once the GC has determined it's time to free an object. Usually this manifests as your Java application humming along until you hit some GC threshold cliff and then perf/memory plummets. I also can't enforce ownership in Java which drives me up the wall. Once you hand out a ref anything is fair game and calling code is free to add that ref to the root GC set so that it never gets freed.
- icebraining 9y agoRust doesn't have the Billion Dollar Mistake, as far as I can tell. That alone makes it safer than Java.
- Animats 9y agoIt'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 while back.
- epage 9y agoFrom 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 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. [0] https://aturon.github.io/2018/04/24/async-borrowing/ https://aturon.github.io/2018/04/24/async-borrowing/
- Animats 9y agoToo many articles about Rust talk about why the current language sucks, but some feature in progress will fix it. Rust started out with roughly the complexity level of C++, and it's become more complex from there.
- lossolo 9y agoI agree with both of your comments, I've noticed exactly the same thing. Every feature that fix something brings more complexity and have probability that will not interact nicely with some other features which means you need to make another feature that will fix that and then that feature... Soon people will use different dialects of the language like in C++ and like in C++ only few will be able to say that they really know the language. How will managing huge enterprise projects will look like in future? With average developers maintaining it and not language experts like in case of Mozilla Servo? Time will tell I suppose. I am little bit pessimistic but I hope to be proven wrong.
- andyidsinga 9y agothis: "Software is partly a production problem, but it’s mainly a maintenance problem."