13 ms·

> - Restricting the language to its target use: systems programming, not applications or data science or AI... Go has a GC and a very heavy runtime with green

> - Restricting the language to its target use: systems programming, not applications or data science or AI... Go has a GC and a very heavy runtime with green threads, leading to cumbersome/slow C interop. It certainly isn't viable as systems programming language , which is by design. That's an odd myth that has persisted ever since the language called itself as such in the beginning. They removed that wording years ago I think. It's primarily a competitor to Java et al, not to C or Rust, and you see that when looking at the domains it is primarily used in, although it tends to sit a bit lower on the stack due to the limited nature of the type system and the great support for concurrency.

wredcoll 3y ago
Man, arguments about the definition of "systems programming" are almost as much fun as the old "dynamic" vs "static" language wars.
- kibwen 3y ago
  > the old "dynamic" vs "static" language wars. We used to argue about dynamic vs static languages. We still do, but we used to, too.
  - ysofunny 3y ago
    then there's this https://en.wikipedia.org/wiki/Dynamic_programming https://en.wikipedia.org/wiki/Dynamic_programming which has nothing to do with types nor variables but with algorithm optimization
    - jfoutz 3y ago
      The trick is to throw memory at it. if memoization helps, that’ll work without the memory hit!
  - klausnrooster 3y ago
    :) ...Mitch
  - tharne 3y ago
    RIP Mitch, you were one of the greats.
- pohl 3y ago
  I don’t recall anything but a single definition of the term until Google muddied the waters.
