My experience rewriting Enjarify in Rust

https://medium.com/@robertgrosse/my-experience-rewriting-enjarify-in-rust-723089b406ad#.wdxskueoh

by buster • 10 years ago

230 121 10 years ago

If you want to be able to refer to the contents of the enum, have named fields, or call methods, you need to create a separate struct definition.

Not so! An enum variant may contain named fields. From The Book, https://doc.rust-lang.org/book/enums.html :

    enum Message {
        Quit,
        ChangeColor(i32, i32, i32),
        Move { x: i32, y: i32 },
        Write(String),
    }

the_duke2• 10 years ago

I agree with him though that enum variants not being distinct types is a hassle.

I think there's an RFC for making this possible.

lmm• 10 years ago

It's by design AIUI; certainly it's often what you want (I won't claim "always", but probably more often than actually wanting the distinct subtypes).

saosebastiao• 10 years ago

This is one of my last remaining nitpicks with Rust as a language. In Scala, sum types are a form of sub-type polymorphism, where each variant is its own distinct type and can be used as such. To get similar behavior in Rust, you end up having to wrap structs in the variant like this:

    struct Foo_
    enum Bar { Foo(Foo_) }

It works, but it is extremely annoying.

the_duke2• 10 years ago

Good write up.

I can agree with him on a couple of points.

I've found Rust code to become terribly verbose and unreadable for certain tasks. You have to be careful to not end up with messy and hard to read code. Lifetimes of course make it even worse. Some common patterns are hard / awkward to implement. The stdlib is (intentionally) very small, and throwing together various crates adds a considerable maintenance overhead. Overall I find Rust really promising though. It might need a few more years to mature.

I totally agree on Go: I intially really loved it and used it all the time. The more code, and especially the more reusable libraries I wrote, I started hating it more and more, to the point where I only touch Go if I have to, or for small, one-off, self contained projects that need a bit more perf than Python or where Haskell is not appropriate (team, problem space).

The only thing that's a plus for go is it's dead-easy concurrency.

cm34• 10 years ago

The only thing that's a plus for go is it's dead-easy concurrency.

Since you mention Haskell, I would like to say that Haskell's concurrency support is more diverse and at least as easy as Go's.

masklinn7• 10 years ago

I would like to say that Haskell's concurrency support is more diverse and at least as easy as Go's.

More diverse is easy, Go is opinionated about its concurrency.

"At least as easy" is a flaming lie. The diversity alone makes it impossible but beyond that:

* when you look for concurrent go you're introduced to 3 constructs (`go`, channels and `select`) and you're off to the race having barely learned the language

* when you look for concurrent haskell you're directed towards the corresponding paper, "tackling the awkward squad" and a world of Async, MVar, ThreadId, STM and various types of Chan, and at that point you still can't write a line of concurrent haskell

Like the_duke I don't enjoy Go, but with respect to dead-easy concurrency the only language that's in the same ballpark is Erlang (and it's similarly boiled down to a complete lack of diversity — though a different model than Go's — and three basic constructs: `spawn`, `receive` and `!`).

sethammons• 10 years ago

I've not looked at Rust, but I've been using Go in production now for years at this point with non-trivial code bases. In our cases, they are mostly SMTP and HTTP servers. Sometimes the boiler plate gets in the way (and I think Go should almost never be used for simple CRUD stuff, there are better options), but I find the readability fantastic. It really dawned on my how readable it can be when I had to fix a missed condition in clean up on shutdown. It was fixed in an hour. For the perl version that the Go one replaced, it would have been a day before I even understood what would have needed fixing.

stormcrowsx• 10 years ago

Really not a property of Go. Any codebase can be hard to follow if the designer wants it to be. It just happened that the Perl community went off the deep end and decided that tiny unreadable code was better than big readable code.

ngrilly• 10 years ago

I think Go should almost never be used for simple CRUD stuff

Why?

there are better options

Which ones?

steveklabnik6• 10 years ago

I'm always glad to get feedback, we're specifically going to focus on ergonomics and smoothing rough edges this year, so this kind of thing is invaluable.

There's some good discussion on the Rust subreddit: https://www.reddit.com/r/rust/comments/53ft4m/my_experience_...

cm34• 10 years ago

Off-topic, but since you're here, let me ask: where can I track the progress on rustup support for musl-based distros where musl is the host (void linux, alpine linux) and FreeBSD? I got everything but Rust working nicely on void linux, and it's the only thing holding me back right now. Since Docker defaults to alpine linux, the reach of such support will be wider than one might initially think.

steveklabnik6• 10 years ago

For void: https://github.com/voidlinux/void-packages/issues/4570

And alpine: http://pkgs.alpinelinux.org/packages?name=rust*&branch=&repo...

https://github.com/rust-lang/rust/issues/31322#issuecomment-... is the latest news on the subject. It's not impossible, but we're not sure _how_ we want to make it easy. The real issue is the bootstrapping, my understanding is that cross-compiling a musl compiler from a gnu compiler does work today, which is how those packages were made.

FreeFull• 10 years ago

I tried rustup.rs on PacBSD, and everything just worked, so presumably it'll just work on FreeBSD too.

tormeh3• 10 years ago

Great that you're open to feedback! I'm looking at this snippet from the guessing game in the official Rust documentation:

    let mut guess = String::new();

    io::stdin().read_line(&mut guess)
        .expect("Failed to read line");

There are two things wrong here: 1) I have to use mutability to read from standard input. 2) I have to use a pointer. How about something like this instead:

    let guess = io::stdin().read_line()
        .expect("Failed to read line");

