Hacker News Reader

Comment by lacker | Hacker News Reader

Rust seems like a fine choice for this use case. However, the decisionmaking process is a bit odd. They considered Java, Lua, and Python, but not Go? I think Go is far more "Rust-like" than those other three, ie for people who want something one notch nicer than C++.

View on HN

While I don’t disagree about the consideration of Go, calling Go Rust-like is really strange.

I think of Go as more Java-like than Rust-like. But even that’s a hard comparison. Really, Go is C-like with a garbage collector for memory safety.

Rust is Java or C++-like with a strongly typed compiler, support for generics (not Go), lifetimes for memory management and no GC (closer to C++), and a type system that enforces some constraints around concurrency. I guess they are similar in that they both (by default) create static binaries, but so does C and C++ (if you want).

Rust and Go seem to get lumped together because they both came on the scene around the same time, but that is pretty much where the comparison ends.

> Rust and Go seem to get lumped together because they both came on the scene around the same time

That, and that the golang authors at that time claimed that it was a "systems language". They would later go back on that by attempting to redefine what "systems language" meant.

However Go is indeed being used as real systems language, even if the anti-GC crowd deslikes it.

Examples in production, gVisor, Android GPU debugger, Biscuit and other research OSes, tiny GO for embedded targets, compiler development.

I'm not anti-GC :) The language itself though doesn't lend itself well to larger complex designs however, which I feel precludes it from more interesting projects, and we can see that by the fact that it's mainly getting used for "devops" kind of work. Compare that to Rust or Java (e.g. GraalVM) or C#, the latter two which weren't really advertised as "systems" languages, yet were used there anyway (maybe real-time Java is something else though)

I am also a Rust, Java, C#, C++, ML,... kind of dev.

However as safety minded person, I rather see such projects being done in Go than C, even if I am not a big Go design's fan.

This is actually the area where you will find positive comments from me regarding Go.

> Rust and Go seem to get lumped together because they both came on the scene around the same time, but that is pretty much where the comparison ends.

I don't think it has to end right here. It's definitely true that Rust has a much stronger type system and is more suitable for some kinds of applications (super-low level, libraries, things were we try to avoid allocations, etc.).

