6 ms·

IMO Plan 9 didn't gain critical mass because Unix is still "good enough". It's also very difficult to keep current with hardware drivers for a niche OS. Howev

by jbarham 16y ago

IMO Plan 9 didn't gain critical mass because Unix is still "good enough". It's also very difficult to keep current with hardware drivers for a niche OS. However, there are some things that came from Plan 9 that are very much mainstream, the most notable being UTF-8 which was invented by Ken Thompson and first implemented on Plan 9. Linux's clone(2) system call is obviously inspired by Plan 9's rfork. And one could argue that the Go language is a spin-off of Plan 9 as it's substantially implemented by Plan 9 refugees to Google (Ken Thompson, Rob Pike, Russ Cox) and is explicitly descended from other languages that came out of Bell Labs (Newsqueak, Alef, Limbo). Of course whether Go will be a success is an open question, but I think its chances are as good as any other equivalent language.

TallGuyShort 16y ago
Speaking of Plan 9 and Go, I have to ask the same question: why isn't Go more popular?
- alnayyir 16y ago
  Not substantially performant for use in systems programming. Not substantially powerful or enough libraries for use in web dev (yet, this could change). Global GC (inappropriate for the niche it's ostensibly targeting). Overly opinionated about concurrency. (C++ and Java are the gold-standard for library-centric concurrency methodologies) Go sits in an uncanny valley.
  - jbarham 16y ago
    > C++ and Java are the gold-standard for library-centric concurrency methodologies The last time I checked concurrency isn't possible with standard C++. And multi-threaded programming in Java has been called many things, but "gold-standard" isn't one of them.
    - alnayyir 16y ago
      >The last time I checked concurrency isn't possible with standard C++ If you don't know, then I can't tell you. People have been doing threading, re-entrant code, libevent/libev in C and C++ for decades. (cf. DragonflyBSD) I didn't say it was trivial, just that it's an industry standard for when you need to get things done (TM).
      - jbarham 16y ago
        It appears you are being intentionally obtuse, so I repeat: Neither the current C and C++ language standards provide any support whatsoever for concurrent programming. Therefore you cannot do concurrent programming in either of those languages without resorting to using operating system specific or 3rd party libraries. DragonflyBSD, a project that was only started in 2003, has obviously not been around for "decades" so hardly serves to advance your claim.
        alnayyir 16y ago
        >Neither the current C and C++ language standards provide any support whatsoever for concurrent programming. They're not supposed to. They're systems programming languages. When you're writing a kernel or embedded software, having the language mandate some kind of concurrency model at the standards level is nonsensical. I wasn't linking decades to DragonflyBSD, I was saying that the techniques and methods have been known and used for decades. The original point, restated here for clarity is this. Go was supposed to be a new-age systems programming language. Its current design (mandated concurrency model and global GC) preclude that from ever happening without fundamental changes. Rust has a better chance of becoming the next systems programming language. I don't know what your niche or corner of the realm of software is, but I get the feeling you're commenting on a field you have no substantial experience in. It's evident to anybody with any real experience or wisdom concerning software that having choices like concurrency made for you at the language-level narrow the scope of usefulness for that particular language and pretty much precludes it from being a top-grade choice for embedded/systems development. Example: Were it not for the glut of hardware performance and memory capacity improvements in smartphones, Dalvik/java would've been impractical at best on Android. It's still a vastly inferior experience compared to the iPhone, which is obj-c with optional drop-down to C/C++. And don't mention the NDK for Android, it's a bad joke. Bootstrapping a runtime for a language that depends on a particular concurrency model irrespective of the problem at hand is stupid beyond my faculty for describing with words. tl;dr good luck using Go for hard real-time systems. Why do you think C++ achieved popularity so quickly? It was pliable to the demands of the problem being solved just like C at the expense of complexity.
    - philwelch 16y ago
      You can use Java's concurrency features to implement better concurrency features (as opposed to the language just giving you better concurrency features from the outset), which is presumably what was meant by "less opinionated" or "library-centric". You can have asynchronous or synchronous message passing or STM on mutable references to immutable data or really anything built on top of Java, but an opinionated language like Go just picks something (synchronous message passing in Go's case) and makes you use it.[1] [1] You can implement asynchronous message passing on top of synchronous message passing, but not the other way around. Presumably the "least opinionated" language would simply give you the concurrency primitive with which you can implement the greatest number of other concurrency primitives, which presumably[2] is locks. [2] I could be wrong about this.
      - alnayyir 16y ago
        I think you're the only one to get my point so far. A lot of the best libraries and concurrency approaches I've implemented in Clojure so far have been imports from Java. (NIO2 being one example)
  - obiterdictum 16y ago
    It's hard to make any judgement of a language that's barely a year old, especially about performance and libraries. All industry standard languages are at least a decade old. > C++ and Java are the gold-standard for library-centric concurrency methodologies. It's a standard, but it is not by any means the gold standard. Just about anything would be a better concurrency model. Also see "Threads Cannot be Implemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html
    - alnayyir 16y ago
      >It's hard to make any judgement of a language that's barely a year old, especially about performance and libraries. All industry standard languages are at least a decade old. It's a product of their design decisions and has nothing at all to do with implementation or time. Look at Rust if you want to see a realistic up-and-coming systems programming language. >It's a standard, but it is not by any means the gold standard. Just about anything would be a better concurrency model. Right, well get back to me when you write that multi-threaded web server in Python.
