5 ms·

Golang is the modern Oberon.

by Sin2x 4y ago

deleted 4y ago
[deleted]
vitiral 4y ago
Golang is not an OS. Golang doesn't fit in 12kib of source code. I could go on.
- pjmlp 4y ago
  Depends on what extent an unikernel is an OS. https://www.withsecure.com/en/solutions/innovative-security-hardware/usb-armory https://www.withsecure.com/en/solutions/innovative-security-... Go has all the same features as Oberon has, in regards to systems programming, it is a matter of anyone finding it worthwhile to actually design a graphical OS with it. I will conceed it lacks a very important one from Oberon, proper dynamic loading. Also the plugin packages are mostly abandoned across several releases. However in this day and age, probably it would make more sense to do the dynamic loading capabilities of Oberon commands available via OS IPC instead.
  - Rochus 4y ago
    > Go has all the same features as Oberon has Go is missing both two new features Wirth introduced in Oberon compared to Modula (see section 5.2 of the referenced HOPL paper): type extension (i.e. inheritance) and type inclusion (no implicit coercion in Golang at all). Taking a closer look there are only few similarities between Oberon and Go; both are garbage collected; Go uses the same separate receiver syntax element in method declarations as Oberon-2; and there is an intersection of keywords and also := appears, but the semantics are rather different.
    - pjmlp 4y ago
      You get similar workflows via interfaces, delegation and now generics to help reduce the boilerplate. COM has done just great during the last 30 years without class inheritance.
      - Rochus 4y ago
        I didn't say that the "Go way" was bad; just that there are few similarities. Certain things you can do in Oberon you cannot do in Go and vice versa. Personally I prefer Oberon+ over both Go and previous Oberons; if I didn't need to maintain backward compatibility with Oberon/-2/-07 I would remove type inclusion from Oberon+ and require explicit casts like Go; Wirth also removed type inclusion from Oberon-07, but he (unfortunately) also removed all numeric types but INTEGER, REAL and BYTE (but left some unfortunate implicit casts).
        pjmlp 4y ago
        From that point of view yes, I do agree. Although I still think Active Oberon is the best descendant from original Oberon, I am not a fan of the minimalist design Wirth persued afterwards. In any case, Oberon's best days are behind it, hence why I would rather see some Go inspired approach to those ideas, even if I am not a big fan of Go's design.
        Rochus 4y ago
        > In any case, Oberon's best days are behind it Maybe if you insist that parallel processing is part of the language (which you likely do if you prefer Active Oberon). Personally I think this can be well delegated to libraries to keep the language simple. Oberon+ doesn't use dedicated syntax even for exception handling; also "green" or regular threads, and channels and the like can well be covered by libraries or FFI. I'm neither a fan of Go's design, but with the ongoing work on Oberon+ I'm confident that its best days are yet to come.
        pjmlp 4y ago
        The whole point of Oberon was the Smalltalk like experience, or to be more precise Mesa/Cedar like experience. So to offer a bare bones language in 2022 without an OS that is at least at the same level of Blue Bottle, let alone what consumers expect from a modern OS is really not attainable. It remains a nice language to look at as language nerd, and at the end of the day, pick something else when delivering software into production with the expectations that Swift, C#, Kotlin and so on can fulfill.
- Sin2x 4y ago
  Oberon language and Oberon OS are two distinct entities and given the context of this post it's obvious that I was talking about Oberon the language. Whether you like Go or not, it's the closest modern production language to Oberon and derived very much from it, so my point stands.
  - vitiral 4y ago
    Ah, you're speaking of just the language. I've actually read a bit of the Oberon book and had no idea Golang was inspired by it. Good to know, since I consider both an inspiration for my own projects!
timbit42 4y ago
Golang is the admission by the creators of B, C, Unix, and Plan-9, that Wirth was right.
- Rochus 4y ago
  This is a rather bold claim given that the most obvious influence was the method syntax of Oberon-2 (designed by H.P. Mössenböck, the PhD supervisor of R. Griesemer), and besides that there are only some superficial similarities between Oberon and Go. See https://news.ycombinator.com/item?id=32303837 https://news.ycombinator.com/item?id=32303837.
  - deleted 4y ago
    [deleted]
swamiji 4y ago
Yes, I believe Robert Griesemer one of the three brains behind Golang is Wirths student.

