Live data from Hacker News

Performance of Rust and Dart in Sudoku Solving

attractivechaos.wordpress.com

31–40 of 72 posts

Re: Performance of Rust and Dart in Sudoku Solving

#31
post #18
post #3

I'm really excited by Rust because it seems to be one of the most sensible language designs I've seen in a while. Go is nice but has some pretty odd syntax in places. I'm just waiting on Rust to hit 1.0 before I start playing with it more seriously.

You're complaining about Go syntax, which is one of the most readable languages out there but you like rust which looks like line noise?[1] Sometimes I have a hard time convincing myself people don't post troll comments on HN. [1] https://github.com/mozilla/rust/blob/master/src/libsyntax/pa...

Lexers are notoriously complex and difficult to read. The one in Go[1] is also really difficult to grok.

[1] - https://code.google.com/p/go/source/browse/src/pkg/go/scanne...

Re: Performance of Rust and Dart in Sudoku Solving

#32
post #18
post #3

I'm really excited by Rust because it seems to be one of the most sensible language designs I've seen in a while. Go is nice but has some pretty odd syntax in places. I'm just waiting on Rust to hit 1.0 before I start playing with it more seriously.

You're complaining about Go syntax, which is one of the most readable languages out there but you like rust which looks like line noise?[1] Sometimes I have a hard time convincing myself people don't post troll comments on HN. [1] https://github.com/mozilla/rust/blob/master/src/libsyntax/pa...

>You're complaining about Go syntax, which is one of the most readable languages out there but you like rust which looks like line noise? Sometimes I have a hard time convincing myself people don't post troll comments on HN.

And then, as an example of "bad Rust syntax" you link to the "lexer.rs"?

As if a lexer in any language is a good example of it's everyday syntax?

How about the very first example they give:

http://www.rust-lang.org/

>My first thought was that it looked like CSS o.O

Because the top part of the source he linked to has just struct definitions, which is what CSS was designed like anyway. Would struct definitions in most common languages, like modern C or Go look any different? (including an {} object definition in JS)

Re: Performance of Rust and Dart in Sudoku Solving

#33
My results with newer versions of gcc and go:

gcc 4.7.2 o3 0.765s

java openjdk 7 1.066s

java openjdk 6 1.118s

go 1.1b 1.653s

rust 0.6 opt 3 1.659s

go 1.0.2 2.127s

dart 0.4.4.4 2.384s

pypy PyPy 1.9.0 5.094s

pypy PyPy 2.0b 5.319s

(Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz)

Edit: Added java

Re: Performance of Rust and Dart in Sudoku Solving

#34
post #16
post #11

Earlier quoted context omitted.

And deterministic memory management, which is quite rare these days... :) But to be honest, skimming through Rust samples, I find its syntax somewhat noisy. It feels ad-hoc. Is there any document about justification of its syntax elements?

> And deterministic memory management, which is quite rare these days... :) Memory management should be automatic, either by reference counting or GC. I think it is a generation thing until mainstream OS adopt such kind of system programming languages. There are a few OS with such system programming languages, but it only counts when the likes of Apple, Microsoft and Google adopt such languages. Objective-C with ARC,…

Rust's memory management is both (relatively) deterministic and automatic, in that it's easy to figure out exactly when objects are being destroyed if you care but you don't have to do anything yourself to ensure that they're destroyed properly. This is in contrast to C or C++ where you have deterministic destruction but you have to clean up things you have to clean up things on the heap yourself, or Go or Java where you can't be sure at all when the garbage collector is going to harvest something.

Re: Performance of Rust and Dart in Sudoku Solving

#35
post #16
post #11

Earlier quoted context omitted.

And deterministic memory management, which is quite rare these days... :) But to be honest, skimming through Rust samples, I find its syntax somewhat noisy. It feels ad-hoc. Is there any document about justification of its syntax elements?