- fractalb 3y ago
  IIRC, Google tried to use Go for their Fuchsia TCP stack and then backtracked. Not a systems programming language for sure.
  - pjmlp 3y ago
    Sure it backtracked, because the guy pushing for Go left the team, and the rest is history. Is writing compilers, linkers, IoT and bare metal firmware systems programming?
    - raggi 3y ago
      I worked on Fuchsia for many years, and maintained the Go fork for a good while. Fuchsia shipped with the gvisor based (go) netstack to google home devices. The Go fork was a pain for a number of reasons, some were history, but more deeply the plan for fixing that was complicated due to the runtime making fairly core architectural assumptions that the world has fd's and epoll-like behavior. Those constraints cause challenges even for current systems, and even for Linux where you may not want to be constrained by that anymore. Eventually Fuchsia abandoned Go for new software because folks hired to rewrite the integration ran out of motivation to do so, and the properties of the runtime as-written presented atrocious performance on a power/performance curve - not suitable for battery based devices. Binary sizes also made integration into storage constrained systems more painful, and without a large number of components written in the language to bundle together the build size is too large. Rust and C++ also often produce large binaries, but they can be substantially mitigated with dynamic linking provided you have a strong package system that avoids the ABI problem as Fuchsia does. The cost of crossing the cgo/syscall boundary remains high, and got higher over the time that Fuchsia was in major development due to the increased cost of spectre and meltdown mitigations. The cgo/syscall boundary cost shows up in my current job a lot too, where we do things like talk to sqlite constantly for small objects or shuffle small packets of less than or equal to common mtu sizes. Go is slow at these things in the same way that other managed runtimes are - for the same reasons. It's hard to integrate foreign APIs unless the standard library already integrated them in the core APIs - something the team will only do for common use cases (reasonably so, but annoying when you're stuck fighting it constantly). There are quite a few measures like this where Go has a high cost of implementation for lower level problems - problems that involve high frequency integration with surrounding systems. Go has a lower cost of ownership when you can pass very large buffers in or out of the program and do lots of work on them, and when your concurrency models fit the channel/goroutine model ok. If you have a problem that involves higher frequency operations, or more interesting targets, you'll find the lack of broader atomics, the inability to cheaply or precisely schedule work problematic.
sapiogram 3y ago
I totally agree that Go is best suited outside of systems programming, but to me that always seemed like a complete accident - its creators explicitly said their goal was to replace C++. But somehow it completely failed to do so, while simultaneously finding enormous success as a statically typed (and an order of magnitude faster) alternative to Python.
- usrusr 3y ago
  Go appears to be made with radical focus on a niche that isn't particularly well specified outside the heads of its benevolent directorate for life. Opinionated to the point of "if you use Go outside that unnamed niche you got no-one to blame but yourself". Could almost be called a solution looking for a problem. But it also appears to be quite successful at finding problem-fit, no doubt helped by the clarity of that focus. They've been very open about what they consider Go no to be or ever become. Unlike practically every other language, they all seem to eventually fall into the trap of advertising themselves with what boils down to "in a pinch you could also use it for everything else". It's quite plausible that before Go, its creators would have chosen C++ for problems they consider in "The Go Niche". That would be perfectly sufficient to declare it a C++ replacement in that niche. Just not a universal C++ replacement.
  - pjmlp 3y ago
    Consider this, the authors have fixed some of the Plan 9 design errors including the demise of Alef, by creating Inferno and Limbo (yeah it was a response to Java OS, but still). Where C is only used for the Inferno kernel, Limbo VM (with a JIT) and little else like Tk bindings, everything else in Inferno is written in Limbo. Replace Limbo with AOT compiled Go, and that is what systems programming is in the minds of UNIX, Plan 9 and Inferno authors.
- fishywang 3y ago
  >its creators explicitly said their goal was to replace C++ so nowadays when we say "c++" we mostly mean the works should be replaced by rust, but back then, it's not like that. I would argue that go successfully replaced c++ in specific domains (network, etc.), and changed your perspective on what "c++" means.
randomdata 3y ago
> It certainly isn't viable as systems programming language It is perfectly viable as a systems programming language. Remember, systems are the alternative to scripts. Go is in no way a scripting language... You must be involved in Rust circles? They somehow became confused about what systems are, just as they became confused about what enums are. That is where you will find the odd myths.
- cdogl 3y ago
  Indeed - I’ve seen this refrain about “systems programming” countless times. I’m not sure how one can sustain the argument that a “system” is only an OS kernel, network stack or graphics driver.
- leoc 3y ago
  It’s all admittedly a somewhat handwaving discussion, but in ‘systems programming’ ‘systems’ is generally understood to be opposite to ‘applications’, not ‘scripts’.
  - randomdata 3y ago
    All software is application. That’s what software is for!
    - bmicraft 3y ago
      I wouldn't consider a driver an application
      - randomdata 3y ago
        application: the action of putting something into operation What's a driver if not something that carries out an action of putting something (an electronic device, typically) into operation?
      - kazinator 3y ago
        We live in an age in which a PC running an OS, which has drivers in it, is something that can be done by Javascript in a browser.
zozbot234 3y ago
Early versions of Rust were a lot like Golang with some added OCaml flavor. Complete with general GC, green threading etc. They pivoted to current Rust with its focus on static borrowcheck and zero-overhead abstractions very late in the language's evolution (though still pre-1.0 obviously) because they weren't OK with the heavy runtime and cumbersome interop with C FFI. So there's that.
- kibwen 3y ago
  Both Rust and Go are descendants of Limbo, Pike's prior language, although while Limbo's DNA remains strong in Go it's much more diffuse in Rust.
  - sapiogram 3y ago
    While those influences are important to Rust's history, they were mostly removed from the language before 1.0, notably green threads and the focus on channels as a core concurrency primitive. Channels still exist as a library in stdlib, but they're infinitely buffered by default, and aren't widely used.
- masklinn 3y ago
  > Complete with general GC, green threading etc. AFAIK there was never "general GC". There was a GC'd smart pointer (@), and its implementation never got beyond refcounting, it was moved behind a feature gate (and a later-removed Gc library type) in 0.9 and removed in 0.10. Ur-Rust was closer to an "applications" language for sure, and thus closer to Go's (possibly by virtue of being closer to OCaml), but it was always focused much more strongly on type safety and lifting constraints to types, as well as more interested in low-level concerns: unique pointers (~) and move semantics (if in a different form) were part of Rust 0.1. That is what the community glommed onto, leading to "the pivot": there were applications language aplenty, but there was a real hunger for a type-heavy and memory-safe low level / systems programming language, and Rust had the bones of it.
  - tialaramex 3y ago
    > a real hunger for a type-heavy and memory-safe low level / systems programming language, and Rust had the bones of it. I didn't know I wanted this, but yes, I did want this and when I got it I was much more enthusiastic than I'd ever been about languages like Python or Java. I bounced off Go, it's not bad but it didn't do anything I cared about enough to push through all the usual annoyances of a new language, whereas Rust was extremely compelling by the time I looked into it (only a few years ago) and has only improved since.
opportune 3y ago
Seconding this. Go also has some opinionated standard libraries (want to differentiate between header casings in http requests because your clients/downstream services do? Go fuck yourself!) and shies you away from doing hacky, ugly, dangerous things you need in a systems language. It’s absolutely an applications language.
- aatd86 3y ago
  Headers are case-sensitive?
  - jrockway 3y ago
    They aren't, but because you can send Foo-Bar as fOo-BaR on the wire, someone somewhere depends on it. People don't read the specs, they look at the example data, and decide that's how their program works now. Postel's Law allows this. A different law might say "if anything is invalid or weird, reject it instantly" and there would be a lot less security bugs. But we also wouldn't have TCP or HTTP.
  - akoboldfrying 3y ago
    No, and that wasn't the claim being made. The claim being made was that there can be engineering value in preserving the case of existing headers. Example: An HTTP proxy that preserves the case of HTTP headers is going to cause less breakage than one that changes them. In a perfect world, it would make no difference, but that isn't the world we live in.
    - aatd86 3y ago
      Are you sure they are discarded and unrecoverable? Can't that be simply recovered by using textproto.MIMEHeader and iterating over the header map? Seems that it could be a middleware away, I don't see the big deal if so.
      - akoboldfrying 3y ago
        You may well be right -- I don't know Go at all, and just assumed the parent post's claim is true.
ysofunny 3y ago
let's just pretend that when go lang people say "systems programing" they mean smething closer to "network (systems) programming" which is where go shines the brightest
- kernal 3y ago
  And yet Google replaced the go based network stack in Fuchsia with rust for performance reasons.
  - howenterprisey 3y ago
    I understand ysofunny's comment to have meant basically microservices/contemporary web backend.
  - pjmlp 3y ago
    After the guy responsible for it left the team.
    - ikiris 3y ago
      This sounds more like for perf reasons that for performance reasons.
  - kramerger 3y ago
    Hold on a minute. You are confusing the network stack (as in OS development) and network applications. Go is the undisputed king of backend, but no reasonable person has ever claimed its a good choice for OS development.
veqq 3y ago
> runtime ... GC ... not viable as systems programming language A GC can work fine. At the lower levels, people want to save every flop, but at the higher levels uncounted millions are wasted by JS, Electron apps etc. etc. We can sacrifice a little on the bottom (in the kernel) for great comfort, without a difference. But you don't even have to make sacrifices. A high performance kernel only needs to allocate at startup, without freeing memory, allowing you to e.g. skip GC completely (turn it off with a compiler flag). This does require the kernel to implement specific optimizations though, which aren't typically party to a language spec. Anyway, some OS implemented with a GC: Oberon/Bluebottle (the Oberon language was designed specifically to implement the Oberon OS), JavaOS, JX, JNode, Smalltalk (was the OS for the first Smalltalk systems), Lisp in old Lisp machines... Interval Research even worked on a real time OS written in Smalltalk. Indeed, GC can work in hard real time systems e.g. the Aonix PERC Ultra, embedded real time Java for missile control (but Go's current runtime' GC stops are unpredictable....) Particularly when we consider modern hardware problems (basic OS research already basically stopped in the 90s, yay risc processor design...), with minimal hardware support for high speed context switching because of processor speed vs. memory access latency... Well, it's not like we can utilize such minuscule operations anyway. Why don't we just have sensible processors which don't encourage us to unroll loops, which have die space to store context... There were Java processors [2] which implement the JVM in hardware, with Java bytecode as machine code. Before llvm gained dominance, there were processors optimized to many languages (even Forths!) David Chisnell, a RTOS and FreeBSD contributor recently went into quite a bit of depth [1] ending with: > everything that isn’t an allocator, a context-switch routine, or an ISR, can be written in a fully type-safe GC’d language [1] https://lobste.rs/s/e6tz0r/memory_safety_is_red_herring#c_gf5fyy https://lobste.rs/s/e6tz0r/memory_safety_is_red_herring#c_gf... [2] https://www.electronicdesign.com/technologies/embedded/article/21772568/java-processors https://www.electronicdesign.com/technologies/embedded/artic...
- davedx 3y ago
  The nice thing about Java is you can choose which GC to use
  - pjmlp 3y ago
AnimalMuppet 3y ago
For people of Pike's generation, "systems programming" means, roughly, the OS plus the utilities that would come with an OS. Well, Go may not be useful for writing the OS, but for the OS-level utilities, it works just fine.
- jayd16 3y ago
  Has it found success in OS-level utilities? What popular utilities are written in Go?
  - pjmlp 3y ago
    Being self hosted? Gokrazy userspace? gVisor?
  - ziotom78 3y ago
    Not sure these are really popular, but I cannot resist advertising a few utilities written in Go that I regularly use in my daily workflow: - gdu: a NCDU clone, much faster on SSD mounts [1] - duf: a `df` clone with a nicer interface [2] - massren: a `vidir` clone (simpler to use but with fewer options) [3] - gotop: a `top` clone [4] - micro: a nice TUI editor [5] Building this kind of tools in Go makes sense, as the executables are statically compiled and are thus easy to install on remote servers. [1]: https://github.com/dundee/gdu https://github.com/dundee/gdu [2]: https://github.com/muesli/duf https://github.com/muesli/duf [3]: https://github.com/laurent22/massren https://github.com/laurent22/massren [4]: https://github.com/xxxserxxx/gotop https://github.com/xxxserxxx/gotop [5]: https://github.com/zyedidia/micro https://github.com/zyedidia/micro
  - konart 3y ago
    Not sure what should be counted as OS-level. Is docker cli and OS level? What about lazygit? chezmoi? dive? fzf? Actually many popular utilities are written in Go
  - nolist_policy 3y ago
    Docker and Podman.
kazinator 3y ago
The shells scripts that bring up a machine are also "systems programming".
0xpgm 3y ago
Maybe the better term for go would be server-systems programming.
- bborud 3y ago
  Server programming? The term "systems programming" seems to be interpreted very differently by different people which in practice renders it useless. It is probably best to not use it at all to avoid confusion.
pjmlp 3y ago
Niklaus Wirth, rest his soul, would disagree. Like would the folks at WithSecure, selling the USB Armory with Go written firmware. https://www.withsecure.com/en/solutions/innovative-security-hardware/usb-armory https://www.withsecure.com/en/solutions/innovative-security-... Back in my day, writing compilers and OS services were also systems programming.
Matl 3y ago
"systems" can mean "distributed systems", "network systems" etc. both of which Go is suitable for. It's obviously not a great choice for "operating systems" which is well known.
- jgtgiuhhvvf 3y ago
  [flagged]
yencabulator 3y ago
I'll just leave this here (emphasis mine) https://en.wikipedia.org/wiki/Systems_programming https://en.wikipedia.org/wiki/Systems_programming > The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software which provides services to the user directly (e.g. word processor), whereas systems programming aims to produce software and software platforms which *provide services to other software*, are performance constrained, or both (e.g. operating systems, computational science applications, game engines, industrial automation, and software as a service applications).

wredcoll 3y ago

Man, arguments about the definition of "systems programming" are almost as much fun as the old "dynamic" vs "static" language wars.

kibwen 3y ago
> the old "dynamic" vs "static" language wars. We used to argue about dynamic vs static languages. We still do, but we used to, too.
- ysofunny 3y ago
  then there's this https://en.wikipedia.org/wiki/Dynamic_programming https://en.wikipedia.org/wiki/Dynamic_programming which has nothing to do with types nor variables but with algorithm optimization
  - jfoutz 3y ago
    The trick is to throw memory at it. if memoization helps, that’ll work without the memory hit!
- klausnrooster 3y ago
  :) ...Mitch
