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.
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).
Hmm, I haven't implemented anything complex in Go, but I have read a fair amount of code and looked at the "spec."
What language feature(s) would you say greatly assisted you in Go?
There's a credible argument that C# is a very complicated language (it is relatively old and has undergone a significant amount of iterations, thus is quite large), but I don't usually find that programmers are defining their own subset of the language to program in (a la C++), which usually means that the complexity isn't that large for me.
If you have any specific complaints I would love to know them as C# is being actively developed right this second, including new language features (well, not by me, I'm on vacation :)).
If you feel that HN is the best forum, please feel free to forward them to the email in my profile.
For me it's the comparative noise level. C# is noisy enough. When combined with stick your code here framework and code generation, monkeying with IIS, and the rest of the msft box I'm thrown into regardless of app load and requirements, I just start detaching or worse am just worn out at the end of the day. Go asks for so little in the productivity I get in return. Haven't enjoyed writing code this much since my Modula-2 days.
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)
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 =)
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.
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.
No I wouldn't be saying I produce reams of boilerplate like it's a good thing ;) I meant, and I'm sure you've experience this, that the language doesn't get in the way of realizing the program that's still in my head. Every interruption spent tracking down some language quirk is probably double the time or more to get back into the flow of it. It's really a shame Microsoft doesn't do more to make C# more portable.
The reason you write less code in Go is because there is less complexity. Similar to F# vs C#:
http://fpbridge.co.uk/why-fsharp.html (checkout the call graph comparisons. I believe a Haskell call graph would be similar, but I could be very wrong.
I don't see the irony. It's a contrast of a class based and object oriented language vs a functional language. The functional language leads to a much simpler call graph than the OOP language.
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.
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!
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.
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++.
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?
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.
Comments
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.
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.
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).
Hmm, I haven't implemented anything complex in Go, but I have read a fair amount of code and looked at the "spec."
What language feature(s) would you say greatly assisted you in Go?
There's a credible argument that C# is a very complicated language (it is relatively old and has undergone a significant amount of iterations, thus is quite large), but I don't usually find that programmers are defining their own subset of the language to program in (a la C++), which usually means that the complexity isn't that large for me.
If you have any specific complaints I would love to know them as C# is being actively developed right this second, including new language features (well, not by me, I'm on vacation :)).
If you feel that HN is the best forum, please feel free to forward them to the email in my profile.
For me it's the comparative noise level. C# is noisy enough. When combined with stick your code here framework and code generation, monkeying with IIS, and the rest of the msft box I'm thrown into regardless of app load and requirements, I just start detaching or worse am just worn out at the end of the day. Go asks for so little in the productivity I get in return. Haven't enjoyed writing code this much since my Modula-2 days.
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)
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 =)
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.
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.
No I wouldn't be saying I produce reams of boilerplate like it's a good thing ;) I meant, and I'm sure you've experience this, that the language doesn't get in the way of realizing the program that's still in my head. Every interruption spent tracking down some language quirk is probably double the time or more to get back into the flow of it. It's really a shame Microsoft doesn't do more to make C# more portable.
The reason you write less code in Go is because there is less complexity. Similar to F# vs C#:
http://fpbridge.co.uk/why-fsharp.html (checkout the call graph comparisons. I believe a Haskell call graph would be similar, but I could be very wrong.
Kind of ironic that for making a point on C#, you're using F#, an FP language.
I don't see the irony. It's a contrast of a class based and object oriented language vs a functional language. The functional language leads to a much simpler call graph than the OOP language.
The irony is that Go is not a functional programming language.
You're right. One of the reason it has simpler call graphs and less complexity is because it is composition based and struct rather than class based.
I agree from the original poster having done a lot of C/C++/Java/C# in the past.
Yes, he is exaggerating. Go is nowhere near as expressive or productive as C#.
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.
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!
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.
So use Rust. Rust looks neat.
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++.
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?
One thing is gochannels and the lightweight concurrency primitives.
Java, Scala, Clojure, Haskell, C#, F#, Scheme (do Rackets Places count?) all have their equivalents.
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.