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.
Comments
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#.