Go is strongly typed, and so is it's templating language. This means that you need to take a much more rigorous approach to using them, as a single unhandled edge case value can break the entire page. Contrast this with something like Jinja2 where if you mess up it'll only break a small bit of the page.
I managed to produce a usable template system, but it's still a tad more verbose than I'd like. It'd have been nice if a more scripting-language style templating language had been an option.
Do you have some examples of error that are easy to make with Jinja2? I personally find it to be a thing of beauty, but it's possible that I don't try to make very elaborate things with templating engines and thus might be missing out.
Ability to convert between language types and raw addresses, in the form of pointers.
Toolchain should also provide the ability for aot compilation both to static and dynamic executables/libraries.
In this context, Rust's semantics do allow C-level performance- they make it straightforward to describe the same machine code that C would. In some cases, they even enable more compiler optimizations than C does.
Java, on the other hand, makes it hard or impossible to do that (straightforwardly at least). A more mature compiler will make a lot of difference- compare early Java performance to where it is now, for example.
Please share your measurements of "real-world performance" that are "not very correlated" with the benchmarks game's results.
edit: Please provide a better response than downmods.
edit: Please provide a better response than downmods.
Just a URL to published comparison measurements would be so much more interesting for anyone interested in Rust, than downmods.
(There seem to have been plenty of breaking language changes in the last 6 months.)
(The "faster" bit isn't important; various reasons might have made C++ slower than Rust for this, but what is important is that perf was comparable)
What I questioned was Rusky's technical-sounding but apparently unsupported claim that "the benchmarks game's results are not very correlated with real-world performance." For Rusky to know he'd need some kind-of "real-world performance" measurements and a correlation coefficient - neither of which have been shown.
I'm working on improving the regex engine now. Hopefully I can submit some improvements soon. :-) It will be hard to get near the top, but I think there's some low hanging fruit I can tackle first.
A couple of weeks ago you said -- "… optimizing performance hasn't been a focus, shipping good language semantics has been."
https://news.ycombinator.com/item?id=9565405
edit: Please provide a better response than downmods.
Optimizing the workloads tested on the benchmarks game has not been a focus.
https://news.ycombinator.com/item?id=9554676
edit: Please provide a better response than downmods.
It isn't bad manners to trust that when steveklabnik answers "No, as optimizing performance hasn't been a focus, shipping good language semantics has been." that's what he means.
Conclusion: Don't draw conclusions from the benchmarks game.
[1] http://benchmarksgame.alioth.debian.org/u64q/performance.php...
[2] i5-3470 @ 3.20GHz
the answer was to what qualities make a lang suited for systems programming not just specific to Rust
And the minimal libraries usually need to be light weight as well. Or at least such that you can strip out what's not wanted. Here again garbage collection becomes an issue. If the language supports it natively then it's going to be impossible in practice to prevent the libraries from using it for something unexpected.
The last bit is escape. There are always some cases where the language doesn't have the ability to implement a critical bit of stuff and you need a way to seamlessly mess with that something. In simple you need to be able to insert a bit of arbitrary code and have it work properly.
Erlang would argue with you. GC works fine as long as you have a bunch of really tiny heaps (attached to a bunch of really tiny processes) which can be collected in parallel. It just sucks for Unix-process-sized heaps.