5 ms·

I'm surprised to see that Go wasn't considered. While not as lean and mean as Rust, it also has excellent support for parallelism and safety, while being easier

by fwip 7y ago

I'm surprised to see that Go wasn't considered. While not as lean and mean as Rust, it also has excellent support for parallelism and safety, while being easier to get into. Edit: For clarity, I'm not saying Go is the best choice. But when Lua, Python, and Java are in the running, it's surprising that Go wasn't. Especially when the article calls out the learning curve of Rust as a downside.

hackcasual 7y ago
It's for an embedded (SoC) device, so likely they didn't want the overhead of a more managed language.
- dom96 7y ago
  and yet they include Python in the comparison?
  - cyphar 7y ago
    MicroPython is a wholesale rewrite of Python to be suitable for microcontrollers. From memory, the ESA (European Space Agency) uses it for some of their projects.
  - deleted 7y ago
    [deleted]
- randyrand 7y ago
  He never said it was embedded.
  - reificator 7y ago
    > He never said it was embedded. > We needed a language that was fast enough to allow minimum real-time latency and use limited resources of a SoC device.
    - flukus 7y ago
      SoC also describes a modern phone, rasberry pi, probably even some modern laptops/netbooks. I think it's generally agreed that these are not embedded devices, but the line used to be much blurrier. It sounds like the evaluated their options, added in a few that they were never really going to consider anyway, came to the conclusion that C++ was best but then made up some reasons to use rust anyway.
solipsism 7y ago
It's a real stretch to call Go's support for memory safety "excellent".
- monocasa 7y ago
  Strictly speaking, it is memory safe with the exception of storing pointers in atomics and unsafe calls AFAIK.
  - Jweb_Guru 7y ago
    Sending slices over channels can cause UB.
    - chessturk 7y ago
      Do you have an article on this? I didn't know that was possible.
vlovich123 7y ago
> minimum real-time latency and use limited resources of a SoC device.
0815test 7y ago
Well, Go has excellent support for parallelism and excellent support for safety - whereas Rust actually supports parallelism with safety. Rust is also gaining lots of useful "tweaks" that will make it quite a bit easier to get into in the future - and the syntax alone is a big draw to former Ruby, Python etc. programmers, while you really can't say the same about Go. Now, of course Rust is not for everything (some things really can't be done without efficient GC, and Go gives you that), but it looks like these Bitbucket users made a very solid choice here.
- harikb 7y ago
  > Author bio: Mohit Agrawal is a software developer from Indore, India and works at Oviyum Technologies, an outsourced product development firm Not sure why bitbucket is promoting this particular guest post.
- reificator 7y ago
  > it looks like the Bitbucket folks made a very solid choice here. Just a heads up, this is not from the bitbucket team. That's just where it's hosted.
- apta 7y ago
  > has excellent support for parallelism concurrency, not parallelism, and even there it doesn't have anything similar to immutable data structures or java.util.concurrent or System.Collections.Concurrent > support for safety Not more than any other available GC'd languages. > some things really can't be done without efficient GC, and Go gives you that Only if you care about pause times at the expense of throughput, and you don't have to deal with very large heaps
deleted 7y ago
[deleted]
apta 7y ago
> support for parallelism It has support for concurrency, not parallelism. > and safety It's not any safer than other GC'd language available today, and likely quite less so compared to languages with immutability and proper persistent data structures in them (Scala, Java, F#, etc.)
- bsaul 7y ago
  I’m curious what you mean by « no support for parallelism » ? Goroutines are scheduled on different processors, and do run in parallel.
  - apta 7y ago
    It's at the discretion of the runtime though. With native threads you have more control. And you can have several goroutines running on the same processor concurrently.

by fwip 7y ago

hackcasual 7y ago

It's for an embedded (SoC) device, so likely they didn't want the overhead of a more managed language.

dom96 7y ago
and yet they include Python in the comparison?
- cyphar 7y ago
  MicroPython is a wholesale rewrite of Python to be suitable for microcontrollers. From memory, the ESA (European Space Agency) uses it for some of their projects.
- deleted 7y ago
  [deleted]
randyrand 7y ago
He never said it was embedded.
- reificator 7y ago
  > He never said it was embedded. > We needed a language that was fast enough to allow minimum real-time latency and use limited resources of a SoC device.
  - flukus 7y ago
    SoC also describes a modern phone, rasberry pi, probably even some modern laptops/netbooks. I think it's generally agreed that these are not embedded devices, but the line used to be much blurrier. It sounds like the evaluated their options, added in a few that they were never really going to consider anyway, came to the conclusion that C++ was best but then made up some reasons to use rust anyway.

solipsism 7y ago

It's a real stretch to call Go's support for memory safety "excellent".

monocasa 7y ago
Strictly speaking, it is memory safe with the exception of storing pointers in atomics and unsafe calls AFAIK.
- Jweb_Guru 7y ago
  Sending slices over channels can cause UB.
  - chessturk 7y ago
    Do you have an article on this? I didn't know that was possible.

vlovich123 7y ago

> minimum real-time latency and use limited resources of a SoC device.

0815test 7y ago

Well, Go has excellent support for parallelism and excellent support for safety - whereas Rust actually supports parallelism with safety. Rust is also gaining lots of useful "tweaks" that will make it quite a bit easier to get into in the future - and the syntax alone is a big draw to former Ruby, Python etc. programmers, while you really can't say the same about Go. Now, of course Rust is not for everything (some things really can't be done without efficient GC, and Go gives you that), but it looks like these Bitbucket users made a very solid choice here.

harikb 7y ago
> Author bio: Mohit Agrawal is a software developer from Indore, India and works at Oviyum Technologies, an outsourced product development firm Not sure why bitbucket is promoting this particular guest post.
reificator 7y ago
> it looks like the Bitbucket folks made a very solid choice here. Just a heads up, this is not from the bitbucket team. That's just where it's hosted.
apta 7y ago
> has excellent support for parallelism concurrency, not parallelism, and even there it doesn't have anything similar to immutable data structures or java.util.concurrent or System.Collections.Concurrent > support for safety Not more than any other available GC'd languages. > some things really can't be done without efficient GC, and Go gives you that Only if you care about pause times at the expense of throughput, and you don't have to deal with very large heaps

deleted 7y ago

[deleted]

apta 7y ago

> support for parallelism It has support for concurrency, not parallelism. > and safety It's not any safer than other GC'd language available today, and likely quite less so compared to languages with immutability and proper persistent data structures in them (Scala, Java, F#, etc.)

bsaul 7y ago
I’m curious what you mean by « no support for parallelism » ? Goroutines are scheduled on different processors, and do run in parallel.
- apta 7y ago
  It's at the discretion of the runtime though. With native threads you have more control. And you can have several goroutines running on the same processor concurrently.