4 ms·

It seems he wanted a static type system, for starters.

rubiquity 12y ago
There's a running joke in the Erlang community that every Erlang programmer will at some point try and re-implement Supervisors and do it horribly wrong. This isn't because the person is a bad programmer, it's just easy to underestimate the amount of time and incredible programming that has gone into Erlang's supervisors. By sticking with Go, the author gets to keep the static types but likely gets faux-Supervisors at best.
- jerf 12y ago
  I describe exactly what I get. Whether they're "faux" depends on your definition. No, seriously, that's really profoundly true. Erlang's definition isn't the only one. But you're free to take it. If you can bend a bit, though, these may not be "faux". One thing that's easier when it comes to implementing supervisors in not-Erlang though is that the vast majority of languages have something better than "behaviors" to work with, which are bizarrely klunky things. I actually implemented something more like a "gen_server" initially, but it wasn't a win. Some of that "incredible programming" is essential complexity (in Fred Brooks' terminology), but some of it is accidental complexity. Plus Erlang had to build it from true, total scratch; Go is a pre-existing runtime, and "defer" is simple, yet powerful.
  - rvirding 12y ago
    Did you try to implement your own behaviours? Or processes that aren't behaviours as such but still function correctly in supervision trees and in applications?
    - jerf 12y ago
      What I found is that if you implement Serve() and Stop(), honestly, you're done, in the world of Go. If you want a state machine, just write it. Many of the things I'm supervising are goroutines that wrap an API around a channel that implements a server.
polskibus 12y ago
While not exactly static typing, you can add type annotations in Erlang and use dialyzer as a step in compilation to catch typing bugs.
- tel 12y ago
  It's exactly static typing, just a very loose system which allows a lot of holes.
- jerf 12y ago
  In the spirit of rubiquity's post, I'll take a faux supervisor tree and static typing over a "real" supervisor tree (sorry, gotta scare quote it) and faux static typing. It should be pointed out specifically that Erlang's type system is incredibly, annoyingly weak, more so than merely "weak typing". It's a language that doesn't permit any sort of user-created type whatsoever. There are good reasons for this which would be its own interesting blog post, mostly related to the need for a clear serialization for cluster communication, but I think those good reasons have been superceded by later work in the general programming world on serialization of objects and the tradeoff is wrong in 2014. (But, no sarcasm, a good one when it was created. It is no real criticism of a language to observe that it couldn't use lessons learned only a decade after it was created.)
  - dragonwriter 12y ago
    > It's a language that doesn't permit any sort of user-created object whatsoever. I think you are misusing "object" to mean something like "class" or "type" (the two not really being the same thing except in some statically-typed, class-based, OOPLs); Erlang quite obviously allows user-created objects.
    - jerf 12y ago
      Yes, it should be "type". I've edited it, so let the record show that I did say that at first. And of course you can use what exists to build "types", such as a dict. But it's still just a record of a certain format rather than a distinct "type"; there's no way in the core system to assert that you have such a "dict", beyond having a record.

There's a running joke in the Erlang community that every Erlang programmer will at some point try and re-implement Supervisors and do it horribly wrong. This isn't because the person is a bad programmer, it's just easy to underestimate the amount of time and incredible programming that has gone into Erlang's supervisors. By sticking with Go, the author gets to keep the static types but likely gets faux-Supervisors at best.

jerf 12y ago
I describe exactly what I get. Whether they're "faux" depends on your definition. No, seriously, that's really profoundly true. Erlang's definition isn't the only one. But you're free to take it. If you can bend a bit, though, these may not be "faux". One thing that's easier when it comes to implementing supervisors in not-Erlang though is that the vast majority of languages have something better than "behaviors" to work with, which are bizarrely klunky things. I actually implemented something more like a "gen_server" initially, but it wasn't a win. Some of that "incredible programming" is essential complexity (in Fred Brooks' terminology), but some of it is accidental complexity. Plus Erlang had to build it from true, total scratch; Go is a pre-existing runtime, and "defer" is simple, yet powerful.
- rvirding 12y ago
  Did you try to implement your own behaviours? Or processes that aren't behaviours as such but still function correctly in supervision trees and in applications?
  - jerf 12y ago
    What I found is that if you implement Serve() and Stop(), honestly, you're done, in the world of Go. If you want a state machine, just write it. Many of the things I'm supervising are goroutines that wrap an API around a channel that implements a server.

polskibus 12y ago

While not exactly static typing, you can add type annotations in Erlang and use dialyzer as a step in compilation to catch typing bugs.

tel 12y ago
It's exactly static typing, just a very loose system which allows a lot of holes.
jerf 12y ago
In the spirit of rubiquity's post, I'll take a faux supervisor tree and static typing over a "real" supervisor tree (sorry, gotta scare quote it) and faux static typing. It should be pointed out specifically that Erlang's type system is incredibly, annoyingly weak, more so than merely "weak typing". It's a language that doesn't permit any sort of user-created type whatsoever. There are good reasons for this which would be its own interesting blog post, mostly related to the need for a clear serialization for cluster communication, but I think those good reasons have been superceded by later work in the general programming world on serialization of objects and the tradeoff is wrong in 2014. (But, no sarcasm, a good one when it was created. It is no real criticism of a language to observe that it couldn't use lessons learned only a decade after it was created.)
- dragonwriter 12y ago
  > It's a language that doesn't permit any sort of user-created object whatsoever. I think you are misusing "object" to mean something like "class" or "type" (the two not really being the same thing except in some statically-typed, class-based, OOPLs); Erlang quite obviously allows user-created objects.
  - jerf 12y ago
    Yes, it should be "type". I've edited it, so let the record show that I did say that at first. And of course you can use what exists to build "types", such as a dict. But it's still just a record of a certain format rather than a distinct "type"; there's no way in the core system to assert that you have such a "dict", beyond having a record.