Hacker News Reader

> However, the non volatile, non unsafe parts of the code were an absolute joy. Testing was a joy, compiling was a joy, and benchmarking was a joy. I was impressed that it allowed me to bypass the type system completely and do nasty, nasty things in the pursuit of performance. I want a language that lets me do nasty things where I must, but that makes the other 95% of the program, and the job of compiling, testing, and maintaining that program easy. Go excels here. Rust, C++, Haskell, Scala will never be good at that

FWIW, I actually think that Rust positively excels at this sort of isolated low-level work due to explicit `unsafe` blocks. Furthermore, the type system is more expressive meaning the need for this is rarer[1].

In my experience, the rest of the language (i.e. non-`unsafe` things) works very well for maintenance and testing, also in part due to the more expressive typesystem, and things like algebraic data types with exhaustive matches by default (I've done some huge bug-free refactorings to the standard library and compiler, mostly due to the compiler automatically catching all the places that need updating).

On the other hand this comes with the cost of making the "job of compiling" more difficult: the compiler complains about more things.

Re testing: there's unit testing and microbenchmarking built-in: http://doc.rust-lang.org/master/guide-testing.html

[1]: in this case, the type system positively designed with making this sort of concurrency safer.

Rust has `unsafe` blocks in which you're allowed to do all nasty hacks you want.

Rust actually isn't that complicated. Don't get discouraged by comparisons to Haskell — it's still a C-family language where you can play with pointers and mutable state.

To me Rust still feels like a "small" language (similar size as Go or ObjC, not even scratching complexity of C++). It's mostly just functions + structs + enums, but they're more flexible and can be combined to be more powerful than in C.

I think comparisons to Haskell are not too far off the mark. Haskell is not that complicated of a language either. You can do all sorts of complicated things with it, but the language itself is relatively simple. It just has a lot of stuff that you're likely to have never seen before (extensive use of higher-order functions, higher-kinded types, etc), and its type system produces error messages that seem obscure from the outside. Similarly Rust can have some rather obscure error messages that you're probably not going to have seen before during compilation - lifetime specifiers, errors about using things in the wrong contexts, heck, even "Bare str is not a type (what?)"

I'm much more familiar with Haskell than Rust, but having played around with Rust I think they're on a par with each other in terms of difficulty, depending on your background.

I love Rust from a theoretical standpoint, it's more beautiful than Go. But Go is more practical, when it comes to getting things done with a team, it just makes more sense (maybe not for every case!)

> Rust, C++, Haskell, Scala will never be good at that because they're too damn complicated (although each of them make the nasty parts a little less painful!)

Why is Rust too complicated to allow you to do low-level hacking?

I mean too complicated for writing, reading, and maintaining and generally just working with from day to day. It costs too much time to do the same thing.

Again, what specifically?

I ask because this has not been my experience writing several hundreds of thousands of lines of Rust code, nor has this been the experience of anyone I have helped get up to speed. Moreover, I believe there is no feature in Rust that is not necessary to achieve safety without sacrificing performance.

Hundreds of thousands of lines of Rust? Out of curiosity, what kind of software are you writing in Rust?

...

And can I get in on some of that? ;-)

> Hundreds of thousands of lines of Rust

Just a very concurrent browser engine ;) One that does everything in parallel. Basically every task that can be parallelized becomes parallel (rendering, JS execution, CSS matcher, etc.).

Also you can, there is Github for Servo (said parallel browser engine project by Mozilla).

https://github.com/mozilla/servo/wiki/Design

The compiler and Mozilla's experimental rending engine Servo:

- https://github.com/rust-lang/rust/

- https://github.com/mozilla/servo/

(The 'contributors' graphs suggest that pcwalton has added/removed more than 1 million lines of code in those two repos combined.)

The Rust compiler :) He is part of the Rust team and writes Servo.

Can you be any more vague?

I don't think it's bad, but to me(and only to me), disappointing. I'm a long time mozilla fan...heck a Netscape fan really. Go was a pleasure to learn, there were no 'gotchas' initially...just a small, easy to reason about language. Rust...with its arrows, angle brackets, pattern matching, etc. seemed just so complex to fit in my brain. I'd love to be proven wrong and try again, but the docs aren't the best. And I know Rust isn't 'released' yet. But if you are defending it, I feel like it should be at a very learnable state. Do you have plans for a 'tour', for a play by play like Go offers that can bring others up to speed? Further(and this is really reaching while I got you)... my favorite part is cross compilation and being able to deploy a single binary anywhere. I tried to compile something in rustc once, but when I moved it to an older box, it failed to run. Will rust offer such stable static compilation in the future?

