13 ms·

I don't know why the author bothered to even respond to that Medium article. The Medium article starts with that Go shines as a systems programming language. He

by cft 9y ago

I don't know why the author bothered to even respond to that Medium article. The Medium article starts with that Go shines as a systems programming language. He lost me right there: how can a language with a garbage collector and a runtime be called a "systems programming language"?

pjmlp 9y ago
Since Xerox PARC, UK Royal Navy, DEC, HP Labs, ETHZ, Microsoft Research have implemented full stack OSes in GC enabled systems programming languages. At ETHZ Oberon workstations were used during a couple of years by several users across the department. Most of those attempts failed due to losing the political and financial wars of bringing them into the wider market, not because of lack of features.
- cft 9y ago
  very interesting. I would have thought that any practical kernel written in a language with a GC would either have unpredictable slowdowns or be exceedingly complex.
  - pjmlp 9y ago
    Blue Bottle OS, the last Oberon OS iteration done with Active Oberon had a video player as part of the standard set of applications. Just because there is a GC doesn’t mean it is the only way to allocate memory.
  - jstewartmobile 9y ago
    We already sacrifice some silicon for TLBs and other memory management features. Many older architectures sacrificed bits for tag information as well. Perhaps one day we will sacrifice a little more silicon to get performant hardware-assisted GC? Or not.
    - pjmlp 9y ago
      That is one area RISC-V guys are looking into, with Jikes RVM. "Grail Quest: A New Proposal for HW-Assisted Garbage Collection" (PDF) https://people.eecs.berkeley.edu/~maas/papers/maas-asbd16-hwgc.pdf https://people.eecs.berkeley.edu/~maas/papers/maas-asbd16-hw... Also Intel did have hardware GC with i432, but the chip suffered from many design errors that made it quite slow.
  - _ph_ 9y ago
    I don't think that is a necessity. You can write Go code which doesn't heap-allocate at all - the Go GC is written this way in Go. In any case, you would have very little heap allocations in the kernel space and the GC should be well integrated with the kernel operations.
- AnimalMuppet 9y ago
  > At ETHZ Oberon workstations were used during a couple of years by several users across the department. The way you say that, it sounds pretty unimpressive. Say, 2 years and 10 users, plus or minus one order of magnitude. That's not enough to tell anything. Was it going to be portable to other hardware? Was it going to be maintainable? Was it going to be comparable in performance? The answers are all "no data". The only thing you can say is that it could be successfully written and gotten to work, for a definition of "work" that allowed a few people to use it for a little while. > Most of those attempts failed due to losing the political and financial wars of bringing them into the wider market, not because of lack of features. Well... I wasn't there, but I took a look at the Wikipedia page (yeah, I know) giving the chronology of the Oberon OS, and it's quite unimpressive. For four years, it had "only simple text editing facilities". Those four years ended in 1991. That sounds very much like "lack of features" to me. In particular, the competition was either DOS, Mac, or a Unix workstation. That feature set would not lead anyone to want to choose Oberon. Now, I know, there were only a couple of people working on it part time. But all this really proves is that they were able to write an OS and get a text editor running on it. That's proof of concept, I suppose, but there's a huge difference between an OS like that and an OS you can "bring into the wider market". I think you're idolizing a past that wasn't all that hot at the time...
  - pjmlp 9y ago
    Native Oberon was the very first version, then there was EthOS, and Oberon System 3 with the graphical Gadgets framework. In the meantime a new version of Oberon was re-done with Oberon-2, whose method declarations influenced how Go method declarations are done. By this time there was a spin into a Swiss startup that designed Component Pascal, an Oberon-2 derivative, with a RAD development environment targeted mostly at Mac OS and Windows users. The researchers at ETHZ created Blue Bottle OS, also known as A2, using Active Oberon. Yet another Oberon evolution, that had support for co-routines in async/await style, and probably one of the first environments with a multi-threaded compiler. It was good enough to support applications like video playing, BeOS wasn't the only one doing it in the mid-90's. If you want pictures, there are plenty of them here, https://goo.gl/Rce7A2 https://goo.gl/Rce7A2 Oberon was used until early 2000s to teach systems programming at ETHZ, and many department computers used them as their main workstations. Including file servers implemented in Oberon for distributing work across workstations, and an early version of applets concept called Juice. ftp://ftp.cis.upenn.edu/pub/cis700/public_html/papers/Franz97b.pdf Graz University had their own variant of Oberon, with Hanspeter Mössenböck leading some of the development efforts. This same department is nowadays heavily involved with Graal research together with Oracle Labs. http://www.ssw.uni-linz.ac.at/General/Staff/HM/Publications/index.html http://www.ssw.uni-linz.ac.at/General/Staff/HM/Publications/... http://ssw.jku.at/Research/Projects/JVM/Graal.html http://ssw.jku.at/Research/Projects/JVM/Graal.html The Ulm university in Germany also implemented their own Oberon variant, including native versions running on top of several UNIXes and Windows. Mostly broken links nowadays, http://www.mathematik.uni-ulm.de/oberon/ulm.html http://www.mathematik.uni-ulm.de/oberon/ulm.html Niklaus Wirth later in 2013 redid the original Project Oberon, with an updated variant named Oberon-07 and targeting an FPGA instead. http://www.projectoberon.com/ http://www.projectoberon.com/ So no, I am not idolizing a past and there was a little more there than just a plain text editor. Sometimes the Wikipedia is not the best source.