Make it a macro or something if necessary. Personally, I just looked at this and decided that Rust wasn't ready for use by non-low-level programmers.

dbaupp3• 10 years ago

The API used to be what you suggest, but it was changed because it forces doing a new allocation for each line. By taking a mutable string, code can reuse the backing storage of a string (or append to an existing one), which is especially useful for efficient loops.

Personally, I just looked at this and decided that Rust wasn't ready for use by non-low-level programmers.

That's definitely a valid sentiment, but I think a better framing would be "isn't ready for use in non-low-level contexts": Rust is (and aims to become even better) an enabling technology that allows higher level programmers to more easily write performance sensitive code, because the aggressive compiler checks help people sidestep days/weeks of subtle pointer pain. Of course, the language focuses on this low-level/performance-sensitive space, and other languages may make more sense if those benefits aren't important for your particular use case.

Fede_V• 10 years ago

This was exceptionally well written, and it closely mirrors my experience as a python programmer slowly moving into Rust.

Rust is awesome, but there are a few rough corners where you end up having to write really un-ergonomic code.

blub• 10 years ago

After reading this article my conclusion is that Rust is some kind of static-typed Perl with a focus on memory safety.

The syntax is horrid.

steveklabnik asked me once why I thought Rust is more complex than C++. Well, if one takes a look at any of the Rust snippets in this article without being deeply disturbed by the @'s the .'s, &'s and *'s, then we have a completely different idea about what it means to build a user-friendly and ergonomic programming language.

Luckily I don't have to pick between Rust and Go, but if I had to I would just stick to Python and use type annotations after reading this.

steveklabnik6• 10 years ago

In a systems language, it's important to know if you're passing around things by value or reference. We follow the Python maxim here: explicit is better than implicit. This means &s to indicate where something is passed by a pointer, and * for dereferencing. This is the same as C++, we just do less magic coercions. We also tried to not make up too much syntax, and stick to "curly braces and semicolons" for most things. Even lifetime syntax isn't new, though OCaml uses it for a very different purpose than we do. (There also aren't any @s in there, unless I missed something? And . is the same as in any language: for method calls, and we made it _simpler_ than C or C++ here, by having . instead of . and ->.)

I agree that you can make a language without many syntactical constructs, but Rust has other goals as well. Language design is hard! There's tons of tension between various choices.

jpfed• 10 years ago

If you're deeply disturbed by all the @s then you formed your opinion more than a year ago.

p0nce• 10 years ago

Besides, when nearly every call requires a cast, people will just automatically add them to shut the compiler up, defeating the purpose.

That's why there is little reason to "fix" C integer promotion rules in the first place (apart from unsigned).

mmargerum• 10 years ago

Really interesting write up. I'd love for you to port to swift and gives us your thoughts! :)

FraaJad• 10 years ago

I wish someone would do this in nim and compare the results.

My wishful thinking is that nim would come in at the same number of lines as Python and very close to Rust's performance.

agentgt2• 10 years ago

