Notes on a Smaller Rust

It's coming from someone who isn't comfortable with C or Java either.

There's no winning over everyone. Of course Rust's syntax will be completely jarring if you're coming from Crystal or Ruby.

In my personal experience it's a little jarring at first and then it completely goes away.

I don't see where you're coming from honestly. It has familiar C-style syntax, it has type parameters in the form java does with <>.

Honestly I have a hard time understanding why you're being downvoted for expressing an opinion.

My first programming language was Python. And now I write Python and Go frequently.

I'm trying to learn Rust, working through various programming exercises, but it looks and feels very foreign to me.

One example is the closure syntax. Compared to Go where closures look just like function definitions, closures in Rust look needlessly complex.

I also always find myself wanting to type mut &a instead of the correct &mut a. The former just seems more obvious to me, a reference to a is &a. Mutable a is mut a. So a mutable reference must be mut &a.

Then the lifetime syntax, I don't even know what to think of that, but that's probably more because I'm struggling asking myself "Should I use a lifetime here, or am I doing something else wrong that is preventing the compiler from figuring it out."

Maybe these things make more sense to people coming from C.

For the record, I consider Clojure to be beautiful as well, in its own way.

I had experience somewhat counter to this. I learned C and C++ first, and when I first started working with Java things like CamelCase did seem a bit strange and off-putting to me, but I got used to the less keystrokes surprisingly quickly, and it's one of the things which bothers me most about working with Rust.

I think there is such a thing as liking what's familiar, but there are also design decisions which are simply easier to read or easier to parse. Another one would be semicolons: I have never missed semicolons one bit in a language where they're not required.

I'm so not a fan of the ruby-style blocks. I never understood the appeal of typing "end" a million times instead of a single close brace.

I think what helps with that is building up a mental model of where things actually live in memory. If you create a new String, you're putting it on the heap. Which makes sense, because strings can be of any arbitrary length. It also makes sense, then, that you can mutate these heap-strings, because they have room to grow. In contrast, the only strings that can go on the stack (so you don't need String::new) are ones whose lengths are known at compile-time. So, a string literal (str).

There are many things like this in Rust where if you just follow the compiler errors until you can make it happy, things will end up really convoluted and baffling. They'll also probably not perform as well. To really use Rust you have to absorb what's actually going on underneath its protections, and not just the errors that surface from them. This isn't easy, and is probably the dividing line between people who stick with it and people who decide it's not for them.

You get about 50% of this picture for free (thinking in terms of stack, heap, references) if you've done C/C++ before. The other 50% is completely unique to Rust. But the key is to read the Book, follow guides, etc. Rust isn't really something you can learn just by hacking it out on your own, unfortunately.

It doesn't really change the paradigm compared to FP even, it just enforces a clear separation at all times between sequential state mutation on the one hand and references to shared (and generally immutable, except as provided for by explicit mutability mechanisms) state on the other. Which is essentially what FP languages end up doing, though they go about it somewhat differently.

> Apparently the Linux kernel, and all code written before 2010 is just completely random!

The Linux kernel is well known to be completely random when considered as a C program: building something useful out of it relies on a particular set of flags and ad-hoc implementation details of GCC (e.g. -fno-delete-null-pointer-checks).

This should be a type error, because there's no further information available to resolve which implementation of FromIterator<> should be used. (Also you'd need to use filterMap to ever arrive at Vec<string> since you can't simply discard the errors.)

Using magic language syntax like checked exceptions in lieu of type system expressiveness is not great, which is why Java's checked exceptions are a bit on the unpleasant side. You can't have one map() that handles functions with and without exceptions, because exceptions aren't part of the type system.

In Rust, exceptions are part of the type system, so you only need one map(). If you also add syntactic sugar for the types such as:

  1: fn foo(i: i32) -> string throws IOException
  2: throw SomeIOException
  3: try a catch IOException b

  1: fn foo(i: i32) -> Result<string, IOException>
  2: return Err(SomeIOException)
  3: match a {
       None => b
       Some(_) => {}
     }

The Rust implementation (syntax I use might vary from reality) of async/await is just this sort of syntactic sugar over a type: "async fn foo() -> X" is sugar for "fn foo() -> Future<X>", and "await!foo()" is (kind of) sugar for "foo().then(rest of the function)".

The only really kind of disappointing thing about this is that exceptions and futures don't get unified: we get ? for exceptions and await! for futures. Both of them ultimately are continuations: exceptions bypass the continuation and return an error immediately, futures call the continuation only when their value becomes available. The value of using a unified interface to continuations (or monads, if you prefer) is that you can use ones that don't have a magic blessed syntax: parsers with automatic backtracking written as simple imperative blocks, non-determinism via iterators where the continuation is a flatten operation, etc.