sidlls 9y ago
"systems programming language" doesn't start and stop with bit twiddling one step removed from assembler. There's a huge fuzzy region between that extreme and "application programming as a semi-skilled trade", and go seems to fill certain "systems programming" needs adequately as far as that goes.
- cft 9y ago
  Languages like C and Rust are true system programming languages, and they are not one step removed from assembler. Rust has a very complex compiler. Go is a low level applications programming language.
  - sagichmal 9y ago
    This pedantic terminology fight about what constitutes a “systems” language hasn’t been worth having since 2009, when all of these arguments were already aired and resolved. Please find another hill to die on.
    - BuckRogers 9y ago
      He is correct though, at least from the perspective of Go's own designers? Wasn't "systems language" removed from the description at some point. I've listened to interviews with Rob Pike who even outright said they got the messaging wrong there. I think it's pretty well accepted that no systems language has GC. Go is on the same abstraction layer as Java/C#. Everything in text can be taken as a slight, and to ensure that doesn't read that way, I am a believer in targeting that level of abstraction most of the time. I think it's the sweet spot. I'm not a fan of the dual language approach targeting high (Python) and low (C). Java or C# makes more sense to me, for most software. That's my opinion. If I needed more than what those heavy hitters provide, I'd just go all the way and reach for Rust myself. So I don't necessary see the parent comment from ctf as combative. I think he's just seeking accuracy.
      - sidlls 9y ago
        Java has been used as the implementation language for games, high performance servers, message queuing systems, operating systems, and operating embedded devices for goodness sake. It doesn't get much more "systems-y" than that. Go is surely at least as suitable for these uses. I think the other commenter is correct: it seems like a semantics argument, and a rather pointless one at that.
paxys 9y ago
Go's "runtime" is just a library. Programs are still compiled to native machine code.
- cft 9y ago
  I think you are confusing the language runtime with the Go "runtime" package that provides an API to the Go runtime. Golang runtime is basically a program, that is running whenever your Go application is running. As a programmer, you do not have full control over the language runtime. It runs things like garbage collection, and serializes/deserializes data in the channels. True system languages like C do not have a runtime. Rust has a primitive automatic memory allocator/deallocator (not a garbage collector!), but I would not call it a full fledged runtime.
  - paxys 9y ago
    By that definition every language has a runtime (yes, including C with crt0.o). Something has to set up the stack, enter the main() function etc. So how do you differentiate a systems language runtime? One that is bundled with the OS? Or is thin enough by some arbitrary measure?
    - cft 9y ago
      In Go you cannot fully control the runtime as a programmer- Go's GC is a complicated periodically run program with sometimes surprising behavior. crt0.o is a very simple set of startup routines with a fixed and predictable behavior. It is typically run only once ("0" in the name is for startup), and has only a couple of assembly instructions.
      - pjmlp 9y ago
        C runtime does much more than that, depending how floating point is supported, language extensions for constructors on execution start, threading runtime introduced in C11.
    - steveklabnik 9y ago