However there is a certain set of applications for which both languages are well-suited and potentially more appealing than the other mentioned languages (e.g. Java, C#, Python, etc). Those are applications were we want to have a low memory footprint and ahead of time compilation (to improve startup times and to avoid having to ship also a big VM). Command line applications or daemons fall into the category. And we can definitely see both Rust and Go gaining tractions in those domains.

Rust and Go are both close to being as fast as C++, but not as terrible to actually use. In my subjective opinion, no other languages fit that niche.

Go is to c as Java is to c++.

It was a SoC device that had a real-time latency requirement. I'm actually surprised they even bothered putting Java in the table.

Or Python for that matter. It's the sort of use case where it's worth considering a language without a garbage collector.

Python is mostly refcounted, and I think Python is useful to put in the table because it's a common language and provides a good baseline for user-friendly scripting language performance.

> Or python for that matter

Both Java and Python have (limited) implementations for time-sensitive microcontrollers: Chances are high your SIM card or your chipcard is running Java, and I believe Python (MicroPython) is also in active use on some SOCs

MicroPython is a wholesale rewrite of Python, and is used in quite a few places (the ESA uses it for some of their projects).

Apple's A12 and Snapdragon are both SoC and smartphones do much heavier tasks than running Java.

From context I assume the author was talking about some sort of embedded device, not a high-power smartphone.

I guess I misunderstood the benchmark chart. The Java line shows it taking 500mb, which is absurd, but I assumed that they were running on the target platform and therefore had 500mb of RAM.

It's not clear what the chart is actually demonstrating, or why it had a "Source" link that just goes to a 4-year-old blog post about concurrency in Rust that contains no benchmarks.

My guess is the benchmark chart is just that: a benchmark. They didn't actually write their target program in 6 different languages. They probably just found a set of benchmarks that they believed to be at least somewhat representative. I really wish the article would actually explain this though.

Java runs perfectly fine from smart cards, PIC, and many other kinds of micro-controllers.

Naturally they are special purpose versions and not a OpenJDK dump.

Real-time is a huge field. There is hard-realtime with < 1ms deadlines. And there is soft realtime which is often "fast enough that the user doesn't complain", which is maybe somewhere between 100ms and 1s for various applications. For a cloud-connected device I assume it's in the latter category since most transport protocols won't provide much better guarantees anyway. For those use-cases most languages will be fine.

Yeah, I’d be curious to know why they didn’t at least evaluate Go as a possibility. Seems an odd omission.

> for people who want something one notch nicer than C++

That would be D, .NET Native or AOT Java.

They also considered only Lua 5.1, when Lua is on 5.3 already (and soon to be 5.4).

Lua 5.1 is the last version supported by LuaJIT, which is probably why they used it.

Lua 5.1 has LuaJIT, which is quite fast. Performance was obviously a priority, and since LuaJIT doesn't support newer than 5.1, that's probably why they used that as the point of comparison.

https://luajit.org/performance.html

There used to be some great benchmark comparisons including luajit on the programming language benchmark site[1], but I swear that site has gotten worse as time has gone on.

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/

Please make specific criticisms.

Even — sucks because it doesn't show LuaJIT — would tell us more than "gotten worse".

That would be one reason, you could compare more language runtimes. I think the core of my issue is that it used to provide more data points, and give the user more power. I would think that the site is primarily targeted toward developers, and that we could handle a more data-heavy UI like it used to have.

* There used to be more languages and runtimes shown.

* The site makes decisions for you about which languages you want to compare, whereas before it used to give the user more power. It used to be easier to compare arbitrary languages with each other. I think you could see the "How many times slower?" graph on individual language pages, but it has been a long time since that was on there.

* Related to above, it seems like it changed to be a more mobile-friendly format. I'm not inherently against that, but if it means I get less points of comparison, I am.

* You used to be able to see examples of run-times on multiple machines. It's less relevant now since everything is multi-core, but it did mean that there would be single and multi-thread implementations of some programs, and you could see how they were written and performed differently.

There are other reasons. Most of these are related to each other, and to be clear, I still like that the site exists, and that it provides useful metrics.

> There used to be more languages and runtimes shown.

True —

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> It used to be easier to compare arbitrary languages with each other.

True; and a couple of years of Google Analytics showed that there were one or two people who did. The massive majority made the same comparisons, so it was made easier for them.

> … "How many times slower?" graph on individual language pages…

True; and intentionally removed to force a slower look at the measurements.

> … single and multi-thread implementations of some programs…

There still are — look at "busy" and "cpu load" instead of elapsed "secs".

> …we could handle a more data-heavy UI …

Open the data files in a spreadsheet:

https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...

I was fully aware that my criticisms were unlikely to be taken seriously. Otherwise, why would the site have changed from what it was before?

> > … single and multi-thread implementations of some programs…

> There still are — look at "busy" and "cpu load" instead of elapsed "secs".

I do want to clarify this point. I'm aware of the "cpu load" section of the results. That is not at all the same thing. I don't think this was necessarily even intentional before, but the fact that both systems existed, meant that contributors could explicitly optimize for either single-threaded or multi-threaded.

A single-threaded algorithm will likely smoke a locking multi-threaded algorithm when run on a single-core. It will also probably look completely different.

I did take your comments seriously. Have you taken my point-by-point response seriously?

I acknowledged your "criticisms" that "there used to be more languages and runtimes shown" and that "you used to be able to see examples of run-times on multiple machines".

Do you acknowledge that those "criticisms" sound a lot like someone saying — give me more free stuff ?

> …contributors could explicitly optimize for either single-threaded or multi-threaded…

They still can; have you noticed that the Chapel programs are optimized for program size?

> …single-threaded … will likely smoke a locking multi-threaded…

Look at the programs —

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

    15.82 (busy)   Ada 2012 GNAT #3 (15.79 cpu)
    15.89 (busy)   Ada 2012 GNAT (15.69 cpu)

    15.84 (busy)   Free Pascal #2 (15.82 cpu)
    16.15 (busy)   Free Pascal (15.98 cpu)

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> A single-threaded algorithm will likely smoke a locking multi-threaded algorithm when run on a single-core

Do you claim the single-threaded program will speed-up on single-core?

Do you claim the multi-threaded program will slow-down on single-core?

We can look in the Internet Archive and see neither of those things happened —

    Free Pascal mandelbrot #4 program [multi threaded]
    68.18 elapsed secs, 68.15 cpu secs [single core]
    17.07 elapsed secs, 68.14 cpu secs [quad core]


    Free Pascal mandelbrot #3 program [single threaded]
    75.47 elapsed secs, 75.43 cpu secs [single core]
    75.47 elapsed secs, 75.44 cpu secs [quad core]

https://web.archive.org/web/20150221165617/http://benchmarks...

https://web.archive.org/web/20150221172620/http://benchmarks...

I'm working with go since last September. It is a glorified bash script. Absolutely "go" with Rust.

When dealing in such embedded systems, there's often not a whole lot of help online for arcane issues. Device documentation etc. usually makes default assumptions about C/C++. Drivers, other tools - same. This is usually a big concern.

If there isn't much software involved, then the natural choice would be that which most easily integrates with the platform, because at that level, there's always trouble.

Given limited information, I probably would have chosen C/C++, and then done some experiments with Rust to see if it was worthwhile, and then possibly port over during an appropriate iteration.

Reply on news.ycombinator.com