Hacker News Reader

I've gone all-in for Rust for any side projects. I still get paid to write C++, but I choose to use Rust. I'd say that I'm up to around 20K LOC at this point and the sheer peace of mind that I get is worth almost any amount of extra arguing with the compiler when it just works the first time I run it -- which happens a surprising proportion of the time.

Improvements which would make me really happy:

* Faster builds. This is still a pain point.

* "Non-lexical borrows" [1]

* Trapped under ICE [2]

I know that all of the above are being actively worked on, so I'm waiting patiently. [3]

[1] Borrows are currently tied to scopes (blocks, etc). This makes certain safe borrowing patterns illegal, requiring slightly-to-highly awkward workarounds.

[2] The compiler crashes too often (ICE). I was recently stuck with a non-compiling code base and facing the prospect of systematically commenting out code to find the offending piece. Fortunately, this one was fixed quickly. There are many others remaining, though. (It is getting better as Rust gets more use.)

[3] This is a lie. Patience is rarely one of my virtues.

> Faster builds.

This is a pain point for us, too, on Servo. There's fantastic active work going on for incremental builds, which will solve our most pressing needs (long turn-around on debug changes).

Also, if you're on linux, make sure you're using gold instead of system ld. That change made a huge difference for Servo.

The ICE issue is what turned me off Rust.

I went all-in for side projects like you (this is how I typically learn a language), but after two months or so, I was spending 30-60 minutes a day trying to figure out the cause of compiler crashes, and then tweak my code so it didn't trigger them.

I've heard the ICEs have gotten much better in 1.2 (I was working in 1.0), but I haven't picked it up again.

To you or anyone else who reads this, if you find an ICE, please report it or :+1: a previous report. It can be hard to tell which ones hit a lot of people, and which ones don't.

Would it be possible to add an optional crashpad-like script, one that allows you to review the data sibmitted in hex/ascii before sending it off?

We've been discussing it, not just for crashes, but even compiler errors. But it's all in the 'wild dreaming' kind of phase, there's privacy concerns, and you'd want such a thing to be VERY opt-in. But it's a cool idea.

1.2 is so much better with ICE-s than 1.0.

[1] should get fixed post-MIR (the new "middle IR" that's in progress right now)

[2] --- let's hope this improves :)

Abandoning ~90k LOC certainly seems like a bad idea, but since Rust can basically pretend to be C, you could just peel off a certain part of your app, and have a hybrid codebase. Your C++ would just link to the Rust like any other C library. This is the approach Firefox is taking.

Firefox' C parts are getting incrementally rewritten in Rust?

Slowly. There's two patches right now: using Rust for URL parsing, and an MP4 parser. They're not being built by default, but you can set an option at compile time to use them. There's some more work to be done before they'll start appearing in regular builds.

See here for more:

  * https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code
  * https://bugzilla.mozilla.org/show_bug.cgi?id=1175322
  * https://bugzilla.mozilla.org/show_bug.cgi?id=1151899

(and Firefox is mostly C++, not C)

Addendum: The URL parser is a replacement (it's the same parser we use in Servo), but the MP4 thingy adds new functionality.

Yeah, this is very appealing, ideally migrating new features/submodules rather than rewrite.

"after having gotten burned (in Haskell) by the "more purity or strictness (in the conventional, not evaluation, sense) is always better" argument ... I'm waiting to be convinced that having a more picky compiler actually helps rather than getting in the way"

@seertaak, can you quickly explain how the strictness became a problem?

Could you describe in more details how you got burned? (I have never done anything big in haskell)

It was a while ago, and I tried using it at work -- for simple tasks, tasks that would have taken tens of minutes using either Java or Python. With Haskell it would invariably take much, much longer. It would look really beautiful at the end, but the truth is the extra amount it took couldn't be justified.

Specific problems were extending a program to do "just one more thing", as is commonly the case for more "scripty" tasks. This often caused severe refactoring, as what was suddenly a simple function or IO/ST monad now had to include another monad and it all would become a bit of a mess. In general I find combining monads in Haskell pretty unpleasant, especially when you consider that this kind of stuff is so trivial in other languages that you don't even think about it. To put it shortly, I would spend too many brain cycles wrestling with Monads and strictness and Haskelly concepts, and too little on my actual problem.

But hey, that was some time ago and YMMV.

> It was a while ago, and I tried using it at work -- for simple tasks, tasks that would have taken tens of minutes using either Java or Python. With Haskell it would invariably take much, much longer. It would look really beautiful at the end, but the truth is the extra amount it took couldn't be justified.

The productivity curve for Haskell is exactly the opposite of something like Python. You spend a lot of time at the beginning writing all your fancy types, monads, etc. Then later when you have thousands of lines of code you can make non-trivial changes with the ease with which you could write a tiny one-off Python script.

I also think it's important to tell people that there is a learning curve on that, too, even after the learning curve of learning Haskell. It takes some time to figure out how to write the idiomatiac Haskell code that factors correctly to make those changes.

It's a fantastic exercise to get to that point in Haskell, and the skills carry over in surprising ways to conventional languages too, so I unequivocally recommend it to anyone with at least, oh, say, 4 years of experience in "conventional" programming, to get you to the next level of programming skill. But make no mistake, it is quite the learning curve. I think this is a positive thing, though... the reason why it is such a learning curve is precisely that you are learning, in exactly the way you really aren't learning anything when you pick up your fifth object-oriented imperative language.

Do you have any references on that ? books, papers or even blog posts.

Start with Learn You a Haskell, IMHO. Best starting explanation of that sort of stuff.

Then you actually have to use it for a while.