I was thinking the same thing with OCaml. I wrote in OCaml years ago and I still remember how incredibly terse the language is/was. You can accomplish so much with very few lines of code (with the minor exception of the whole reduplicate signatures and way too many artifacts (mli, cmi, ml, etc)). It also compiles much faster than Rust (I'm not sure about Go but since Go doesn't have that sophisticated type system it isn't really fair).

I have to say Rust got fairly hard to read and think about writing code with lifetimes when using closures. I couldn't decide at times whether to just use a trait with some cells or get the closure stuff working. This was in part because of some bugs (about 1.5 years ago) and the fact that their are 4 types function things. It is also probably because I haven't programmed in anything analogous that has lifetimes (I haven't programmed in C++ in more than 1.5 decades).

spion• 10 years ago

There is the Python -> OCaml story for 0install:

http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...

This article in particular tackles polymorphic variants http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain... which solve one of the issues that the author had with Rust (enum subsets)

zem• 10 years ago

that was my first thought too. ocaml would have addressed all the complaints he had with rust:

  * far more concise  
  * familiar exception handling mechanism  
  * classes and inheritance for the few places he needed them  
  * mutability  
  * bytestrings

missing are

  * proper support for enum subset types (i've felt the need for those too)  
  * exhaustiveness checking for uint8  
  * bit length (seems like a very niche thing; i'm sure someone's implemented it in a library somewhere)

rust makes a compelling competitor to d as an upgrade path from c++, but if you're porting code from a high-level, dynamic language like python, ocaml is almost always going to be a better experience.

catnaroek9• 10 years ago

You can convert an `Option` into a `Result` and then use the `try!` macro, all in a single line: http://stackoverflow.com/a/37890739/46571

glandium2• 10 years ago

But Iterator's next() returns an Option, not a Result.

catnaroek9• 10 years ago

I don't see why you'd want to manipulate iterators by hand, unless you're implementing custom iterators. But, in any case:

    try!(iter.next().ok_or("end of sequence"))

EDIT: Sorry. I was just being dense.

Thaxll3• 10 years ago

Rust syntax is horrible compare to Python / Go, I don't see how you could give an advice to someone that do Python to use Rust, you lose GC and add a great layer of complexity / learning curve. No thanks. Seriously when I see that:

struct IRBlock<'b, 'a: 'b> { pool: &'b mut (ConstantPool<'a> + 'a), // other fields omitted }

hokkos• 10 years ago

GC is not a feature in all cases, and without GC you must manually handle allocation and deallocation in some cases, C or C++ let you free of lifetime annotations at the cost of crashes, Swift force you to use counted pointers and Rust force you in a semantic that forbid errors at the cost of some lifetime allocation that you consider ugly. But it is still shorter than copy pasted Go code to simulate generics, and multiple "err, res" that stains the code.

Thaxll3• 10 years ago

My point is a lot of people use Python because it's a simple and powerful language, Rust is not a simple language at all. And the performance it brings is not enough to make the decision to switch language in most cases.

geofft• 10 years ago

C or C++ let you free of lifetime annotations at the cost of crashes

This is so very true. A lot of my time as a professional C and C++ developer is spent trying to figure out exactly how long some previous programmer intended a value to live, whether it can be safely accessed in this context without a lock, etc. The ugliness of <'b, 'a: 'b> is vastly preferable to segfaults or corruption in production and days of debugging.

Anyway, time for me to go back to staring at why this machine isn't reinstalling because wget is hitting a null pointer dereference, but I'm sure wget's code is very pretty.

davyjones• 10 years ago

Why is this getting downvoted? Please don't downvote if you disagree with this viewpoint. Rust has its reasons for is current form, which is OK! In general, the whole song and dance around GC is a hard problem.

I agree that the syntax is cryptic. I also think that programs are written by humans for human consumption (for accomplishing a certain task).

If you have a long term plan, you might want to factor in the talent pool, hardware cost, and tech debt. For your case, if that leads to Rust, so be it. Or if it means Python, that is fine too.

kbenson6• 10 years ago

Likely because it's presented as a rebuttal to the article, when the article makes no such claim. It's a non-sequitur at best, and possibly a straw-man argument.

Roboprog2• 10 years ago

It's a shame there aren't more "Modula" derived modern languages, rather than trying to force C into being a higher level language.

Java, especially at the 1.1 mark, felt like some kind of crippled version of Borland's Pascal/Delphi + a UCSD P-system VM (dressed up to look like C++).

Microsoft for C# hired the language designer from Borland.

The Go team includes a Uni of Zurich guy, and at least decided to use a declaration syntax (when variable types aren't inferred) more like Pascal.

Start with a language that wasn't a shiv with a broken handle in the first place to build applications.

It's a shame Eiffel never took off instead of the wretched C++, no, this time for sure, Java... (not, that's not it, either - lather, rinse, repeat) lineage.

(C was vastly preferable to assembly in the late 80s / early 90s, but it's time to let it go, and its syntax/semantics, people)

Irony: I like the unix philosophy of composing processes in a functional pipeline, which is totally lost in the era of monolithic java crud, but that is another huge tangent.

RANT ENDS.

Hemospectrum• 10 years ago

The Rust community is pretty good at turning specific complaints into actionable proposals. Could you perhaps be more specific about what nice things in Modula/Delphi/Eiffel are missing from other languages, or about what might be different if Go or Rust borrowed more of their influence?

Roboprog2• 10 years ago

Thanks for the response, it was just a rant.

I suspect the Rust community and I simply have irreconcilable differences. They want a better C or C++, and like special character ditties such as &, *, <_> (whatever that does), and I would rather have short keywords in some places.

For example, declaring a parameter with "var" in a function heading means it is a reference, instead of a copy. However, there is no dereferencing syntax, you simply use it as if it were a local "auto"/stack type variable (which also cannot be a null, so no checks are required - which Rust probably takes care of as well if you ask nicely), and there is nothing special for the caller to do, unless the caller has a pointer that needs to be checked and then dereferenced in the call.

I also miss reasonable "set" operations, even if the sets were just bit vectors on short enumerated types (enums or short sub-ranges of other discrete values). Maybe Rust has sane set operations, but Java's collections operations are a bit off: mutating "add-all" vs union producing a new set, and so on.

Eiffel's pre/post-condition and class invariant special assertions are nice, as well.

adelarsq• 10 years ago

Based on this would be nice to know things that still can be used within Rust :)

alexnewman2• 10 years ago

Plenty of ways to .orthat for options. The author should checkout the option type in detail

tombert• 10 years ago

I'm curious what the performance would be if it were ported to Haskell or OCaml. It almost certainly would be slower than Rust, but I think some benchmarks would definitely be interesting when comparing those languages to Go.

My experience rewriting Enjarify in Rust

Related Stories