7 ms·

If you come from a Scala background, you will find Go pretty 'Meh' feature-wise (No offense). It's a great language, but still it has a long way to go. With tha

by neya 13y ago

If you come from a Scala background, you will find Go pretty 'Meh' feature-wise (No offense). It's a great language, but still it has a long way to go. With that said, I personally want Go to succeed as I love it's syntax (compared to Scala's slightly hair-pulling syntax). Also, the lack of robust battle-tested web-frameworks is right now a show stopper for me.

PommeDeTerre 13y ago
One interesting thing to consider about the increase in Go's popularity is that it has been driven, to some extent, by programmers who really only had experience with PHP, Ruby, or JavaScript. These are the kind of developers who have by now been burned by the inherent dangers and drawbacks of dynamic languages. They know enough to know that there must be a better way to develop safer, more reliable and better-performing software. They just aren't familiar enough with existing statically-typed compiled languages to know what's already possible. Go may just be in the right place at the right time. It is simpler than languages like C, C++, Haskell, SML, and even Scala, for example. And it is getting a lot of hype just when these dynamic language refugees need something better, and are actively looking for it. While it's good that Go offers a much better environment and infrastructure than many of these developers are accustomed to, this may also be harmful in some ways. It may be just "good enough", at least compared to the alternatives that they're familiar with, that they don't feel the need to explore more established languages which do offer much more. Even if they don't move past Go any time soon, at least it's encouraging to see them using a more responsible language for larger-scale software projects.
- steveklabnik 13y ago
  This defiantly jives with some of my experiences. I've been saying that "Go makes me feel like an old man," because other than a _fantastic_ development experience, I don't actually see anything about Go that's particularly interesting and/or worthwhile. I also remind fellow Rubyists who say "Go is boring, it's supposed to be that way!" that when they talk shit on Java, that was one of its rallying cries as well. It's all just a bunch of cycles, what's trendy comes and goes, is boring and then interesting again...
- happy_dino 13y ago
  That has exactly been my experience, too. The people who think Go is great are the same who lack substantial experience with any remotely modern programming language.
copx 13y ago
The lack of features actually is a feature. It is a different approach to language design. The Go devs wanted to keep the number of language constructs small.
- happy_dino 13y ago
  ... one would have hoped that this decision would have enabled them to at least get those features right which went into the language. Nope.
smegel 13y ago
Except that Scala lacks Go's headline feature: green threads. Being able to write event-based code without the use of callbacks is a major paradigm shift away from almost everything that came before it. Yes, Scala has loop/react ... but they are really just a different way of writing callbacks, and don't allow you write truly synchronous-style code over an event based system.
- happy_dino 13y ago
  Eh what? That's not right, that's not even wrong... The style one can program in and the style it is implemented isn't connected the way you think it is. And no, Scala "doesn't have" loop/react. Unlike Go, where people seemingly put random stuff into the language, it's just a bog-standard library.
  - smegel 13y ago
    > The style one can program in and the style it is implemented isn't connected the way you think it is. The implementation determines what happens when synchronous, blocking code, well blocks. In Go it yields to another green thread (Goroutine). In any language implemented on the JVM (including Scala) you block an OS level thread. The way languages without green thread support allow non-blocking, event based code is through callbacks, which can get pretty horrendous in large, complex programs. > Unlike Go, where people seemingly put random stuff into the language, it's just a bog-standard library. I'm not sure why that is relevant (Actors seem a pretty core part of Scala), but I guess it is unsurprising that a mere library on top of the JVM is still constrained by the kind of concurrency supported by that platform, i.e. the lack of green threads.
    - happy_dino 13y ago
      > In any language implemented on the JVM (including Scala) you block an OS level thread. Wrong. Whether JVM implementations use green threads or system threads is an implementation detail. There are implementations for both cases. You realize that many JVM implementations started with green threads in the early days and abandoned them not much later? There is a reason for that. > The way languages without green thread support allow non-blocking, event based code is through callbacks, which can get pretty horrendous in large, complex programs. Wrong. I repeat, the underlying threading model does not necessarily enforce some style of API. > I'm not sure why that is relevant (Actors seem a pretty core part of Scala) Actors are a library, just like Scala's async/await, the Future/Promises library, the continuation library, Java's Fork/Join library. Actually, Scala just replaced its “official” Actor library in the last release. Go will be stuck forever with its ad-hoc stuff which has been hard-coded into the language. > it is unsurprising that a mere library on top of the JVM is still constrained by the kind of concurrency supported by that platform, i.e. the lack of green threads LOOOOOOOOOOOL. Since when are green threads the “new best thing ever!!!11!!”? Did I miss a memo here? You know what? Wake me up when Go has fixed their broken scheduler. Until then, I just keep watching how the JVM embarrasses Go on pretty much every concurrency and scalability workload.
MetaCosm 13y ago
If you think lack of features is a knock against Go, you aren't really in the right mindset (Go might just not be for you). The lack of remarkable features is what is remarkable. The same with heavily built web-frameworks versus like Gorilla (a series of take it or leave tools). Scala has every feature and language construct under the sun and full access to the astounding landscape of Java -- as well as amazing tools like Akka. This is all wonderful, and I enjoy using Scala because it is rich and you can treat is very functionally. That said, I now prefer Go to it after shipping two production products on it. A deploy that is second to none, amazingly fast development cycles, easy to build rich custom tools on top of it (for example go-diff, which ignores syntax differences and only shows functional differences), the easiest cross compilation I have ever used, and a focus on this exceptional clear and easy to read code (lack of implicitness / magic). It reminds me a lot of what I like about Erlang -- with some of the more annoying bits stripped away. But, at the end of the day I am using Go for three reasons: 1) Lets me get work done quicker than other languages (and win contracts / beat competition) 2) I can keep the entire spec (50 pages) in my head, with very little time spent. I have used Scala far longer, but would never make such a claim about it. 3) The tool chain (build, cross-compile, test, format, doc) that comes with it is amazing, the least obnoxious I have ever used. It has warts (get), but all in all -- it makes using anything else exceptionally painful. Once you get used to "go test ./... && go install ./..." to build your app and put it in ./bin -- and you get used to doing deploys with "scp bin/foo server..." everything else starts to feel stupid.

by neya 13y ago

PommeDeTerre 13y ago

One interesting thing to consider about the increase in Go's popularity is that it has been driven, to some extent, by programmers who really only had experience with PHP, Ruby, or JavaScript. These are the kind of developers who have by now been burned by the inherent dangers and drawbacks of dynamic languages. They know enough to know that there must be a better way to develop safer, more reliable and better-performing software. They just aren't familiar enough with existing statically-typed compiled languages to know what's already possible. Go may just be in the right place at the right time. It is simpler than languages like C, C++, Haskell, SML, and even Scala, for example. And it is getting a lot of hype just when these dynamic language refugees need something better, and are actively looking for it. While it's good that Go offers a much better environment and infrastructure than many of these developers are accustomed to, this may also be harmful in some ways. It may be just "good enough", at least compared to the alternatives that they're familiar with, that they don't feel the need to explore more established languages which do offer much more. Even if they don't move past Go any time soon, at least it's encouraging to see them using a more responsible language for larger-scale software projects.

steveklabnik 13y ago
This defiantly jives with some of my experiences. I've been saying that "Go makes me feel like an old man," because other than a _fantastic_ development experience, I don't actually see anything about Go that's particularly interesting and/or worthwhile. I also remind fellow Rubyists who say "Go is boring, it's supposed to be that way!" that when they talk shit on Java, that was one of its rallying cries as well. It's all just a bunch of cycles, what's trendy comes and goes, is boring and then interesting again...
happy_dino 13y ago
That has exactly been my experience, too. The people who think Go is great are the same who lack substantial experience with any remotely modern programming language.

copx 13y ago

The lack of features actually is a feature. It is a different approach to language design. The Go devs wanted to keep the number of language constructs small.

happy_dino 13y ago
... one would have hoped that this decision would have enabled them to at least get those features right which went into the language. Nope.

smegel 13y ago

Except that Scala lacks Go's headline feature: green threads. Being able to write event-based code without the use of callbacks is a major paradigm shift away from almost everything that came before it. Yes, Scala has loop/react ... but they are really just a different way of writing callbacks, and don't allow you write truly synchronous-style code over an event based system.

happy_dino 13y ago
Eh what? That's not right, that's not even wrong... The style one can program in and the style it is implemented isn't connected the way you think it is. And no, Scala "doesn't have" loop/react. Unlike Go, where people seemingly put random stuff into the language, it's just a bog-standard library.
- smegel 13y ago
  > The style one can program in and the style it is implemented isn't connected the way you think it is. The implementation determines what happens when synchronous, blocking code, well blocks. In Go it yields to another green thread (Goroutine). In any language implemented on the JVM (including Scala) you block an OS level thread. The way languages without green thread support allow non-blocking, event based code is through callbacks, which can get pretty horrendous in large, complex programs. > Unlike Go, where people seemingly put random stuff into the language, it's just a bog-standard library. I'm not sure why that is relevant (Actors seem a pretty core part of Scala), but I guess it is unsurprising that a mere library on top of the JVM is still constrained by the kind of concurrency supported by that platform, i.e. the lack of green threads.
  - happy_dino 13y ago
    > In any language implemented on the JVM (including Scala) you block an OS level thread. Wrong. Whether JVM implementations use green threads or system threads is an implementation detail. There are implementations for both cases. You realize that many JVM implementations started with green threads in the early days and abandoned them not much later? There is a reason for that. > The way languages without green thread support allow non-blocking, event based code is through callbacks, which can get pretty horrendous in large, complex programs. Wrong. I repeat, the underlying threading model does not necessarily enforce some style of API. > I'm not sure why that is relevant (Actors seem a pretty core part of Scala) Actors are a library, just like Scala's async/await, the Future/Promises library, the continuation library, Java's Fork/Join library. Actually, Scala just replaced its “official” Actor library in the last release. Go will be stuck forever with its ad-hoc stuff which has been hard-coded into the language. > it is unsurprising that a mere library on top of the JVM is still constrained by the kind of concurrency supported by that platform, i.e. the lack of green threads LOOOOOOOOOOOL. Since when are green threads the “new best thing ever!!!11!!”? Did I miss a memo here? You know what? Wake me up when Go has fixed their broken scheduler. Until then, I just keep watching how the JVM embarrasses Go on pretty much every concurrency and scalability workload.

MetaCosm 13y ago

If you think lack of features is a knock against Go, you aren't really in the right mindset (Go might just not be for you). The lack of remarkable features is what is remarkable. The same with heavily built web-frameworks versus like Gorilla (a series of take it or leave tools). Scala has every feature and language construct under the sun and full access to the astounding landscape of Java -- as well as amazing tools like Akka. This is all wonderful, and I enjoy using Scala because it is rich and you can treat is very functionally. That said, I now prefer Go to it after shipping two production products on it. A deploy that is second to none, amazingly fast development cycles, easy to build rich custom tools on top of it (for example go-diff, which ignores syntax differences and only shows functional differences), the easiest cross compilation I have ever used, and a focus on this exceptional clear and easy to read code (lack of implicitness / magic). It reminds me a lot of what I like about Erlang -- with some of the more annoying bits stripped away. But, at the end of the day I am using Go for three reasons: 1) Lets me get work done quicker than other languages (and win contracts / beat competition) 2) I can keep the entire spec (50 pages) in my head, with very little time spent. I have used Scala far longer, but would never make such a claim about it. 3) The tool chain (build, cross-compile, test, format, doc) that comes with it is amazing, the least obnoxious I have ever used. It has warts (get), but all in all -- it makes using anything else exceptionally painful. Once you get used to "go test ./... && go install ./..." to build your app and put it in ./bin -- and you get used to doing deploys with "scp bin/foo server..." everything else starts to feel stupid.