7 ms·

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

by lacker 7y ago

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++.

bluejekyll 7y ago
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.
- apta 7y ago
  > 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.
  - pjmlp 7y ago
    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.
    - apta 7y ago
      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)
      - pjmlp 7y ago
        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.
- Matthias247 7y ago
  > 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.
- lacker 7y ago
  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.
- e12e 7y ago
  Go is to c as Java is to c++.
eridius 7y ago
It was a SoC device that had a real-time latency requirement. I'm actually surprised they even bothered putting Java in the table.
- incompatible 7y ago
  Or Python for that matter. It's the sort of use case where it's worth considering a language without a garbage collector.
  - cyphar 7y ago
    MicroPython is a wholesale rewrite of Python, and is used in quite a few places (the ESA uses it for some of their projects).
  - eridius 7y ago
    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.
  - mattashii 7y ago
    > 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
- da_chicken 7y ago
  Apple's A12 and Snapdragon are both SoC and smartphones do much heavier tasks than running Java.
  - eridius 7y ago
    From context I assume the author was talking about some sort of embedded device, not a high-power smartphone.
Zelizz 7y ago
They also considered only Lua 5.1, when Lua is on 5.3 already (and soon to be 5.4).
- MereInterest 7y ago
  Lua 5.1 is the last version supported by LuaJIT, which is probably why they used it.
- uep 7y ago
  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 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/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/
  - igouy 7y ago
    Please make specific criticisms. Even — sucks because it doesn't show LuaJIT — would tell us more than "gotten worse".
    - uep 7y ago
      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.
camdenlock 7y ago
Yeah, I’d be curious to know why they didn’t at least evaluate Go as a possibility. Seems an odd omission.
sonnyblarney 7y ago
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.
invasionofsmall 7y ago
I'm working with go since last September. It is a glorified bash script. Absolutely "go" with Rust.
pjmlp 7y ago
> for people who want something one notch nicer than C++ That would be D, .NET Native or AOT Java.

by lacker 7y ago

bluejekyll 7y ago

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.

apta 7y ago
> 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.
- pjmlp 7y ago
  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.
  - apta 7y ago
    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)
    - pjmlp 7y ago
      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.
Matthias247 7y ago
> 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.
lacker 7y ago
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.
e12e 7y ago
Go is to c as Java is to c++.

eridius 7y ago

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

incompatible 7y ago
Or Python for that matter. It's the sort of use case where it's worth considering a language without a garbage collector.
- cyphar 7y ago
  MicroPython is a wholesale rewrite of Python, and is used in quite a few places (the ESA uses it for some of their projects).
- eridius 7y ago
  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.
- mattashii 7y ago
  > 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
da_chicken 7y ago
Apple's A12 and Snapdragon are both SoC and smartphones do much heavier tasks than running Java.
- eridius 7y ago
  From context I assume the author was talking about some sort of embedded device, not a high-power smartphone.

Zelizz 7y ago

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

MereInterest 7y ago
Lua 5.1 is the last version supported by LuaJIT, which is probably why they used it.
uep 7y ago
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 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/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/
- igouy 7y ago
  Please make specific criticisms. Even — sucks because it doesn't show LuaJIT — would tell us more than "gotten worse".
  - uep 7y ago
    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.

camdenlock 7y ago

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

sonnyblarney 7y ago

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.

invasionofsmall 7y ago

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

pjmlp 7y ago

> for people who want something one notch nicer than C++ That would be D, .NET Native or AOT Java.