- tharne 3y ago
  RIP Mitch, you were one of the greats.
pohl 3y ago
I don’t recall anything but a single definition of the term until Google muddied the waters.
fractalb 3y ago
IIRC, Google tried to use Go for their Fuchsia TCP stack and then backtracked. Not a systems programming language for sure.
- pjmlp 3y ago
  Sure it backtracked, because the guy pushing for Go left the team, and the rest is history. Is writing compilers, linkers, IoT and bare metal firmware systems programming?
  - raggi 3y ago
    I worked on Fuchsia for many years, and maintained the Go fork for a good while. Fuchsia shipped with the gvisor based (go) netstack to google home devices. The Go fork was a pain for a number of reasons, some were history, but more deeply the plan for fixing that was complicated due to the runtime making fairly core architectural assumptions that the world has fd's and epoll-like behavior. Those constraints cause challenges even for current systems, and even for Linux where you may not want to be constrained by that anymore. Eventually Fuchsia abandoned Go for new software because folks hired to rewrite the integration ran out of motivation to do so, and the properties of the runtime as-written presented atrocious performance on a power/performance curve - not suitable for battery based devices. Binary sizes also made integration into storage constrained systems more painful, and without a large number of components written in the language to bundle together the build size is too large. Rust and C++ also often produce large binaries, but they can be substantially mitigated with dynamic linking provided you have a strong package system that avoids the ABI problem as Fuchsia does. The cost of crossing the cgo/syscall boundary remains high, and got higher over the time that Fuchsia was in major development due to the increased cost of spectre and meltdown mitigations. The cgo/syscall boundary cost shows up in my current job a lot too, where we do things like talk to sqlite constantly for small objects or shuffle small packets of less than or equal to common mtu sizes. Go is slow at these things in the same way that other managed runtimes are - for the same reasons. It's hard to integrate foreign APIs unless the standard library already integrated them in the core APIs - something the team will only do for common use cases (reasonably so, but annoying when you're stuck fighting it constantly). There are quite a few measures like this where Go has a high cost of implementation for lower level problems - problems that involve high frequency integration with surrounding systems. Go has a lower cost of ownership when you can pass very large buffers in or out of the program and do lots of work on them, and when your concurrency models fit the channel/goroutine model ok. If you have a problem that involves higher frequency operations, or more interesting targets, you'll find the lack of broader atomics, the inability to cheaply or precisely schedule work problematic.

sapiogram 3y ago

I totally agree that Go is best suited outside of systems programming, but to me that always seemed like a complete accident - its creators explicitly said their goal was to replace C++. But somehow it completely failed to do so, while simultaneously finding enormous success as a statically typed (and an order of magnitude faster) alternative to Python.

usrusr 3y ago
Go appears to be made with radical focus on a niche that isn't particularly well specified outside the heads of its benevolent directorate for life. Opinionated to the point of "if you use Go outside that unnamed niche you got no-one to blame but yourself". Could almost be called a solution looking for a problem. But it also appears to be quite successful at finding problem-fit, no doubt helped by the clarity of that focus. They've been very open about what they consider Go no to be or ever become. Unlike practically every other language, they all seem to eventually fall into the trap of advertising themselves with what boils down to "in a pinch you could also use it for everything else". It's quite plausible that before Go, its creators would have chosen C++ for problems they consider in "The Go Niche". That would be perfectly sufficient to declare it a C++ replacement in that niche. Just not a universal C++ replacement.
- pjmlp 3y ago
  Consider this, the authors have fixed some of the Plan 9 design errors including the demise of Alef, by creating Inferno and Limbo (yeah it was a response to Java OS, but still). Where C is only used for the Inferno kernel, Limbo VM (with a JIT) and little else like Tk bindings, everything else in Inferno is written in Limbo. Replace Limbo with AOT compiled Go, and that is what systems programming is in the minds of UNIX, Plan 9 and Inferno authors.
fishywang 3y ago
>its creators explicitly said their goal was to replace C++ so nowadays when we say "c++" we mostly mean the works should be replaced by rust, but back then, it's not like that. I would argue that go successfully replaced c++ in specific domains (network, etc.), and changed your perspective on what "c++" means.

randomdata 3y ago

> It certainly isn't viable as systems programming language It is perfectly viable as a systems programming language. Remember, systems are the alternative to scripts. Go is in no way a scripting language... You must be involved in Rust circles? They somehow became confused about what systems are, just as they became confused about what enums are. That is where you will find the odd myths.

cdogl 3y ago
Indeed - I’ve seen this refrain about “systems programming” countless times. I’m not sure how one can sustain the argument that a “system” is only an OS kernel, network stack or graphics driver.
leoc 3y ago
It’s all admittedly a somewhat handwaving discussion, but in ‘systems programming’ ‘systems’ is generally understood to be opposite to ‘applications’, not ‘scripts’.
- randomdata 3y ago
  All software is application. That’s what software is for!
  - bmicraft 3y ago
    I wouldn't consider a driver an application
    - randomdata 3y ago
      application: the action of putting something into operation What's a driver if not something that carries out an action of putting something (an electronic device, typically) into operation?
    - kazinator 3y ago
      We live in an age in which a PC running an OS, which has drivers in it, is something that can be done by Javascript in a browser.

zozbot234 3y ago

Early versions of Rust were a lot like Golang with some added OCaml flavor. Complete with general GC, green threading etc. They pivoted to current Rust with its focus on static borrowcheck and zero-overhead abstractions very late in the language's evolution (though still pre-1.0 obviously) because they weren't OK with the heavy runtime and cumbersome interop with C FFI. So there's that.

kibwen 3y ago
Both Rust and Go are descendants of Limbo, Pike's prior language, although while Limbo's DNA remains strong in Go it's much more diffuse in Rust.
- sapiogram 3y ago
  While those influences are important to Rust's history, they were mostly removed from the language before 1.0, notably green threads and the focus on channels as a core concurrency primitive. Channels still exist as a library in stdlib, but they're infinitely buffered by default, and aren't widely used.
masklinn 3y ago
> Complete with general GC, green threading etc. AFAIK there was never "general GC". There was a GC'd smart pointer (@), and its implementation never got beyond refcounting, it was moved behind a feature gate (and a later-removed Gc library type) in 0.9 and removed in 0.10. Ur-Rust was closer to an "applications" language for sure, and thus closer to Go's (possibly by virtue of being closer to OCaml), but it was always focused much more strongly on type safety and lifting constraints to types, as well as more interested in low-level concerns: unique pointers (~) and move semantics (if in a different form) were part of Rust 0.1. That is what the community glommed onto, leading to "the pivot": there were applications language aplenty, but there was a real hunger for a type-heavy and memory-safe low level / systems programming language, and Rust had the bones of it.
- tialaramex 3y ago
  > a real hunger for a type-heavy and memory-safe low level / systems programming language, and Rust had the bones of it. I didn't know I wanted this, but yes, I did want this and when I got it I was much more enthusiastic than I'd ever been about languages like Python or Java. I bounced off Go, it's not bad but it didn't do anything I cared about enough to push through all the usual annoyances of a new language, whereas Rust was extremely compelling by the time I looked into it (only a few years ago) and has only improved since.

opportune 3y ago

Seconding this. Go also has some opinionated standard libraries (want to differentiate between header casings in http requests because your clients/downstream services do? Go fuck yourself!) and shies you away from doing hacky, ugly, dangerous things you need in a systems language. It’s absolutely an applications language.

aatd86 3y ago
Headers are case-sensitive?
- jrockway 3y ago
  They aren't, but because you can send Foo-Bar as fOo-BaR on the wire, someone somewhere depends on it. People don't read the specs, they look at the example data, and decide that's how their program works now. Postel's Law allows this. A different law might say "if anything is invalid or weird, reject it instantly" and there would be a lot less security bugs. But we also wouldn't have TCP or HTTP.
- akoboldfrying 3y ago
  No, and that wasn't the claim being made. The claim being made was that there can be engineering value in preserving the case of existing headers. Example: An HTTP proxy that preserves the case of HTTP headers is going to cause less breakage than one that changes them. In a perfect world, it would make no difference, but that isn't the world we live in.
  - aatd86 3y ago
    Are you sure they are discarded and unrecoverable? Can't that be simply recovered by using textproto.MIMEHeader and iterating over the header map? Seems that it could be a middleware away, I don't see the big deal if so.
    - akoboldfrying 3y ago
      You may well be right -- I don't know Go at all, and just assumed the parent post's claim is true.

ysofunny 3y ago

let's just pretend that when go lang people say "systems programing" they mean smething closer to "network (systems) programming" which is where go shines the brightest

kernal 3y ago
And yet Google replaced the go based network stack in Fuchsia with rust for performance reasons.
- howenterprisey 3y ago
  I understand ysofunny's comment to have meant basically microservices/contemporary web backend.
- pjmlp 3y ago
  After the guy responsible for it left the team.
  - ikiris 3y ago
    This sounds more like for perf reasons that for performance reasons.
- kramerger 3y ago
  Hold on a minute. You are confusing the network stack (as in OS development) and network applications. Go is the undisputed king of backend, but no reasonable person has ever claimed its a good choice for OS development.

veqq 3y ago

> runtime ... GC ... not viable as systems programming language A GC can work fine. At the lower levels, people want to save every flop, but at the higher levels uncounted millions are wasted by JS, Electron apps etc. etc. We can sacrifice a little on the bottom (in the kernel) for great comfort, without a difference. But you don't even have to make sacrifices. A high performance kernel only needs to allocate at startup, without freeing memory, allowing you to e.g. skip GC completely (turn it off with a compiler flag). This does require the kernel to implement specific optimizations though, which aren't typically party to a language spec. Anyway, some OS implemented with a GC: Oberon/Bluebottle (the Oberon language was designed specifically to implement the Oberon OS), JavaOS, JX, JNode, Smalltalk (was the OS for the first Smalltalk systems), Lisp in old Lisp machines... Interval Research even worked on a real time OS written in Smalltalk. Indeed, GC can work in hard real time systems e.g. the Aonix PERC Ultra, embedded real time Java for missile control (but Go's current runtime' GC stops are unpredictable....) Particularly when we consider modern hardware problems (basic OS research already basically stopped in the 90s, yay risc processor design...), with minimal hardware support for high speed context switching because of processor speed vs. memory access latency... Well, it's not like we can utilize such minuscule operations anyway. Why don't we just have sensible processors which don't encourage us to unroll loops, which have die space to store context... There were Java processors [2] which implement the JVM in hardware, with Java bytecode as machine code. Before llvm gained dominance, there were processors optimized to many languages (even Forths!) David Chisnell, a RTOS and FreeBSD contributor recently went into quite a bit of depth [1] ending with: > everything that isn’t an allocator, a context-switch routine, or an ISR, can be written in a fully type-safe GC’d language [1] https://lobste.rs/s/e6tz0r/memory_safety_is_red_herring#c_gf5fyy https://lobste.rs/s/e6tz0r/memory_safety_is_red_herring#c_gf... [2] https://www.electronicdesign.com/technologies/embedded/article/21772568/java-processors https://www.electronicdesign.com/technologies/embedded/artic...

davedx 3y ago
The nice thing about Java is you can choose which GC to use
- pjmlp 3y ago

AnimalMuppet 3y ago

For people of Pike's generation, "systems programming" means, roughly, the OS plus the utilities that would come with an OS. Well, Go may not be useful for writing the OS, but for the OS-level utilities, it works just fine.

jayd16 3y ago
Has it found success in OS-level utilities? What popular utilities are written in Go?
- pjmlp 3y ago
  Being self hosted? Gokrazy userspace? gVisor?
- ziotom78 3y ago
  Not sure these are really popular, but I cannot resist advertising a few utilities written in Go that I regularly use in my daily workflow: - gdu: a NCDU clone, much faster on SSD mounts [1] - duf: a `df` clone with a nicer interface [2] - massren: a `vidir` clone (simpler to use but with fewer options) [3] - gotop: a `top` clone [4] - micro: a nice TUI editor [5] Building this kind of tools in Go makes sense, as the executables are statically compiled and are thus easy to install on remote servers. [1]: https://github.com/dundee/gdu https://github.com/dundee/gdu [2]: https://github.com/muesli/duf https://github.com/muesli/duf [3]: https://github.com/laurent22/massren https://github.com/laurent22/massren [4]: https://github.com/xxxserxxx/gotop https://github.com/xxxserxxx/gotop [5]: https://github.com/zyedidia/micro https://github.com/zyedidia/micro
- konart 3y ago
  Not sure what should be counted as OS-level. Is docker cli and OS level? What about lazygit? chezmoi? dive? fzf? Actually many popular utilities are written in Go
- nolist_policy 3y ago
  Docker and Podman.

kazinator 3y ago

The shells scripts that bring up a machine are also "systems programming".

0xpgm 3y ago

Maybe the better term for go would be server-systems programming.

bborud 3y ago
Server programming? The term "systems programming" seems to be interpreted very differently by different people which in practice renders it useless. It is probably best to not use it at all to avoid confusion.

pjmlp 3y ago

Niklaus Wirth, rest his soul, would disagree. Like would the folks at WithSecure, selling the USB Armory with Go written firmware. https://www.withsecure.com/en/solutions/innovative-security-hardware/usb-armory https://www.withsecure.com/en/solutions/innovative-security-... Back in my day, writing compilers and OS services were also systems programming.

Matl 3y ago

"systems" can mean "distributed systems", "network systems" etc. both of which Go is suitable for. It's obviously not a great choice for "operating systems" which is well known.

jgtgiuhhvvf 3y ago
[flagged]

yencabulator 3y ago

I'll just leave this here (emphasis mine) https://en.wikipedia.org/wiki/Systems_programming https://en.wikipedia.org/wiki/Systems_programming > The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software which provides services to the user directly (e.g. word processor), whereas systems programming aims to produce software and software platforms which *provide services to other software*, are performance constrained, or both (e.g. operating systems, computational science applications, game engines, industrial automation, and software as a service applications).