>Rust...with its arrows, angle brackets, pattern matching, etc. seemed just so complex to fit in my brain.

It's 2014 already. Angle brackets, arrows, and pattern matching are 1990 level language technology.

Heck, even a dynamic front-end language like Coffescript has these kind of things nowadays.

I'm not saying you're wrong nor will I argue about it as in the end it really comes down to taste I feel. To me, and perhaps to others, these things make a language harder to read/use, regardless of how pervasive...

While some of it can come to taste, I think having higher abstractions (as long as they don't leak) is beneficial to reading/using a language. Like, objectively.

And foreach vs for is not a leaky abstraction. Nor is pattern matching vs traditional checking and extracting the values. So their value is not geting lost on having corner cases that the equivalent "based on primitives" code wouldn't have. If anything they make the operation even more explicit.

So I think a lot of it comes down to getting familiar with them.

While something made of "first principles" might be more instantly familiar, it will be harder to reason about because of its low-level ness as the code size increases.

Case in point, assembly. It's quite primitive language with very few constructs, so it's easy to learn to use. But an actual high level "if" or function call is much easier to grasp at once than checking 10-20 lines that implement the same thing in assembly (even if you have trained yourself to see the assembly "pattern" for a function call, etc).

To expand on this: isn't what Go does with built-in channel and parallelism primitives similar to that?

They sure didn't exist in C. But people see the value of having this higher level abstractions.

So, why draw the line on Channels and Goroutines, and not add pattern matching in there? Just because Go already came out offering the former?

If anything, pattern matching is even more applicable to the work we do day-to-day, than channels and goroutines are.

Millions of people write programs without parallelism/concurrency every day, but nobody writes programs without pattern matching. They just do it by hand with lots of if/else and various manual extraction techniques, if their language doesn't offer it.

> the docs aren't the best.

This week is week two of my being contracted by Mozilla to write docs full time. First up, a new tutorial. You can see my work from last week http://doc.rust-lang.org/guide.html , and my first task after I finish breakfast is to clean up https://github.com/rust-lang/rust/pull/15229 , which got some review over the weekend.

So, you're right (at least about the docs) but I'm on it.

Steve - thanks for your reply and work on the docs. Is there currently a place - or will there be one, that describes precisely build/deployment options? This really in the end is the most important thing to me. I've searched unsuccessfully for this wrt Rust. It seems that as it sits, items built on a newer machine won't run on an older machine due to libc library mismatches. Will this always be a potential issue? Or will I be able to generate a single binary a la go?

Well, first of all, I'd point to you http://arewewebyet.com/ ;)

Different linking options are found here: http://static.rust-lang.org/doc/master/rust.html#linkage

Basically, as of right now, when you link statically, Rust will not build in glibc (and jemalloc, IIRC). So, you'll need to make sure that your glibc versions line up. My understanding is that glibc isn't able to be statically linked in without breaking things.

You can use `objdump -T` to see these dependencies. On my system, compiling 'Hello world,' I get symbols for glibc and gcc.

(Go gets away with this by reimplementing the world, rather than relying on glibc. The benefit is a wholly-contained binary, as you've seen. The downside is compatibility bugs, like https://code.google.com/p/go/issues/detail?id=1435)

it allows any number of reader threads concurrent access without any synchronization or blocking, unlike Go maps.

You mean readers concurrent with a writer? AFAIK, any number of reader threads can get values out of a Go map when it isn't being written to.

Yes, concurrent with a writer. If there is more than one writer, the writers must use a mutex, but the single writer and readers don't block each other. I updated the text to make it clear.

That map only works with keys and values both being int32, right?

Correct. I have to duplicate much of the code for in64 keys and values, the lack of generics hurts there.

You seem to be brushing this off as a minor nuisance, when in many cases it is a showstopper.

Need it for floats, duplicate it again.

This is a solved problem -- the fact Go doesn't have the solution reflects very poorly on Go.

There are some batshit crazy "solutions" offered from Go fans, like "no biggie, just use a templating engine to generate the code for the types you want and compile it".

I actually use that solution in c (we have some reasons to avoid c++).

Of course it sucks, but at least c has the excuse of being from the 70's.

They suffer from a strange distortion field effect.

Ironically that is the solution c++ essentially uses.

Not quite, given that C++ templates do higher-level type-checking than just expanding and checking.

Also, they support higher-order kinds (a template parameterized by a template). And specialization (specifying special cases). And automatic instantiation based on the static types at the call site. Etc.

Its not like you will be creating a collections library all the time you create some program... yes generics are cool for code reuse.. but i think some people just overreact, turning it into something that will make the language unusable or that you will have to copy-and-paste just because of the lack of generics.. this is far from truth..