by cft 9y ago

pjmlp 9y ago

Since Xerox PARC, UK Royal Navy, DEC, HP Labs, ETHZ, Microsoft Research have implemented full stack OSes in GC enabled systems programming languages. At ETHZ Oberon workstations were used during a couple of years by several users across the department. Most of those attempts failed due to losing the political and financial wars of bringing them into the wider market, not because of lack of features.

cft 9y ago
very interesting. I would have thought that any practical kernel written in a language with a GC would either have unpredictable slowdowns or be exceedingly complex.
- pjmlp 9y ago
  Blue Bottle OS, the last Oberon OS iteration done with Active Oberon had a video player as part of the standard set of applications. Just because there is a GC doesn’t mean it is the only way to allocate memory.
- jstewartmobile 9y ago
  We already sacrifice some silicon for TLBs and other memory management features. Many older architectures sacrificed bits for tag information as well. Perhaps one day we will sacrifice a little more silicon to get performant hardware-assisted GC? Or not.
  - pjmlp 9y ago
    That is one area RISC-V guys are looking into, with Jikes RVM. "Grail Quest: A New Proposal for HW-Assisted Garbage Collection" (PDF) https://people.eecs.berkeley.edu/~maas/papers/maas-asbd16-hwgc.pdf https://people.eecs.berkeley.edu/~maas/papers/maas-asbd16-hw... Also Intel did have hardware GC with i432, but the chip suffered from many design errors that made it quite slow.
- _ph_ 9y ago
  I don't think that is a necessity. You can write Go code which doesn't heap-allocate at all - the Go GC is written this way in Go. In any case, you would have very little heap allocations in the kernel space and the GC should be well integrated with the kernel operations.
AnimalMuppet 9y ago
> At ETHZ Oberon workstations were used during a couple of years by several users across the department. The way you say that, it sounds pretty unimpressive. Say, 2 years and 10 users, plus or minus one order of magnitude. That's not enough to tell anything. Was it going to be portable to other hardware? Was it going to be maintainable? Was it going to be comparable in performance? The answers are all "no data". The only thing you can say is that it could be successfully written and gotten to work, for a definition of "work" that allowed a few people to use it for a little while. > Most of those attempts failed due to losing the political and financial wars of bringing them into the wider market, not because of lack of features. Well... I wasn't there, but I took a look at the Wikipedia page (yeah, I know) giving the chronology of the Oberon OS, and it's quite unimpressive. For four years, it had "only simple text editing facilities". Those four years ended in 1991. That sounds very much like "lack of features" to me. In particular, the competition was either DOS, Mac, or a Unix workstation. That feature set would not lead anyone to want to choose Oberon. Now, I know, there were only a couple of people working on it part time. But all this really proves is that they were able to write an OS and get a text editor running on it. That's proof of concept, I suppose, but there's a huge difference between an OS like that and an OS you can "bring into the wider market". I think you're idolizing a past that wasn't all that hot at the time...
- pjmlp 9y ago
  Native Oberon was the very first version, then there was EthOS, and Oberon System 3 with the graphical Gadgets framework. In the meantime a new version of Oberon was re-done with Oberon-2, whose method declarations influenced how Go method declarations are done. By this time there was a spin into a Swiss startup that designed Component Pascal, an Oberon-2 derivative, with a RAD development environment targeted mostly at Mac OS and Windows users. The researchers at ETHZ created Blue Bottle OS, also known as A2, using Active Oberon. Yet another Oberon evolution, that had support for co-routines in async/await style, and probably one of the first environments with a multi-threaded compiler. It was good enough to support applications like video playing, BeOS wasn't the only one doing it in the mid-90's. If you want pictures, there are plenty of them here, https://goo.gl/Rce7A2 https://goo.gl/Rce7A2 Oberon was used until early 2000s to teach systems programming at ETHZ, and many department computers used them as their main workstations. Including file servers implemented in Oberon for distributing work across workstations, and an early version of applets concept called Juice. ftp://ftp.cis.upenn.edu/pub/cis700/public_html/papers/Franz97b.pdf Graz University had their own variant of Oberon, with Hanspeter Mössenböck leading some of the development efforts. This same department is nowadays heavily involved with Graal research together with Oracle Labs. http://www.ssw.uni-linz.ac.at/General/Staff/HM/Publications/index.html http://www.ssw.uni-linz.ac.at/General/Staff/HM/Publications/... http://ssw.jku.at/Research/Projects/JVM/Graal.html http://ssw.jku.at/Research/Projects/JVM/Graal.html The Ulm university in Germany also implemented their own Oberon variant, including native versions running on top of several UNIXes and Windows. Mostly broken links nowadays, http://www.mathematik.uni-ulm.de/oberon/ulm.html http://www.mathematik.uni-ulm.de/oberon/ulm.html Niklaus Wirth later in 2013 redid the original Project Oberon, with an updated variant named Oberon-07 and targeting an FPGA instead. http://www.projectoberon.com/ http://www.projectoberon.com/ So no, I am not idolizing a past and there was a little more there than just a plain text editor. Sometimes the Wikipedia is not the best source.

