Live data from Hacker News

A Fresh Look at Rust

lucumr.pocoo.org

11–20 of 157 posts

Re: A Fresh Look at Rust

#11
post #6

I have a huge hatred towards both the STL and boost and that has existed even before I worked in the games industry. I really don't understand why STL gets so little love. It's a little lean on features maybe but in my experience it just works, and it's fast . Once you get your head around the iterator concept it's pretty simple to use. And with lambdas in C++ I can write code that's almost as concise as Ruby or Scal…

In my experience the people who have strongly negative opinions specifically about the STL have it rooted in one of these two things: - They haven't used it much in a very long time and have very bad memories of tracing through the completely opaque SGI STL implementation and its derivatives. - They include std::string and/or std::iostreams as part of the STL, neither of which are part of the original STL and have al…

Probably true. I wasn't much of a fan either when I first used it in 1996. It was extremely verbose, slow to compile, and tended to generate compilation error messages that filled the screen.

But the experience of using the STL today with the niceties of C++11 and a good compiler like Clang is vastly better. I can now write code almost as concise as Ruby that runs 100x faster, without usually having to worry about memory management. I avoid using the streams stuff though. That chunk of the library could use a serious overhaul.

I'm rooting for Rust because it's designed to address the problem spaces I care about most but C++ has improved by leaps and bounds in the last few years.

Re: A Fresh Look at Rust

#12
post #4

I've been using Rust to process a large text corpus, and as Armin suggests, it's a really interesting experience. Here are a few things I've noticed so far: 1. Writing Rust code definitely takes more time than Python or Ruby, but it's not bad in practice. I can't measure the productivity difference yet, partly because I'm still learning Rust. I do spend more time thinking about how to write zero-allocation and zero-c…

> Rust is one of those languages where I need to work to make the compiler happy, but once I manage that, the code generally works on the first try.

I can confirm this. I have a CSV parser[1] that is maybe twice as fast as Python's CSV parser (which is written in C)+. There's nothing magical going on: with Rust, I can expose a safe iterator over fields in a record without allocating.

[1] - https://github.com/BurntSushi/rust-csv

The docs explain the different access patterns (start with convenience and move toward performance): http://burntsushi.net/rustdoc/csv/#iteratoring-over-records

+ - Still working on gathering evidence...

Re: A Fresh Look at Rust

#13
post #5

Earlier quoted context omitted.

This is great feedback, thanks. And if there's anything that you don't like about Rust, please let us know now while we still have a chance to possibly fix it! Only a few short months left until all of our mistakes are forever entombed in Rust 1.0. :)

Two things that come to my mind: 1) General concurrency/parallelism ease of use. It would be nice to have Async/Await a la C#, as well as some easier to use channels and synchronization primitives/functions along the lines of Go or Core.Async. And 2) use of for type annotations instead of [], which is much easier to parse when nested.

Servo is definitely demanding a wide variety of approaches to both concurrency and parallelism, so I expect the facilities for such in Rust to mature very quickly (but faster with more help and feedback!). It's a very important issue that is seeing work from full-time developers as we speak.

As for the second point, we've gone beyond the bikeshed ( and [] are both exactly as ambiguous to the grammar, so it's just an argument of preference by this point) and addressed the root issue with `where` clauses, which prevent you from needing to nest at all for a majority (or perhaps plurality, I haven't measured) of function signatures where you previously needed to.

Re: A Fresh Look at Rust

#14

Earlier quoted context omitted.

In my experience the people who have strongly negative opinions specifically about the STL have it rooted in one of these two things: - They haven't used it much in a very long time and have very bad memories of tracing through the completely opaque SGI STL implementation and its derivatives. - They include std::string and/or std::iostreams as part of the STL, neither of which are part of the original STL and have al…

Probably true. I wasn't much of a fan either when I first used it in 1996. It was extremely verbose, slow to compile, and tended to generate compilation error messages that filled the screen. But the experience of using the STL today with the niceties of C++11 and a good compiler like Clang is vastly better. I can now write code almost as concise as Ruby that runs 100x faster, without usually having to worry about me…

Yeah, Clang has really improved the ecosystem as a whole, as has this decade's updates to the language and libraries. But unfortunately they are all band-aids over some very deep foundational problems that were decided decades ago (I don't blame Bjarne by the way - he didn't have the benefit of hindsight).

I am glad we have a new language that takes the best from C++ and sets in on reasonably solid theoretical foundation inspired by languages like ML and Haskell. It's not watertight yet (unlike the formally verified ML), but it is damn better than the current status quo.

Re: A Fresh Look at Rust

#15
post #8

I rarely have to do anything as low-level as rust would demand. More often than not I find myself using Python, but I had the same feelings when I started looking into rust a few weeks ago. It was exciting seeing the full pattern-matching, especially. I have a desire to get some experience in the area, but the problem is what to make. Does anyone have any ideas for some smallish libraries that would benefit the commu…

What kind of areas are you interested/experienced in? What would you like to learn? I'm sure there are tons of gaps out there that you could help fill. Maybe the folks on irc.mozilla.org #rust might be able to give you some ideas.

Re: A Fresh Look at Rust

#18
post #15
post #8

I rarely have to do anything as low-level as rust would demand. More often than not I find myself using Python, but I had the same feelings when I started looking into rust a few weeks ago. It was exciting seeing the full pattern-matching, especially. I have a desire to get some experience in the area, but the problem is what to make. Does anyone have any ideas for some smallish libraries that would benefit the commu…

What kind of areas are you interested/experienced in? What would you like to learn? I'm sure there are tons of gaps out there that you could help fill. Maybe the folks on irc.mozilla.org #rust might be able to give you some ideas.

Thanks. I'll definitely try out irc for some ideas. My general projects are small automation tasks for myself as well as small web-based apps for myself and friends. That's part of why coming up with ideas for something like rust are a little tricky.

The only promising thought I've had is maybe implementing some sort of template preprocessor that I can find a way to work into an existing rust framework.

Re: A Fresh Look at Rust

#19

In addition to being a great lang, I love all the little things. Like he mentions, the doc tools and compiler are very nice.

> the [...] compiler [is] very nice.

No doubt clang has been a good influence in setting the standard for gorgeous, readable error messages with nice colored squigglies and arrows. Borrow check errors probably the hairiest you get, and you get less and less of those as you internalise the rules.

Re: A Fresh Look at Rust

#20

This is a good write-up. I still think some kind of vanilla ML would suit a lot of people very well.

What do you mean by 'vanilla ML'? I wasn't sure there were any really around... Ocaml has tons of stuff added, and SML also has lots of added extensions.
Post reply on HN