6 ms·

How golang compares to zig? Not using any of them, but from my understanding both of them trying to be "simple". Just curious what is the difference on the high

How golang compares to zig? Not using any of them, but from my understanding both of them trying to be "simple". Just curious what is the difference on the highter level

wolf550e 6y ago
AFAIK Go has a GC you can't avoid, so it's not very suitable for embedded or realtime.
- deleted 6y ago
  [deleted]
- coder543 6y ago
  "not very suitable" is a relative term. TinyGo is a cool project: https://tinygo.org https://tinygo.org There are various conference presentations about it that show it in action.
  - IshKebab 6y ago
    Cool project but I think he's still right - you normally don't want GC on your microcontroller and often you don't want heap allocations at all. Very difficult to write Go with those constraints.
    - coder543 6y ago
      Lots of "serious" microcontroller projects are written in MicroPython, Lua (such as eLua), and Espruino (JavaScript). I think it's simply an outdated oversimplification in 2021 to say that microcontroller projects "normally" don't want heap allocations at all. TinyGo also makes it relatively easy to avoid heap allocations because you can change a compiler flag to make heap allocations a compiler error^1, if that's required for a particular project. ^1: https://tinygo.org/usage/important-options/ https://tinygo.org/usage/important-options/ (look at -gc=none) Another interesting link: https://tinygo.org/compiler-internals/heap-allocation/ https://tinygo.org/compiler-internals/heap-allocation/
      - Cyph0n 6y ago
        It ultimately depends on your definition of “serious” and the microcontrollers we’re talking about. For performance-sensitive areas where deterministic latency is critical, a GC simply won’t cut it, even if you can control when to run the GC step. For lower end microcontrollers, I highly doubt any of those solutions would ever work: there is simply too much “magic” (read: overhead) involved. This is primarily why C is still king of the microcontroller world.
dilap 6y ago
It's interesting to consider generics. Go gained some simplicity by not having generics, instead simply special-casing the two most common generic datastructures: lists and maps. But in the end, the desire for generics was too strong, and now they're adding them to the language, and losing that simplicity win. Zig gained simplicity by not having generics, but instead giving you comp-time evaluation, which can do everything generics can do and more (e.g., replaces need for preprocessor, need for minilanguage for build variants). I do think both languages have similar philosophies and feel, though Zig is much lower level, and seems to have more of a focus on "get things exactly right" vs. maybe more of a "eh, good enough / hacky" approach from Go. I wonder what a language that tried to combine this focus on smallness/orthogonality with a borrow checker would look like. (Would it even be possible?)

How golang compares to zig? Not using any of them, but from my understanding both of them trying to be "simple". Just curious what is the difference on the highter level

wolf550e 6y ago

AFAIK Go has a GC you can't avoid, so it's not very suitable for embedded or realtime.

deleted 6y ago
[deleted]
coder543 6y ago
"not very suitable" is a relative term. TinyGo is a cool project: https://tinygo.org https://tinygo.org There are various conference presentations about it that show it in action.
- IshKebab 6y ago
  Cool project but I think he's still right - you normally don't want GC on your microcontroller and often you don't want heap allocations at all. Very difficult to write Go with those constraints.
  - coder543 6y ago
    Lots of "serious" microcontroller projects are written in MicroPython, Lua (such as eLua), and Espruino (JavaScript). I think it's simply an outdated oversimplification in 2021 to say that microcontroller projects "normally" don't want heap allocations at all. TinyGo also makes it relatively easy to avoid heap allocations because you can change a compiler flag to make heap allocations a compiler error^1, if that's required for a particular project. ^1: https://tinygo.org/usage/important-options/ https://tinygo.org/usage/important-options/ (look at -gc=none) Another interesting link: https://tinygo.org/compiler-internals/heap-allocation/ https://tinygo.org/compiler-internals/heap-allocation/
    - Cyph0n 6y ago
      It ultimately depends on your definition of “serious” and the microcontrollers we’re talking about. For performance-sensitive areas where deterministic latency is critical, a GC simply won’t cut it, even if you can control when to run the GC step. For lower end microcontrollers, I highly doubt any of those solutions would ever work: there is simply too much “magic” (read: overhead) involved. This is primarily why C is still king of the microcontroller world.

dilap 6y ago

It's interesting to consider generics. Go gained some simplicity by not having generics, instead simply special-casing the two most common generic datastructures: lists and maps. But in the end, the desire for generics was too strong, and now they're adding them to the language, and losing that simplicity win. Zig gained simplicity by not having generics, but instead giving you comp-time evaluation, which can do everything generics can do and more (e.g., replaces need for preprocessor, need for minilanguage for build variants). I do think both languages have similar philosophies and feel, though Zig is much lower level, and seems to have more of a focus on "get things exactly right" vs. maybe more of a "eh, good enough / hacky" approach from Go. I wonder what a language that tried to combine this focus on smallness/orthogonality with a borrow checker would look like. (Would it even be possible?)