Golang is the modern Oberon.

by Sin2x 4y ago

Golang is the modern Oberon.

deleted 4y ago

[deleted]

vitiral 4y ago

Golang is not an OS. Golang doesn't fit in 12kib of source code. I could go on.

pjmlp 4y ago
Depends on what extent an unikernel is an OS. https://www.withsecure.com/en/solutions/innovative-security-hardware/usb-armory https://www.withsecure.com/en/solutions/innovative-security-... Go has all the same features as Oberon has, in regards to systems programming, it is a matter of anyone finding it worthwhile to actually design a graphical OS with it. I will conceed it lacks a very important one from Oberon, proper dynamic loading. Also the plugin packages are mostly abandoned across several releases. However in this day and age, probably it would make more sense to do the dynamic loading capabilities of Oberon commands available via OS IPC instead.
- Rochus 4y ago
  > Go has all the same features as Oberon has Go is missing both two new features Wirth introduced in Oberon compared to Modula (see section 5.2 of the referenced HOPL paper): type extension (i.e. inheritance) and type inclusion (no implicit coercion in Golang at all). Taking a closer look there are only few similarities between Oberon and Go; both are garbage collected; Go uses the same separate receiver syntax element in method declarations as Oberon-2; and there is an intersection of keywords and also := appears, but the semantics are rather different.
  - pjmlp 4y ago
    You get similar workflows via interfaces, delegation and now generics to help reduce the boilerplate. COM has done just great during the last 30 years without class inheritance.
    - Rochus 4y ago
      I didn't say that the "Go way" was bad; just that there are few similarities. Certain things you can do in Oberon you cannot do in Go and vice versa. Personally I prefer Oberon+ over both Go and previous Oberons; if I didn't need to maintain backward compatibility with Oberon/-2/-07 I would remove type inclusion from Oberon+ and require explicit casts like Go; Wirth also removed type inclusion from Oberon-07, but he (unfortunately) also removed all numeric types but INTEGER, REAL and BYTE (but left some unfortunate implicit casts).
      - pjmlp 4y ago
        From that point of view yes, I do agree. Although I still think Active Oberon is the best descendant from original Oberon, I am not a fan of the minimalist design Wirth persued afterwards. In any case, Oberon's best days are behind it, hence why I would rather see some Go inspired approach to those ideas, even if I am not a big fan of Go's design.
        Rochus 4y ago
        > In any case, Oberon's best days are behind it Maybe if you insist that parallel processing is part of the language (which you likely do if you prefer Active Oberon). Personally I think this can be well delegated to libraries to keep the language simple. Oberon+ doesn't use dedicated syntax even for exception handling; also "green" or regular threads, and channels and the like can well be covered by libraries or FFI. I'm neither a fan of Go's design, but with the ongoing work on Oberon+ I'm confident that its best days are yet to come.
        pjmlp 4y ago
        The whole point of Oberon was the Smalltalk like experience, or to be more precise Mesa/Cedar like experience. So to offer a bare bones language in 2022 without an OS that is at least at the same level of Blue Bottle, let alone what consumers expect from a modern OS is really not attainable. It remains a nice language to look at as language nerd, and at the end of the day, pick something else when delivering software into production with the expectations that Swift, C#, Kotlin and so on can fulfill.
Sin2x 4y ago
Oberon language and Oberon OS are two distinct entities and given the context of this post it's obvious that I was talking about Oberon the language. Whether you like Go or not, it's the closest modern production language to Oberon and derived very much from it, so my point stands.
- vitiral 4y ago
  Ah, you're speaking of just the language. I've actually read a bit of the Oberon book and had no idea Golang was inspired by it. Good to know, since I consider both an inspiration for my own projects!

timbit42 4y ago

Golang is the admission by the creators of B, C, Unix, and Plan-9, that Wirth was right.

Rochus 4y ago
This is a rather bold claim given that the most obvious influence was the method syntax of Oberon-2 (designed by H.P. Mössenböck, the PhD supervisor of R. Griesemer), and besides that there are only some superficial similarities between Oberon and Go. See https://news.ycombinator.com/item?id=32303837 https://news.ycombinator.com/item?id=32303837.
- deleted 4y ago
  [deleted]

swamiji 4y ago

Yes, I believe Robert Griesemer one of the three brains behind Golang is Wirths student.