- zephyrfalcon 16y ago
  It has only been out since November 2009, and it wasn't considered ready for production then. Maybe it is now, but it definitely hasn't had much time to be establish a large user base.
  - mrj 16y ago
    Well... Not so much. I'm playing with it, but apparently it doesn't yet fully run on Windows. I think that'll work for my project, but that would prevent most people from using Go.
  - mhd 16y ago
    Go is in a "public beta" status, i.e. what you see right now is its development, not its refinement. It basically hasn't reached a 1.0 release version yet. Participants of the mailing list are very early adopters who write some libraries for it. It's still likely enough that important parts of the language spec will change in non-compatible ways, and especially the standard library still isn't too stable (e.g. the http module is a bit orphaned right now). But the progress is quite impressive, and it might hit a niche for lots of people (those Zed Shaw tends to call "longbeards"). Unix systems programming is still dominated by C, as there aren't that many valid alternatives. Java is systems programming for the Java system, C++ is C++. Ocaml is probably one step too far for bit pushers. And then there's the pedigree of the developers. I think within a year the language should have matured enough. If someone manages to come up with a "killer application" for it (c.f. RoR/Ruby or node.js/server-side Javascript), it might take off. It might also end up like Modula-3.
    - xiongchiamiov 16y ago
      What about D?
      - mhd 16y ago
        That's a good question. D has been around for quite some time, has some well-known names (Bright, Alexandrescu), but has yet to break big. Compared to it, Go, a much more recent development, tends to do quite well (just my estimates, PL mindshare is a bit hard to measure). I think it's mostly because of some internal and positioning issues. I haven't been following it recently, but I remember some problems with different standard libraries, D 1 vs D 2, and three compilers that each had issues. Maybe that's resolved, but it certainly didn't make things look too good. Also, it seems to be more a successor to C++, which makes some people a bit distrustful. Yes, it's much cleaner, but also quite a bit more complex than C, and not a total programming environment as Java or C#. So it mainly gets its users from the C++ camp, which isn't the mightiest army nowadays (And whose Windows battalions aren't supported very well by D). Go is in the news a lot because of its Google and Unix (Pike, Thompson) heritage, because it's a bit simpler (more C crossed with Python than ++C++), and because it has some prominent concurrency support, which is close to the current hype (every emerging language has to prove its mettle there). By the way, don't read this as a value judgment. It's just a personal assessment why I think that Go is currently a bit more popular and will continue to be so.
- kaib 16y ago
  I think this is a hard question to answer without a solid definition of popular. That said, at our startup we use Go for all server side work and I wrote Go production code while still working for Google. In my little world it's very popular, the only other language we use is Javascript.
  - tonfa 16y ago
    Interesting, how was Go used at Google? How do they deal with incompatible changes?
  - sandGorgon 16y ago
    that's interesting - did you evaluate something like Node.js or Clojure/Aleph for the same purpose ?
- drivingmenuts 16y ago
  Because it's promoted by a company with institutional ADD? /snark
- pmjordan 16y ago
  I can't speak for general popularity, but the reason I haven't been able to try it as a C & C++ replacement is that I tend to use C or C++ where I have to. Weird hardware, integrating with some existing piece of software, etc. Using it for that kind of thing is hard and definitely more work than using C/C++. I guess it's the same reason I don't use D.