sidlls 9y ago

"systems programming language" doesn't start and stop with bit twiddling one step removed from assembler. There's a huge fuzzy region between that extreme and "application programming as a semi-skilled trade", and go seems to fill certain "systems programming" needs adequately as far as that goes.

cft 9y ago
Languages like C and Rust are true system programming languages, and they are not one step removed from assembler. Rust has a very complex compiler. Go is a low level applications programming language.
- sagichmal 9y ago
  This pedantic terminology fight about what constitutes a “systems” language hasn’t been worth having since 2009, when all of these arguments were already aired and resolved. Please find another hill to die on.
  - BuckRogers 9y ago
    He is correct though, at least from the perspective of Go's own designers? Wasn't "systems language" removed from the description at some point. I've listened to interviews with Rob Pike who even outright said they got the messaging wrong there. I think it's pretty well accepted that no systems language has GC. Go is on the same abstraction layer as Java/C#. Everything in text can be taken as a slight, and to ensure that doesn't read that way, I am a believer in targeting that level of abstraction most of the time. I think it's the sweet spot. I'm not a fan of the dual language approach targeting high (Python) and low (C). Java or C# makes more sense to me, for most software. That's my opinion. If I needed more than what those heavy hitters provide, I'd just go all the way and reach for Rust myself. So I don't necessary see the parent comment from ctf as combative. I think he's just seeking accuracy.
    - sidlls 9y ago
      Java has been used as the implementation language for games, high performance servers, message queuing systems, operating systems, and operating embedded devices for goodness sake. It doesn't get much more "systems-y" than that. Go is surely at least as suitable for these uses. I think the other commenter is correct: it seems like a semantics argument, and a rather pointless one at that.

paxys 9y ago

Go's "runtime" is just a library. Programs are still compiled to native machine code.

cft 9y ago
I think you are confusing the language runtime with the Go "runtime" package that provides an API to the Go runtime. Golang runtime is basically a program, that is running whenever your Go application is running. As a programmer, you do not have full control over the language runtime. It runs things like garbage collection, and serializes/deserializes data in the channels. True system languages like C do not have a runtime. Rust has a primitive automatic memory allocator/deallocator (not a garbage collector!), but I would not call it a full fledged runtime.
- paxys 9y ago
  By that definition every language has a runtime (yes, including C with crt0.o). Something has to set up the stack, enter the main() function etc. So how do you differentiate a systems language runtime? One that is bundled with the OS? Or is thin enough by some arbitrary measure?
  - cft 9y ago
    In Go you cannot fully control the runtime as a programmer- Go's GC is a complicated periodically run program with sometimes surprising behavior. crt0.o is a very simple set of startup routines with a fixed and predictable behavior. It is typically run only once ("0" in the name is for startup), and has only a couple of assembly instructions.
    - pjmlp 9y ago
      C runtime does much more than that, depending how floating point is supported, language extensions for constructors on execution start, threading runtime introduced in C11.
  - steveklabnik 9y ago