Notes on a Smaller Rust

https://boats.gitlab.io/blog/post/notes-on-a-smaller-rust/

by telotortium • 7 years ago

103 116 7 years ago

boats.gitlab.io

dwenzek• 7 years ago

I like how the strengths of Rust are summarized by 3 points:

* Algebraic data types

* Resource acquisition is initialization

* Aliasable XOR mutable

I think it can help not only to design a Smaller Rust as discussed here, but also to grasp the key design points of this language which is a bit daunting.

nudq• 7 years ago

I like how these three points aren't just "strengths of Rust", but...

the necessary components ... to make imperative programming work as a paradigm

You know, before Rust imperative programming just didn't work. Didn't work as a paradigm, even!

_bxg18• 7 years ago

It had state mutation as a massive liability - which is probably why FP has seen such a surge in recent years. Rust is the only language that mostly solves that without totally changing the paradigm.

skohan16• 7 years ago

There seems to be a certain train of thought within the Rust community that unsafe languages are fundamentally invalid. I saw a comment on another forum claiming that C++ was even unsuitable for personal, experimental projects because unsafe code == undefinted behavior, and therefore your program produces "random results" which would not be fit for, say, scientific inquiry.

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

swsieber2• 7 years ago

Rust works because it enables users to write in an imperative programming style, which is the mainstream style of programming that most users are familiar with, while avoiding to an impressive degree the kinds of bugs that imperative programming is notorious for.

That's from the previous paragraph. So yeah, out of context it's a bad quote, but in the context it's a little less hoity toity.

logimame• 7 years ago

There's also the trait system, which although isn't unique in Rust, has many advantages over the inheritance-based class system that languages such as C++/Nim/etc uses. Rust's trait system can be both used for static and dynamic polymorphism seamlessly (basically, impl T vs. dyn T). But in C++, you need different systems for doing so: templates (via hacks such as CRTP/SFINAE, or concepts in C++20) vs. virtual/override. Note that Go has interfaces which is the closest thing to traits, but only allows for dynamic polymorphism (because Go doesn't have generics yet... it seems like it's going down a similar path to C++20's concepts)

rishav_sharan3• 7 years ago

As someone who recognizes himself as beginner programmer, i do not consider the borrow checker as my major issue with the language. Heck, i haven't even reached that issue.

Everytime that I have turned away from Rust, despite trying half a dozen times is due to its super busy and alien looking syntax. I just can't parse the code.

paavohtl• 7 years ago

What other languages do you have experience with? IMO the syntax is not wildly different from other statically typed curly bracket languages. IMO the most alien thing it has in terms of syntax is the use of a single quote for lifetime parameters ('a), but even that is based on the type parameter syntax for already existing languages (OCaml, F#, Standard ML).

rishav_sharan3• 7 years ago

Crystal and vanilla es6 are my favoured languages. I also adore elixir. I have recently done some toy projects in f# using xelmish. I have written small projects in python, nodejs and lua. I have also tried Nim and wren. So while i am not much of a programmer, I love trying new languages. Out of all the languages that I tried, Rust and lisp are the two which scared me off outright just based on the syntax

MrBuddyCasino3• 7 years ago

Rust is unpleasant to look at. I know its silly, but that my biggest gripe with it as well, aside from sometimes overly complex type signatures due to generics. As a reference, I consider Python and Kotlin to be a e s t e t i c.

slezyr• 7 years ago

And crystal lang, for static typed language example.

https://crystal-lang.org/reference/overview/http_server.html

adestefan• 7 years ago

What was the first programming language you really understood and learned? I ask because most of the time people think something different is complex or "ugly" it's because they're using bad abstractions between what they fully understood first to other things they think is in the same domain.

Patricia Asa has an excellent presentation[0] on how she tried to learned C# and one of the biggest things she discovered was these bad cross-over abstractions held her back.

[0] https://www.youtube.com/watch?v=Id2jBMJLz2Y

lloydatkinson• 7 years ago

I have the same experience - I don't know what the hell is going on in the code with Rust. Compared to say F#, its far more verbose and feels too much like C++.

In the same vein I think Typescript error messages are absolutely horrific. Furthermore, I keep seeing people who start using Typescript to "make it like my preferred language xyz".

Coincidentally these devs 1) hate Javascript 2) end up writing a massively over engineered OO big ball of mud

These reasons are why I avoid Typescript where I can.

pdpi• 7 years ago

Honestly, I don't see any intrinsic problems with Rust's syntax that makes it unusually ugly.