- NonEUCitizen 16y ago
  No support for apt-get installation?
- Avshalom 16y ago
  Because it's still not really on Windows. Which means all the programmers stuck in Windows shops out there aren't doing anything with it, the game writing community isn't doing anything, and even people who write desktop apps are still looking at it a bit funny. Critical mass is slow to build as a result.
- junkbit 16y ago
  If anyone wants to have a go with Go you can now play with it in your browser: http://golang.org/ http://golang.org/

by jbarham 16y ago

TallGuyShort 16y ago

Speaking of Plan 9 and Go, I have to ask the same question: why isn't Go more popular?

alnayyir 16y ago
Not substantially performant for use in systems programming. Not substantially powerful or enough libraries for use in web dev (yet, this could change). Global GC (inappropriate for the niche it's ostensibly targeting). Overly opinionated about concurrency. (C++ and Java are the gold-standard for library-centric concurrency methodologies) Go sits in an uncanny valley.
- jbarham 16y ago
  > C++ and Java are the gold-standard for library-centric concurrency methodologies The last time I checked concurrency isn't possible with standard C++. And multi-threaded programming in Java has been called many things, but "gold-standard" isn't one of them.
  - alnayyir 16y ago
    >The last time I checked concurrency isn't possible with standard C++ If you don't know, then I can't tell you. People have been doing threading, re-entrant code, libevent/libev in C and C++ for decades. (cf. DragonflyBSD) I didn't say it was trivial, just that it's an industry standard for when you need to get things done (TM).
    - jbarham 16y ago
      It appears you are being intentionally obtuse, so I repeat: Neither the current C and C++ language standards provide any support whatsoever for concurrent programming. Therefore you cannot do concurrent programming in either of those languages without resorting to using operating system specific or 3rd party libraries. DragonflyBSD, a project that was only started in 2003, has obviously not been around for "decades" so hardly serves to advance your claim.
      - alnayyir 16y ago
        >Neither the current C and C++ language standards provide any support whatsoever for concurrent programming. They're not supposed to. They're systems programming languages. When you're writing a kernel or embedded software, having the language mandate some kind of concurrency model at the standards level is nonsensical. I wasn't linking decades to DragonflyBSD, I was saying that the techniques and methods have been known and used for decades. The original point, restated here for clarity is this. Go was supposed to be a new-age systems programming language. Its current design (mandated concurrency model and global GC) preclude that from ever happening without fundamental changes. Rust has a better chance of becoming the next systems programming language. I don't know what your niche or corner of the realm of software is, but I get the feeling you're commenting on a field you have no substantial experience in. It's evident to anybody with any real experience or wisdom concerning software that having choices like concurrency made for you at the language-level narrow the scope of usefulness for that particular language and pretty much precludes it from being a top-grade choice for embedded/systems development. Example: Were it not for the glut of hardware performance and memory capacity improvements in smartphones, Dalvik/java would've been impractical at best on Android. It's still a vastly inferior experience compared to the iPhone, which is obj-c with optional drop-down to C/C++. And don't mention the NDK for Android, it's a bad joke. Bootstrapping a runtime for a language that depends on a particular concurrency model irrespective of the problem at hand is stupid beyond my faculty for describing with words. tl;dr good luck using Go for hard real-time systems. Why do you think C++ achieved popularity so quickly? It was pliable to the demands of the problem being solved just like C at the expense of complexity.
  - philwelch 16y ago
    You can use Java's concurrency features to implement better concurrency features (as opposed to the language just giving you better concurrency features from the outset), which is presumably what was meant by "less opinionated" or "library-centric". You can have asynchronous or synchronous message passing or STM on mutable references to immutable data or really anything built on top of Java, but an opinionated language like Go just picks something (synchronous message passing in Go's case) and makes you use it.[1] [1] You can implement asynchronous message passing on top of synchronous message passing, but not the other way around. Presumably the "least opinionated" language would simply give you the concurrency primitive with which you can implement the greatest number of other concurrency primitives, which presumably[2] is locks. [2] I could be wrong about this.
    - alnayyir 16y ago
      I think you're the only one to get my point so far. A lot of the best libraries and concurrency approaches I've implemented in Clojure so far have been imports from Java. (NIO2 being one example)