> And deterministic memory management, which is quite rare these days... :) Memory management should be automatic, either by reference counting or GC. I think it is a generation thing until mainstream OS adopt such kind of system programming languages. There are a few OS with such system programming languages, but it only counts when the likes of Apple, Microsoft and Google adopt such languages. Objective-C with ARC,…

>There are a few OS with such system programming languages, but it only counts when the likes of Apple, Microsoft and Google adopt such languages.

There are a few OSs written with everything. It only counts when pragmatic, useful OSs are written with a language. Most of those OSs are unusable, slow, proof of concepts.

Re: Performance of Rust and Dart in Sudoku Solving

#36

Man, PyPy got destroyed, let alone CPython! As a Python lover, that's pretty disheartening. I'm not an expert in many of these languages, but it would seem as though it should be possible to build a Python interpreter as fast as V8, even without using Numpy to accelerate the math. Anybody have any thoughts as to why PyPy is such a poor performer here?

That's actually an impressively good result. All that wonderful expressive power that Python has comes at a price in implementation complexity, and there are a lot of different cases that the JIT needs to handle with Python. Lua, by contrast, is pretty much Scheme in ALGOL's clothing and is ridiculously simple inside.

Re: Performance of Rust and Dart in Sudoku Solving

#37
post #33

My results with newer versions of gcc and go: gcc 4.7.2 o3 0.765s java openjdk 7 1.066s java openjdk 6 1.118s go 1.1b 1.653s rust 0.6 opt 3 1.659s go 1.0.2 2.127s dart 0.4.4.4 2.384s pypy PyPy 1.9.0 5.094s pypy PyPy 2.0b 5.319s (Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz) Edit: Added java

It looks like Go 1.1 might be faster than Java. That might help convince enterprise developers to adopt it.

Re: Performance of Rust and Dart in Sudoku Solving

#38
post #35
post #16

Earlier quoted context omitted.

> And deterministic memory management, which is quite rare these days... :) Memory management should be automatic, either by reference counting or GC. I think it is a generation thing until mainstream OS adopt such kind of system programming languages. There are a few OS with such system programming languages, but it only counts when the likes of Apple, Microsoft and Google adopt such languages. Objective-C with ARC,…

> There are a few OS with such system programming languages, but it only counts when the likes of Apple, Microsoft and Google adopt such languages. There are a few OSs written with everything. It only counts when pragmatic, useful OSs are written with a language. Most of those OSs are unusable, slow, proof of concepts.

Native Oberon and AOS were used for real work as desktop workstations at Zurich's Technical University.

Sadly no one in the industry decided to invest on them.

Re: Performance of Rust and Dart in Sudoku Solving

#39
post #3

I'm really excited by Rust because it seems to be one of the most sensible language designs I've seen in a while. Go is nice but has some pretty odd syntax in places. I'm just waiting on Rust to hit 1.0 before I start playing with it more seriously.

Eh, the only real surprise in Go's syntax is the odd ordering of type and variable names. That is, I think, a welcome change for those of us who sometimes have a hard time remembering if *a[] is an array of pointers or a pointer to an array. There wasn't anything I couldn't puzzle out without looking it up on the basic syntax side of things.

Rust, by contrast, introduces more new syntax for things like it's various sorts of pointers. And there are other things that look new to me too, thought that might be due to me not knowing ML. They're there for a good reason, but they add to the learning curve.

Re: Performance of Rust and Dart in Sudoku Solving

#40
post #26
post #17

Earlier quoted context omitted.

I think LuaJIT is the outlier, not python. All other implementations got lots of resources to make them fast, except for LuaJIT.

PyPy simply isn't at the same level as V8 and LuaJIT yet. V8 is a professional, full-time project employing some of the best programmers money can buy. And LuaJIT.. well LuaJIT is written by a fucking genius 10x programmer. Let me quote him: " The reason why X is slow, is because X's implementation is slow, unoptimized or untuned. Language design just influences how hard it is to make up for it. There are no excuses.…

Indeed, that's what I meant, even though my phrasing was unclear. Thanks for clarifying.
Post reply on HN