Rather, I think the problem is that the syntax is 100% fine in isolation, but has some issues when taken together with experience in other languages — when you skim the code, some parts of it beg to be looked at like C++, while other parts push you to read it like a functional language. Unsurprisingly, neither fully works, which makes the experience jarring. Once you accept that Rust is its own language with its own rules and stop trying to borrow (hah!) from your experience with other languages, it feels much better.

guiriduro• 7 years ago

Oh yeah, I totally get that with Nim's * (export symbol), just can't get past my 20 years ago c++ pointer syntax brain wiring, even though I've barely touched it since. Always needs a double-take, which spoils reading flow.

sagichmal• 7 years ago

Honestly, I don't see any intrinsic problems with Rust's syntax that makes it unusually ugly.

You literally just got a user experience report claiming that it is.

Spartan-S63• 7 years ago

I had many many false starts back in 2014 when I tried learning Rust. It took me to stop comparing it or thinking about it like C++ (syntactically and semantically) in order for me to get it. Now, I’d consider myself reasonably fluent in Rust.

I don’t mind the syntax because I find it explicit enough, but terse enough in certain cases. It’s similar but different and so it rhymes with my past in C++, but it’s not the same.

sixbrx2• 7 years ago

Agree and also I think the main issue is that parts of the syntax are pointing to ideas that are not present in common languages, but which are essential in Rust. They aren't merely syntactical choices and can't be papered over or omitted. If you don't want to consider these concerns (like lifetimes) then it's probably not the language for you and changes in syntax won't help (much) there.

_bxg18• 7 years ago

Maybe it's my background (Java and JS with a little bit of C++), but I don't find it alien at all. I do find it really clunky in a handful of situations, mostly having to do with lots of nested containers (Option<Arc<Box<...), but luckily those are uncommon for most use-cases.

skohan16• 7 years ago

The bit which seems the most cumbersome to me is working with things like str/String and Path - it seems like there's always a lot of finagling and long chains of method calls to get things into the right type representation for a particular use-case.

I'm still not so experienced though so maybe it gets better.

lmm10• 7 years ago

Interesting. Coming from an FP background I'd say the opposite - the confusing part of Rust is all these special-case imperative control flow keywords, a more smalltalk-like "everything is just values and functions" syntax would be the best way to simplify it.

I'd agree with stepping away from guarantees about when allocations happen etc. But I think at the point where you remove those from Rust you really just have OCaml.

cmrdporcupine2• 7 years ago

Well, it'd be OCaml without a garbage collector. And to be honest, that would be a very useful and handy language for systems development.

masklinn2• 7 years ago

OCaml has for and while loops. Its for loop is even more imperative than Rust's (which simply drives an iterator, whereas OCaml's has "for a to b" and "for b downto a").

OCaml doesn't have break or continue though.

lmm10• 7 years ago

OCaml is already a good language for systems development - people are far too scared of garbage collectors. And if you make the changes in the article then I think you give up most of the concrete benefits of non-GC - you won't have easy C interop without control of stack/heap/allocation, and since trait objects could end up nested arbitrarily far, I think you might still get GC-like pauses where a simple-looking code line ended up doing an arbitrary amount of unwrapping and freeing work.

viraptor• 7 years ago

special-case imperative control flow keywords,

Which ones do you mean?

masklinn2• 7 years ago

Not OP but from what they're saying I'd guess loop, while, for, continue, break, return. Possibly do (which is reserved but not used), could be a do{}while or a monadic block, who knows.

Though it should be noted that Smalltalk provided a non-local return.

0815test4• 7 years ago

a more smalltalk-like "everything is just values and functions" syntax

Can you do that sort of thing without a GC? Some functional languages use tailcall as their control flow primitive, but that's just a glorified GOTO.

lmm10• 7 years ago

I don't see why not? Rust has first-class functions and its lifetime support is supposed to be a big selling point, so it ought to be possible to implement things like "if" and "for" as userspace functions - and if not, then that suggests important limitations to its lifetime/ownership model.

_bxg18• 7 years ago

I think one thing that confuses people about Rust is it sends mixed signals with regard to functional vs imperative. It gives you lots of nice functional toys - closures, implicit returns, pattern matching - but you end up having to write a lot of imperative stuff too.

I've found that Rust flows much more nicely when you just embrace an imperative style "by default". That's its native tongue; the functional stuff is more of an exception.

Those of us used to multi-paradigm languages have taught ourselves that imperative == bad (actual for-loops! egads!), but the thing is, Rust is specifically designed to make it not-bad. It gives you all these tools to carefully control and limit mutability, so you can do imperative stuff with much less fear. It takes getting used to but in my (limited) experience this mindset significantly reduces friction when working with Rust.

