
Reflections on Rust, and the Sand Castle Metaphor - craigkerstiens
https://brandur.org/fragments/rust-reflections
======
vvanders
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 stuff most of their career it was nothing
short of incredible.

~~~
weberc2
I 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
[https://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.

~~~
weberc2
> it will cross-compile your C dependencies

That's really cool indeed! Rust's build tooling is truly world class.

------
Animats
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 while back.

~~~
epage
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 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
Too 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
I 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.

------
csomar
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](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.

~~~
urschrei
Who, 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
The 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
This 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.

------
jlg23
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.

~~~
icebraining
It's not even specific to compilers; it's any type-checker. Compilers just
happen to include one.

~~~
simias
Well 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.

------
guelo
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.

~~~
vvanders
What 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.

~~~
SolarNet
The comparison I like to make is that Rust is the safer/modern version of
C++'s memory model. It's in a different class from most languages, but trying
to apply all the latest lessons and techniques.

------
IshKebab
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.

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.

~~~
v_lisivka
You need to type your Python code extremely fast to finish it 10 times faster
than this Rust program:

    
    
        extern crate xpath_reader;
        extern crate regex;
        
        use std::io::prelude::*;
        use std::fs::File;
        
        use xpath_reader::Reader;
        use regex::Regex;
        
        fn main() {
          let mut contents = String::new();
          File::open("test.xml").expect("Unable to open the file").read_to_string(&mut contents).expect("Unable to read the file");
          //println!("File contents: {}", contents);
        
          let reader = Reader::from_str(&contents, None).expect("Cannot parse XML file");
          let files: Vec<String> = reader.read("//file").expect("Cannot find file entries in XML file");
          //println!("Files: {:?}", files);
        
          for file in files.iter() {
            println!("File: {}", file);
            let mut contents = String::new();
            File::open(file).expect("Unable to open the file").read_to_string(&mut contents).expect("Unable to read the file");
            //println!("File contents: {}", contents);
        
            let re = Regex::new(r"foo bar").expect("Cannot compile regex");
            let replaced = re.replace_all(&contents, "baz").to_string();
            //println!("File contents: {}", replaced);
        
            File::create(file).expect("Unable to overwrite the file").write(replaced.as_bytes()).expect("Unable to write to file");
          }
        }

~~~
cortesoft
This is a really silly counterpoint. I am not even sure what point you are
trying to make. How can pasting some program show how long it would take
someone to reason out how to write it?

------
fafhrd91
I 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)

------
andyidsinga
this: "Software is partly a production problem, but it’s mainly a maintenance
problem."

------
jrq
Doesn't have any objective content whatsoever. Not particularly useful for
anybody?

Maybe I misunderstand