In Java, you'd expect map() to throw, and the type of y to be Vec<string>, in Rust parlance. If one of the conversions failed, you'd expect the stack to unwind as the exception propagates, and you'd expect that the use of map() means you're not particularly interested in which item failed, you just want to abort (roll back) on failure. This is the 99.9% use case for exception in Java, or C#, or Delphi; you almost never catch exceptions.

If you're interested in which item failed, ideally you'd be using a method that doesn't throw at all, and instead returns an error condition. I like how C# makes this clear, with Parse and TryParse on Int32. You use Parse when you want unwinding and abort behaviour including stack unwinding, and TryParse when you want to handle errors, and you don't use exceptions for expected errors, since expected errors are not exceptional.

(If the map is lazy, you'd expect the materialization in collect() to throw. But the return type wouldn't change.)

IMO, the kind of code you write on a daily basis is the primary determinant of your preference for error codes vs exceptions. If you need to handle error conditions frequently, you'll prefer error codes, because they're data, like all other data, and you can use the general compositional tools at your disposal to manipulate them. If you handle error conditions exceedingly rarely, and mostly just want to abort, unwind, roll back, go back to the main loop and log them, then exceptions are your friend.

I do not think there is a fundamental superiority either way. I think there are tools for purposes. I do think that Java's checked exceptions are half-baked; they're half-way into the compile time type system in a language whose applications are generally better suited to run time exceptions.

Java's checked exceptions are a failed experiment because of subclassing (i.e. eventually you get `throws Throwable` which doesn't give you any useful information). More precise exception tracking is essentially isomorphic to current Rust (Result etc.).

Ensuring error values get all the way to the top-level error handling loop is generally more ergonomic with exceptions, not less. It's easier for values to fall by the wayside, and for errors not to propagate when they're paired (type-wise) with values.

If you do a lot of error handling close to the point of the error condition being found, the Rust / checked exceptions approach works well. For the kinds of applications that are written in Java, it's not the case. Most error conditions need to be propagated and the action in flight aborted.

Automatic propagation without relying on macros like try!, or match with return on Err case.

As you make it easier to propagate the error case to the caller, you asymptotically reach checked exceptions.

Strack traces? I love Rust error handling, but the one thing I sometimes miss is that there is no stack traces by default on errors.

To be clear, Rust does not have "implicit returns" nor does it use semicolons to indicate return values.

Expressions evaluate to a value, and semicolons take an expression, throw away its value, and evaluate to () instead. That's it.

The other behaviors you're talking about fall out of these semantics, but are also different than what you've said; functions evaluate to a value, so the final expression's value determines the value it evaluates to, but you cannot "implicitly return" from the middle of a function by dropping a ;, for example.

I actually love the semicolon semantics. Making expressions and statements disjoint prevents bugs like this:

  if(foo = 5) {
    ...
  }

I guess it depends on your definition of systems development. If you mean "writing systemsy applications" like IoT things or whatever, sure, fine, a GC isn't going to be an issue and probably will help.

If you're talking about a language to write drivers or an operating system, etc in then a GC is just a big No. In that domain we don't even have Malloc/Free, let alone GC services. Having the overhead and normative lifestyle assumptions of _any_ kind of runtime is a big Nope.

> The most efficient way to implement this would be to allocate enough memory to store a1, a2, and a3 and then run the initialization method 3 times over that memory.

Only if a1, a2, a3 are also freed at once. In which case, you can just put all three in a struct that is allocated as a single block. Rust doesn't yet support this very well in the general case, because its support for what C++ calls "placement new" and customized allocation in general is not complete or stabilized. But doing this in a more hackish special-cased way is already possible in many cases.

They have to go via the atomic types or it is undefined behaviour. One can use a very weak ordering (such as Relaxed) to require little or no "physical" synchronisation by the CPU. Like C++, Rust atomics offer a range of levels of synchronisation, weaker than sequential consistency.

A platform like the JVM disguises this because every read and write (even without 'volatile') use minimal synchronisation to avoid the worst aspects of the danger here. This ensures that programs that do it wrong (e.g. forget a 'volatile') are "only" incorrect, but not unsafe.

It's surprising to me that a language hasn't emerged which is more purely a modernization of C. It seems like you could go a long way just keeping C's basic abstraction in place, reworking some of the clunky bits and adding some basic quality-of-life improvements from the past 30 years of language design.