skohan16• 7 years ago

I haven't spent a lot of time with FP languages over the years, but implicit returns are one of my least favorite features of Rust. Especially the use of semicolons to denote a terminated statement vs. a return value: a semicolon-related typo is such an easy mistake to make, and an annoying reason for a build to fail, especially when so many modern languages have shown it's quite possible and pleasant to work without semicolons.

MrBuddyCasino3• 7 years ago

I would probably experiment with exceptions if I were making this language.

Hard disagree. Rust made conscious design decisions (i.e. limiting type inference) to enable local reasoning, and exceptions are non-local.

barrkel6• 7 years ago

Checked exceptions (like Java) are isomorphic with Rust's Result type. You could convert a checked exceptions syntax into Result exception-carriers on each return with a mechanical transformation, of a Rust+exceptions program into Rust-today program.

Sharlin• 7 years ago

And nobody, nobody, likes checked exceptions. Perhaps with appropriate syntactic sugar they could be made ergonomic, but Java's checked exceptions at least were a failed experiment.

wtetzner2• 7 years ago

What benefits are there to checked exceptions over Rust's `Result` type?

akavi2• 7 years ago

Not all isomorphic representations are equally ergonomic. Exceptions require special additional syntax, Result is “just” another value.

lmm10• 7 years ago

Suppose you have

    fn foo(i: i32) -> string throws IOException
    let x: Vec<i32> = ...
    let y = x.iter().map(foo).collect()

What's the type of y ? There are no good answers here: if it's Vec<string> then where did the errors go? If it's Vec<Result<IOExecption, string>> then the user is pretty confused about where the Result came from. You can't propagate the IOException through the map() call in the general case (it might be in a third-party compiled library etc.). In Java this is a compilation error and the reason checked exceptions are useless in practice.

coldtea• 7 years ago

In other words, the core, commonly identified “hard part” of Rust - ownership and borrowing - is essentially applicable for any attempt to make checking the correctness of an imperative program tractable. So trying to get rid of it would be missing the real insight of Rust, and not building on the foundations Rust has laid out.

Sure, but people wanting a smaller Rust might not care about the "real insight of Rust", but of the surface syntax, speed, apis, tooling (e.g. cargo), and so on...

I'd like a Rust like language that's GCed for example, and drops all the lifetime annotations and so on...

lucian1900• 7 years ago

That’s basically Swift.

mathw• 7 years ago

I guess it depends what you think is the real core of Rust - for me, Rust's primary innovation and primary differentiation point is giving you safe memory management without a garbage collector. Anything that steps away from it (so stepping away from the borrow checker, lifetimes and so on) becomes something that isn't Rust anymore.

After all, just about everything else in Rust is in Haskell.

mrfredward• 7 years ago

The borrow checker is undoubtedly the core innovation of Rust, but it's not what people new to the language want. When I first came to rust, I was looking for a c++ alternative that had similar syntax and low level power, but also a sane standard library and modern language features like closures.

When I first learned about the borrowchecker I thought it was brilliant. Then I spent some time fighting it and I hated it. Then I learned to love it...until I got backed in to a corner and had to re-architect a project I'd been working on for months. Now I have mixed feelings about it.

So I agree Rust isn't Rust without the borrowchecker, but I empathize with all the noobs who want a rust without it because many people just want a language with some traction that fixes c++ past mistakes, and they end up getting a massive paradigm shift thrown at them instead.

sametmax• 7 years ago

Rust seems like a great language to write other languages in. Not as convenient than a lisp but, zero-cost abstraction, safe, fast and close to the metal.

So you may be see a rustscript at some point. Some people try to implement Python in it, which I think is very interesting: https://github.com/RustPython/RustPython

After all, replacing C/C++ is the raison d'être of rust.

tomp5• 7 years ago

I'm really conflicted about

Aliasable XOR mutable

because it prevents eventual synchronisation (e.g. single writer, multiple readers of a "monotonic" data structure like a counter)... I'm not convinced that it's entirely necessary, nor how easily it can be proved safe, but AFAIK many garbage collection runtimes work using eventual synchronisation... Probably other algorithms as well!

Another thing that's not (AFAIK) covered by Rust's ownership system is flexible memory pools... where you can have proofs that some memory is accessible and pass those proofs around (whether at runtime, or just during compilation on the type system level)... although that might be entirely isomorphic to just passing around owned pointers to memory (pools), so maybe Rust does support it.

People with lots of experience with Rust, what scenarios do you need to use unsafe Rust for?

