7 ms·

I wrote The Little Go book [free], my first Go blog post was in 2011, and a few of my Go libraries are used by people other than just me. But Go's not my goto

by latch 11y ago

I wrote The Little Go book [free], my first Go blog post was in 2011, and a few of my Go libraries are used by people other than just me. But Go's not my goto language. I'm a staunch believer in the productivity of dynamic languages. In my opinion, Go's less than stellar type system and weak reflection capabilities exasperate this gap, even moreso for most websites / apis (which deal with impedance mismatch at two boundaries). But, to answer your question. Consider first that Go's very simple to pick up. So the investment is small. Second, where I differ from you is on your second point: Java. I dislike it. It's complicated and verbose and gets in my way. Rust and Go are both proof that we know how to build better languages now. So, when I need to share memory across multiple cores and performance is a concern, I switch to Go because it's fast and simple.

bogomipz 11y ago
Hi, could you elaborate on you comment about Go's "less than stellar type system"?
- latch 11y ago
  Lack of generics (stick, meet dead horse) is at the forefront. Lack of very basic functions (map, filter, reduce) against slices. map[string]interface{} is pain to work with (one of the moderately popular libraries I mentioned helps: https://github.com/karlseguin/typed https://github.com/karlseguin/typed) Lack of immutability. I don't want to get into errors vs exceptions, but I've never heard a pro-errors argument that wasn't hand waving. I think the decision makes sense given Go's genesis (system programming), but given how Go's actually being used, it's a step backwards.
  - bogomipz 11y ago
    Thanks. Right, generics is a big one. But isn't Go actually being used for system programming? At least that what I think of when I think of Golang. Maybe the scales have tipped and writing api/microservices is the larger use case now?
    - latch 11y ago
      I don't know. All I know is this [possibly dated] quote from Rob Pike: "Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++" Maybe Python and Ruby programmers are adopting Go to do system programming, but that isn't my impression.
  - staticint 11y ago
    What I struggle to understand is: If that functionality is considered useful or even impeding the development process for those developing in Go, why has nobody forked the language to add them? Many of the points you mention are fairly low hanging fruit for inclusion if you are willing to accept the tradeoffs that official Go maintainers are not willing to.
    - brandur 11y ago
      I think the trouble there is just that many other modern languages haven't taken the extreme stance on typing that Go has. It's much easier to learn say, Rust or Scala, than it is to fork and maintain a branch of Go, and there's certainly nothing so special or attractive about Go to tip the balance in the latter's favor.
      - staticint 11y ago
        The issue with that is that anyone invested in Rust or Scala have no reason to want a better type system in Go. Fixing Go is as important to them as fixing COBOL, and I don't see HN full of threads on what needs to change in COBOL. What we have here is people who are already heavily invested in Go to the point where its type system is a real problem for them, yet they do not want to fix the problems, even in light of the relative ease at which at least some the problems can be solved (again, if you are willing to accept the tradeoffs).
        pjmlp 11y ago
        Check the gonuts archives to see how welcoming the community is to such ideas.
        brandur 11y ago
        Yes, exactly. You could fork Go and add generics support, but you'd be maintaining that fork forever. The Go core team would never allow it to go back upstream.
        11y ago
- sgk284 11y ago
  While this may not be a popular opinion, I find Go's type system to mainly benefit the compiler in optimization and be of minimal benefit to the safety or correctness of the program. Any non-trivial Go project will have interface{} sprinkled all over [1], which effectively gives you the guarantees of a dynamic language with the syntactic overhead of a typed language. Truly the worst of both worlds. While I realize it's a tired argument, Go desperately needs generics in some form or another. It would remove most criticism from the language while substantially improving the correctness of programs. [1] Here's an example with an LRU cache. Just search for interface{} : https://github.com/hashicorp/golang-lru/blob/master/simplelru/lru.go https://github.com/hashicorp/golang-lru/blob/master/simplelr...
  - geodel 11y ago
    > It would remove most criticism from the language while substantially improving the correctness of programs. You seem to assume that people who do not like generics complexity will not complain then.
jonesb6 11y ago
I actually think Go's simplicity is a weakness because it will only get you so far. Take web development for example, all the tutorials show json.Unmarshall, but this one stackoverflow post says I should use json.Decode. Oh shoot now I'm having all sorts of problems because I don't really understand json.Decode. Furthermore I think most people reach for Golang in the beginning because they want performance. However I've found it incredibly easy to write unperformant Go. I think Golang will ultimately be a very important stepping stone in language development in terms of concurrency, type systems, standard libraries, deployability, and many other categories. I think a lot of important programs will be written in it. And ultimately I look forward to how future languages draw from it.
- masklinn 11y ago
  > I think Golang will ultimately be a very important stepping stone in language development in terms of concurrency, type systems "stepping stone" usually implies progress and Golang was a regression on both fronts, and while its deployment story is ok that's in no small part because it just opts to statically link everything by default, which the field has been going back and forth on basically since the beginning.
- wfsfw4w44 11y ago
  Your issue here (obviously), is going to stack overflow for advice.
- jerf 11y ago
  "Take web development for example, all the tutorials show json.Unmarshall, but this one stackoverflow post says I should use json.Decode." Plenty of JSON libraries in plenty of languages have both a function to decode JSON and an object that allows you to decode JSON with some settings. That's not really a Go-specific issue.
- shitgoose 11y ago
  "I actually think Go's simplicity is a weakness because it will only get you so far." Some may argue that Go's simplicity is a strength. Adding moving parts doesn't always help.
pron 11y ago
Rust and Go are so completely different that I don't see how they're similar. OTOH, I write most of my code in Java, and a little bit in Go, and can hardly tell the difference between the two (their goals, design philosophy and levels of abstraction are nearly identical). I use Go for small command-line apps, where it shines, and Java for more serious server-side software, where I can't do without its unparalleled monitoring and tooling and more, uhm, grownup approach towards dependencies and project management (unless you work like Google). I know some people don't like Java, but I'm puzzled when the same people like Go (I can understand how you can like neither, or, like me, both). I agree that the onboarding experience for Go is better and more familiar to people coming over from Python (perhaps to the point that to people coming from Python, Java and Go appear very different), but if you're used to Java, Go feels like Java-lite. You use it when you need something more quick-and-dirty (or for command-line apps; Go is a much better fit than Java for those), but you stick with the "full" version for the serious stuff.
- geodel 11y ago
  The only reason I will stick with Java is because business applications are in Java and there is no reason to use any other language. > their goals, design philosophy and levels of abstraction are nearly identical I think it could not be more different. Java APIs (including libs by Sun/IBM/Oracle) is a manifestation of more is less which is exactly opposite of Go. > Java for more serious server-side software The seriousness part is only because serious folks (the one who fund projects) prefer Java. I too think this is very important if not the most important part. > unparalleled monitoring and tooling and more, I too would need lot of monitoring and tooling if Oracle/OpenJDK GC keeps crapping out for just 10-20GB heaps which is currently the case for us.
  - pron 11y ago
    > Java APIs (including libs by Sun/IBM/Oracle) is a manifestation of more is less which is exactly opposite of Go. For example? > The seriousness part is only because serious folks (the one who fund projects) prefer Java. I disagree. There are plenty of design decisions in Go that make it less optimal for very large projects (e.g. dependencies, error handling, generics), but most of all lack of hackability. Go is one of the least hackable languages I've ever encountered, i.e. the only escape-hatch you have when you realize, 5 years into the project, that you need to circumvent some runtime semantics are either source-code instrumentation or hacking on the runtime itself. > Oracle/OpenJDK GC keeps crapping out for just 10-20GB heaps which is currently the case for us. There is no way Go's GC wouldn't crap out on you sooner (except maybe in the circumstances that are now addressed as part of Valhalla). Having said that, I think Go is great, and is a natural fit for anyone who likes the Java philosophy (which is also the Go philosophy)[1]. Some design decisions and some implementation circumstances just make it less suitable for really big stuff. [1]: Namely, reading comes before writing, no too-clever tricks, and no cutting-edge PL ideas; a "blue collar" language, as Gosling referred to it.
cel1ne 11y ago
The days of Java being verbose are over with Lambdas and Method References. I don't know what you mean by "getting in the way". If you have time to spare read this: http://blog.paralleluniverse.co/2014/05/01/modern-java/ http://blog.paralleluniverse.co/2014/05/01/modern-java/
- twic 11y ago
  In particular, it's preposterous to call Java verbose in comparison with Go when Go has the error handling that it does.
- shitgoose 11y ago
  he may have meant this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... One just can't write this shit in Go. The language itself precludes it.
  - pron 11y ago
    > The language itself precludes it. It really doesn't, and you could write the exact same thing. Java code doesn't look like that, either (certainly not modern code).

by latch 11y ago

bogomipz 11y ago

Hi, could you elaborate on you comment about Go's "less than stellar type system"?

latch 11y ago
Lack of generics (stick, meet dead horse) is at the forefront. Lack of very basic functions (map, filter, reduce) against slices. map[string]interface{} is pain to work with (one of the moderately popular libraries I mentioned helps: https://github.com/karlseguin/typed https://github.com/karlseguin/typed) Lack of immutability. I don't want to get into errors vs exceptions, but I've never heard a pro-errors argument that wasn't hand waving. I think the decision makes sense given Go's genesis (system programming), but given how Go's actually being used, it's a step backwards.
- bogomipz 11y ago
  Thanks. Right, generics is a big one. But isn't Go actually being used for system programming? At least that what I think of when I think of Golang. Maybe the scales have tipped and writing api/microservices is the larger use case now?
  - latch 11y ago
    I don't know. All I know is this [possibly dated] quote from Rob Pike: "Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++" Maybe Python and Ruby programmers are adopting Go to do system programming, but that isn't my impression.
- staticint 11y ago
  What I struggle to understand is: If that functionality is considered useful or even impeding the development process for those developing in Go, why has nobody forked the language to add them? Many of the points you mention are fairly low hanging fruit for inclusion if you are willing to accept the tradeoffs that official Go maintainers are not willing to.
  - brandur 11y ago
    I think the trouble there is just that many other modern languages haven't taken the extreme stance on typing that Go has. It's much easier to learn say, Rust or Scala, than it is to fork and maintain a branch of Go, and there's certainly nothing so special or attractive about Go to tip the balance in the latter's favor.
    - staticint 11y ago
      The issue with that is that anyone invested in Rust or Scala have no reason to want a better type system in Go. Fixing Go is as important to them as fixing COBOL, and I don't see HN full of threads on what needs to change in COBOL. What we have here is people who are already heavily invested in Go to the point where its type system is a real problem for them, yet they do not want to fix the problems, even in light of the relative ease at which at least some the problems can be solved (again, if you are willing to accept the tradeoffs).
      - pjmlp 11y ago
        Check the gonuts archives to see how welcoming the community is to such ideas.
        brandur 11y ago
        Yes, exactly. You could fork Go and add generics support, but you'd be maintaining that fork forever. The Go core team would never allow it to go back upstream.
      - 11y ago
sgk284 11y ago
While this may not be a popular opinion, I find Go's type system to mainly benefit the compiler in optimization and be of minimal benefit to the safety or correctness of the program. Any non-trivial Go project will have interface{} sprinkled all over [1], which effectively gives you the guarantees of a dynamic language with the syntactic overhead of a typed language. Truly the worst of both worlds. While I realize it's a tired argument, Go desperately needs generics in some form or another. It would remove most criticism from the language while substantially improving the correctness of programs. [1] Here's an example with an LRU cache. Just search for interface{} : https://github.com/hashicorp/golang-lru/blob/master/simplelru/lru.go https://github.com/hashicorp/golang-lru/blob/master/simplelr...
- geodel 11y ago
  > It would remove most criticism from the language while substantially improving the correctness of programs. You seem to assume that people who do not like generics complexity will not complain then.

jonesb6 11y ago

I actually think Go's simplicity is a weakness because it will only get you so far. Take web development for example, all the tutorials show json.Unmarshall, but this one stackoverflow post says I should use json.Decode. Oh shoot now I'm having all sorts of problems because I don't really understand json.Decode. Furthermore I think most people reach for Golang in the beginning because they want performance. However I've found it incredibly easy to write unperformant Go. I think Golang will ultimately be a very important stepping stone in language development in terms of concurrency, type systems, standard libraries, deployability, and many other categories. I think a lot of important programs will be written in it. And ultimately I look forward to how future languages draw from it.

masklinn 11y ago
> I think Golang will ultimately be a very important stepping stone in language development in terms of concurrency, type systems "stepping stone" usually implies progress and Golang was a regression on both fronts, and while its deployment story is ok that's in no small part because it just opts to statically link everything by default, which the field has been going back and forth on basically since the beginning.
wfsfw4w44 11y ago
Your issue here (obviously), is going to stack overflow for advice.
jerf 11y ago
"Take web development for example, all the tutorials show json.Unmarshall, but this one stackoverflow post says I should use json.Decode." Plenty of JSON libraries in plenty of languages have both a function to decode JSON and an object that allows you to decode JSON with some settings. That's not really a Go-specific issue.
shitgoose 11y ago
"I actually think Go's simplicity is a weakness because it will only get you so far." Some may argue that Go's simplicity is a strength. Adding moving parts doesn't always help.

pron 11y ago

Rust and Go are so completely different that I don't see how they're similar. OTOH, I write most of my code in Java, and a little bit in Go, and can hardly tell the difference between the two (their goals, design philosophy and levels of abstraction are nearly identical). I use Go for small command-line apps, where it shines, and Java for more serious server-side software, where I can't do without its unparalleled monitoring and tooling and more, uhm, grownup approach towards dependencies and project management (unless you work like Google). I know some people don't like Java, but I'm puzzled when the same people like Go (I can understand how you can like neither, or, like me, both). I agree that the onboarding experience for Go is better and more familiar to people coming over from Python (perhaps to the point that to people coming from Python, Java and Go appear very different), but if you're used to Java, Go feels like Java-lite. You use it when you need something more quick-and-dirty (or for command-line apps; Go is a much better fit than Java for those), but you stick with the "full" version for the serious stuff.

geodel 11y ago
The only reason I will stick with Java is because business applications are in Java and there is no reason to use any other language. > their goals, design philosophy and levels of abstraction are nearly identical I think it could not be more different. Java APIs (including libs by Sun/IBM/Oracle) is a manifestation of more is less which is exactly opposite of Go. > Java for more serious server-side software The seriousness part is only because serious folks (the one who fund projects) prefer Java. I too think this is very important if not the most important part. > unparalleled monitoring and tooling and more, I too would need lot of monitoring and tooling if Oracle/OpenJDK GC keeps crapping out for just 10-20GB heaps which is currently the case for us.
- pron 11y ago
  > Java APIs (including libs by Sun/IBM/Oracle) is a manifestation of more is less which is exactly opposite of Go. For example? > The seriousness part is only because serious folks (the one who fund projects) prefer Java. I disagree. There are plenty of design decisions in Go that make it less optimal for very large projects (e.g. dependencies, error handling, generics), but most of all lack of hackability. Go is one of the least hackable languages I've ever encountered, i.e. the only escape-hatch you have when you realize, 5 years into the project, that you need to circumvent some runtime semantics are either source-code instrumentation or hacking on the runtime itself. > Oracle/OpenJDK GC keeps crapping out for just 10-20GB heaps which is currently the case for us. There is no way Go's GC wouldn't crap out on you sooner (except maybe in the circumstances that are now addressed as part of Valhalla). Having said that, I think Go is great, and is a natural fit for anyone who likes the Java philosophy (which is also the Go philosophy)[1]. Some design decisions and some implementation circumstances just make it less suitable for really big stuff. [1]: Namely, reading comes before writing, no too-clever tricks, and no cutting-edge PL ideas; a "blue collar" language, as Gosling referred to it.

cel1ne 11y ago

The days of Java being verbose are over with Lambdas and Method References. I don't know what you mean by "getting in the way". If you have time to spare read this: http://blog.paralleluniverse.co/2014/05/01/modern-java/ http://blog.paralleluniverse.co/2014/05/01/modern-java/

twic 11y ago
In particular, it's preposterous to call Java verbose in comparison with Go when Go has the error handling that it does.
shitgoose 11y ago
he may have meant this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... One just can't write this shit in Go. The language itself precludes it.
- pron 11y ago
  > The language itself precludes it. It really doesn't, and you could write the exact same thing. Java code doesn't look like that, either (certainly not modern code).