- obiterdictum 16y ago
  It's hard to make any judgement of a language that's barely a year old, especially about performance and libraries. All industry standard languages are at least a decade old. > C++ and Java are the gold-standard for library-centric concurrency methodologies. It's a standard, but it is not by any means the gold standard. Just about anything would be a better concurrency model. Also see "Threads Cannot be Implemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html
  - alnayyir 16y ago
    >It's hard to make any judgement of a language that's barely a year old, especially about performance and libraries. All industry standard languages are at least a decade old. It's a product of their design decisions and has nothing at all to do with implementation or time. Look at Rust if you want to see a realistic up-and-coming systems programming language. >It's a standard, but it is not by any means the gold standard. Just about anything would be a better concurrency model. Right, well get back to me when you write that multi-threaded web server in Python.
zephyrfalcon 16y ago
It has only been out since November 2009, and it wasn't considered ready for production then. Maybe it is now, but it definitely hasn't had much time to be establish a large user base.
- mrj 16y ago
  Well... Not so much. I'm playing with it, but apparently it doesn't yet fully run on Windows. I think that'll work for my project, but that would prevent most people from using Go.
- mhd 16y ago
  Go is in a "public beta" status, i.e. what you see right now is its development, not its refinement. It basically hasn't reached a 1.0 release version yet. Participants of the mailing list are very early adopters who write some libraries for it. It's still likely enough that important parts of the language spec will change in non-compatible ways, and especially the standard library still isn't too stable (e.g. the http module is a bit orphaned right now). But the progress is quite impressive, and it might hit a niche for lots of people (those Zed Shaw tends to call "longbeards"). Unix systems programming is still dominated by C, as there aren't that many valid alternatives. Java is systems programming for the Java system, C++ is C++. Ocaml is probably one step too far for bit pushers. And then there's the pedigree of the developers. I think within a year the language should have matured enough. If someone manages to come up with a "killer application" for it (c.f. RoR/Ruby or node.js/server-side Javascript), it might take off. It might also end up like Modula-3.
  - xiongchiamiov 16y ago
    What about D?
    - mhd 16y ago
      That's a good question. D has been around for quite some time, has some well-known names (Bright, Alexandrescu), but has yet to break big. Compared to it, Go, a much more recent development, tends to do quite well (just my estimates, PL mindshare is a bit hard to measure). I think it's mostly because of some internal and positioning issues. I haven't been following it recently, but I remember some problems with different standard libraries, D 1 vs D 2, and three compilers that each had issues. Maybe that's resolved, but it certainly didn't make things look too good. Also, it seems to be more a successor to C++, which makes some people a bit distrustful. Yes, it's much cleaner, but also quite a bit more complex than C, and not a total programming environment as Java or C#. So it mainly gets its users from the C++ camp, which isn't the mightiest army nowadays (And whose Windows battalions aren't supported very well by D). Go is in the news a lot because of its Google and Unix (Pike, Thompson) heritage, because it's a bit simpler (more C crossed with Python than ++C++), and because it has some prominent concurrency support, which is close to the current hype (every emerging language has to prove its mettle there). By the way, don't read this as a value judgment. It's just a personal assessment why I think that Go is currently a bit more popular and will continue to be so.
kaib 16y ago
I think this is a hard question to answer without a solid definition of popular. That said, at our startup we use Go for all server side work and I wrote Go production code while still working for Google. In my little world it's very popular, the only other language we use is Javascript.
- tonfa 16y ago
  Interesting, how was Go used at Google? How do they deal with incompatible changes?
- sandGorgon 16y ago
  that's interesting - did you evaluate something like Node.js or Clojure/Aleph for the same purpose ?
drivingmenuts 16y ago
Because it's promoted by a company with institutional ADD? /snark
pmjordan 16y ago
I can't speak for general popularity, but the reason I haven't been able to try it as a C & C++ replacement is that I tend to use C or C++ where I have to. Weird hardware, integrating with some existing piece of software, etc. Using it for that kind of thing is hard and definitely more work than using C/C++. I guess it's the same reason I don't use D.
NonEUCitizen 16y ago
No support for apt-get installation?
Avshalom 16y ago
Because it's still not really on Windows. Which means all the programmers stuck in Windows shops out there aren't doing anything with it, the game writing community isn't doing anything, and even people who write desktop apps are still looking at it a bit funny. Critical mass is slow to build as a result.
junkbit 16y ago
If anyone wants to have a go with Go you can now play with it in your browser: http://golang.org/ http://golang.org/