dbaupp2• 7 years ago

Interior mutability via atomic values (https://doc.rust-lang.org/std/sync/atomic/index.html) works great for the first one, and, indeed, some sort of atomicity/synchronisation is required even in languages without the XOR rule (such as C++) to prevent undefined behaviour.

There's a variety of safe arena types that give allocation inside pools too: https://crates.io/search?q=Arena&sort=downloads

tomp5• 7 years ago

Atomics are very useful indeed, but an overkill for some situations. In particular, if there's just one writer and multiple readers, the write doesn't need to be synchronised (as there's no possibility of someone else mutating the value in the middle of you incrementing it). An example would be the GC thread incrementing the epoch id/count that all mutator (user) threads read.

Presumably you'd still need some sort of synchronisation otherwise the memory will stay mutated just in one CPU's cache, you need to "flush" the updated memory so that other CPUs can then see it, but that's likely cheaper than executing the whole operation atomically... Basically, increments are fundamentally not atomic (i.e. composed of multiple separate operations) whereas reads (of a single word) are, so if all mutations happen from a single thread (assuming a sensible CPU architecture and cooperative compiler) there's nothing else that needs to be done to ensure atomicity, you only need to care about the "happens before" relationship.

But then I'm not a low-level programmer so the above is probably all wrong :)

akavi2• 7 years ago

The lack of ADTs in mainstream languages is really quite baffling, given their obvious utility.

Thankfully it looks like they’re trickling in via Typescript/Swift/Kotlin.

sambal• 7 years ago

Do TS and Kotlin support them now? Last I checked TS was relying on string comparisons and Kotlin wasn’t even bothering outside sealed classes

sixbrx2• 7 years ago

TS is a bit more powerful than it appears here, because string literal values are recognized at the type level, so can be checked by the compiler when distinguishing cases. See for example: "Discriminated Unions" at https://www.typescriptlang.org/docs/handbook/advanced-types.....

skohan16• 7 years ago

Resource acquisition is initialization

I recently built a small prototype Entity Component System, and one of the big learnings for me was to what extent RAII is an anti-pattern with respect to performance. It's actually amazing how fast a modern CPU can be when you're not using it to allocate and initialize small blocks of memory at a time.

I understand the benefits of RAII in terms of bookkeeping, but it seems like there is opportunity for a new resource management paradigm which is more optimized for using computing resources.

PyroLagus• 7 years ago

Can't you just initialize everything at once before you need it rather than initializing one object here and there?

skohan16• 7 years ago

It depends heavily on the problem domain. In some cases this is possible, but it's often the case that you will not know what resources you will need at the beginning of execution.

Also the implementation of "initialize everything at once" in an RIAA paradigm is not necessarily going to be the most efficient possible implementation. For instance, I might want to do something like this (in a made-up language):

    struct A { ... }

    func init() {
        let a1 = new A();
        let a2 = new A();
        let a3 = new A();
    }

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. But it's likely that instead the compiler will allocate a1, initialize a1 and so on with a2 and a3. Since the allocations are separate, maybe another thread takes precedence between the allocation of a2 and a3 and allocates some memory, so these values are not contiguous in memory, and I get worse caching performance when accessing them.

In this toy example with 3 values it doesn't make aa lot of difference, but if you add up all these marginal costs in a large application it absolutely does cost a lot of performance.

nixpulvis• 7 years ago

As I said once, pure functional programming is an ingenious trick to show you can code without mutation, but Rust is an even cleverer trick to show you can just have mutation.

Yea, I like this.

Aardappel• 7 years ago

See, everyone has a different thing they find important about Rust. He suggest abandoning zero cost abstractions (letting stack/inline allocation be decided by the compiler instead) which I think would remove most of the power of the language. Default thread safe primitives sounds really wasteful too.

I think languages similar to Rust but with less complexity will be a very cool space to watch going forward. All sorts of interesting language designs possible.

I’m working on a language that does “Rust-like” things, but unlike the article, what I am going for is the efficient memory management, in this case the inline structs (zero cost abstraction) and compile time memory management (automatic lifetime analysis). The biggest difference with Rust is that it is fully automatic: when ownership can’t be determined at compile time, by defaults it falls back to a reference count increase at runtime (in Rust this would just be an error). The advantage is zero annotations, and a language that can be used mostly by people that don’t even understand ownership. There may be ways to explicitly (optionally) enforce ownership in the future, for those who want more control.

Language: http://strlen.com/lobster/ Details on memory management: http://aardappel.github.io/lobster/memory_management.html

Notes on a Smaller Rust

Related Stories