5 ms·

In general, I agree. Go doesn't have to be all things to all people, but it could be more than it is with a story about how it would add generics. I think a l

In general, I agree. Go doesn't have to be all things to all people, but it could be more than it is with a story about how it would add generics. I think a lot of people are disappointed that Go doesn't seem interested in going beyond the "systems language" level; we were excited to use Go in a range of applications but were disappointed by our inability to write generic map/reduce/fold/etc functions. >I would be just as happy at this point to see the Golang team put generics to rest. Clarity on this point would be great. And update the FAQ. As it is, Rust is looking better and better as Mozilla tightens it up. EDIT: I added the Rust note after tptacek added his reply. Apologies to him.

tptacek 13y ago
So use Rust. Rust looks neat.
joncooper 13y ago
Totally agree. Go is a superb systems language. But I wouldn't use it for a CRUD web app, nor for quasi-exploratory data pipelines, which is where IMO such generic functional combinators are clutch. It is however awesome when you've nailed down the data pipeline and you want to get a big speed improvement in a fraction of the time required to build out in C/C++.
- ghayes 13y ago
  I would use it for a CRUD app and I wish it had features that would support that. As an open-language, this input should be considered (alongside the input of the maintainers and other users of the language). I believe the top-comment here was saying that this conversation shouldn't be side-lined.
- Buttons840 13y ago
  What makes Go a good "systems language"? Is it because it's fast? What about Java, Scala, Clojure, Haskell, C#, F#, Scheme, Ocaml, etc, which all have performance (speed of execution) similar to Go, are they good "systems languages" as well? If it's not speed of execution then what makes Go a good systems language? The ability to fiddle bits? A small runtime?
  - amalag 13y ago
    One thing is gochannels and the lightweight concurrency primitives.
    - codygman 13y ago
      Java, Scala, Clojure, Haskell, C#, F#, Scheme (do Rackets Places count?) all have their equivalents.
Buttons840 13y ago
Is go really trying to stick to a "system level" language? The performance benchmarks I've seen seem to suggest it's no more suitable for that than Java, Haskell, and a variety of other "2 to 3 times slower than c" languages. Except I think Go might be the only one pushing itself as a system level language.
- dpritchett 13y ago
  I think it's occupying a nice spot on the spectrum between say C and Ruby. If you're implementing some CRUD app with a few hotspots, maybe you'll implement the whole thing in Rails, then break it out into an SOA with golang services powering the hotspots. Finally if you really need to you can hand-tune the hottest spots with some C code inside of your Go services. One thing I've been enjoying out of the Go community is narrowly scoped command line tools. Heroku's CLI client runs on Ruby, but there's an `hk` variant written in Go that offers 90% of the functionality with a fraction of the runtime. More of that, please!
- NateDad 13y ago
  Calling it a system level language is a disservice. It's great for servers and commandline utilities. Canonical is working on integrating go with QML to be able to write nice GUI code that runs on all major platforms. Go is actually quite well suited to GUI code, because it handles concurrent work very easily (i.e. work on the gui thread vs. work on a non-gui thread). About the only thing you can't do nicely in go is write a domain specific language, the way you can in other languages that allow operator overloading. Anything you might think about writing in Java or C# you can write easily in Go (once the GoQML stuff is ready that'll include GUI code). Most things you might want to write in python or ruby you can write easily in go (as long as you don't need monkey patching). And note, I mean "Would be pleasant to write in Go" not "Would be possible but painful to write in Go" If you're doing a lot of vector and matrices math, Go might not be the best language, since you can't operator overload and thus can't make the code look like the math it's trying to replicate. It would still work and would still be fast and accurate and nicely concurrent... but most people doing that kind of math programming have come to expect that parts of their code will look like math, and in Go it won't.
jksmith 13y ago
Let's remember that to the stakeholders, this stuff is just a means to an end. I'd like to see Go have generics as well, but after spending the last two weeks writing a service bus in Go, the work was by factors more productive than the same work I've done in C#, which seems to be trying to have every possible language feature ever created in it. Sure generics would be nice, but getting my shit done and moving on to the next challenge is even nicer. Hopefully some carefully thought out additions to Go will allow me to have all this goodness at some point. Sorry for drift, but I have to put in a word for formalized pre/post conditions in Go. Really enjoyed that stuff in Eiffel, and I think it would play in well with the judicious lack of exceptions (which I like).
- michaelwww 13y ago
  > by factors more productive than the same work I've done in C# are you exaggerating here? C# is already the most productive language in my toolkit. It's easy to write reams of code that just works in C#. I should have a look at Go then. (edit forgot a word)
  - finnh 13y ago
    I measure my productivity in a language by how little code I can write to accomplish my goal. You seem to be saying the opposite? EDIT: I guess you are saying something slightly different: that you can produce reams of C# code that works out of the box without many iterations. "reams" to me implies boilerplate & excessive ceremony, but I shouldn't assume that about your work =)
    - usea 13y ago
      Shouldn't productivity be measured in how much time it takes to solve problems? The amount of code produced at the end is only relevant if typing is a significant portion of your time spent. Typing is rarely my bottleneck.
      - markkanof 13y ago
        Agree that typing speed is not the bottleneck when writing code, but there is something to be said for writing fewer lines of code that are also easy to understand (ie. overly clever code that is concise is often a negative). That should make maintenance and debugging easier as there is less code in which to introduce bugs and less code to load into your brain when returning to it later.

tptacek 13y ago

So use Rust. Rust looks neat.

joncooper 13y ago

Totally agree. Go is a superb systems language. But I wouldn't use it for a CRUD web app, nor for quasi-exploratory data pipelines, which is where IMO such generic functional combinators are clutch. It is however awesome when you've nailed down the data pipeline and you want to get a big speed improvement in a fraction of the time required to build out in C/C++.

ghayes 13y ago
I would use it for a CRUD app and I wish it had features that would support that. As an open-language, this input should be considered (alongside the input of the maintainers and other users of the language). I believe the top-comment here was saying that this conversation shouldn't be side-lined.
Buttons840 13y ago
What makes Go a good "systems language"? Is it because it's fast? What about Java, Scala, Clojure, Haskell, C#, F#, Scheme, Ocaml, etc, which all have performance (speed of execution) similar to Go, are they good "systems languages" as well? If it's not speed of execution then what makes Go a good systems language? The ability to fiddle bits? A small runtime?
- amalag 13y ago
  One thing is gochannels and the lightweight concurrency primitives.
  - codygman 13y ago
    Java, Scala, Clojure, Haskell, C#, F#, Scheme (do Rackets Places count?) all have their equivalents.

Buttons840 13y ago

Is go really trying to stick to a "system level" language? The performance benchmarks I've seen seem to suggest it's no more suitable for that than Java, Haskell, and a variety of other "2 to 3 times slower than c" languages. Except I think Go might be the only one pushing itself as a system level language.

dpritchett 13y ago
I think it's occupying a nice spot on the spectrum between say C and Ruby. If you're implementing some CRUD app with a few hotspots, maybe you'll implement the whole thing in Rails, then break it out into an SOA with golang services powering the hotspots. Finally if you really need to you can hand-tune the hottest spots with some C code inside of your Go services. One thing I've been enjoying out of the Go community is narrowly scoped command line tools. Heroku's CLI client runs on Ruby, but there's an `hk` variant written in Go that offers 90% of the functionality with a fraction of the runtime. More of that, please!
NateDad 13y ago
Calling it a system level language is a disservice. It's great for servers and commandline utilities. Canonical is working on integrating go with QML to be able to write nice GUI code that runs on all major platforms. Go is actually quite well suited to GUI code, because it handles concurrent work very easily (i.e. work on the gui thread vs. work on a non-gui thread). About the only thing you can't do nicely in go is write a domain specific language, the way you can in other languages that allow operator overloading. Anything you might think about writing in Java or C# you can write easily in Go (once the GoQML stuff is ready that'll include GUI code). Most things you might want to write in python or ruby you can write easily in go (as long as you don't need monkey patching). And note, I mean "Would be pleasant to write in Go" not "Would be possible but painful to write in Go" If you're doing a lot of vector and matrices math, Go might not be the best language, since you can't operator overload and thus can't make the code look like the math it's trying to replicate. It would still work and would still be fast and accurate and nicely concurrent... but most people doing that kind of math programming have come to expect that parts of their code will look like math, and in Go it won't.

jksmith 13y ago

Let's remember that to the stakeholders, this stuff is just a means to an end. I'd like to see Go have generics as well, but after spending the last two weeks writing a service bus in Go, the work was by factors more productive than the same work I've done in C#, which seems to be trying to have every possible language feature ever created in it. Sure generics would be nice, but getting my shit done and moving on to the next challenge is even nicer. Hopefully some carefully thought out additions to Go will allow me to have all this goodness at some point. Sorry for drift, but I have to put in a word for formalized pre/post conditions in Go. Really enjoyed that stuff in Eiffel, and I think it would play in well with the judicious lack of exceptions (which I like).

michaelwww 13y ago
> by factors more productive than the same work I've done in C# are you exaggerating here? C# is already the most productive language in my toolkit. It's easy to write reams of code that just works in C#. I should have a look at Go then. (edit forgot a word)
- finnh 13y ago
  I measure my productivity in a language by how little code I can write to accomplish my goal. You seem to be saying the opposite? EDIT: I guess you are saying something slightly different: that you can produce reams of C# code that works out of the box without many iterations. "reams" to me implies boilerplate & excessive ceremony, but I shouldn't assume that about your work =)
  - usea 13y ago
    Shouldn't productivity be measured in how much time it takes to solve problems? The amount of code produced at the end is only relevant if typing is a significant portion of your time spent. Typing is rarely my bottleneck.
    - markkanof 13y ago
      Agree that typing speed is not the bottleneck when writing code, but there is something to be said for writing fewer lines of code that are also easy to understand (ie. overly clever code that is concise is often a negative). That should make maintenance and debugging easier as there is less code in which to introduce bugs and less code to load into your brain when returning to it later.