12 ms·

I have been using Go in production since 2015 and can honestly say that other than the ternary operator, none of these have been a major issue for me. Granted,

I have been using Go in production since 2015 and can honestly say that other than the ternary operator, none of these have been a major issue for me. Granted, I am doing mostly REST API development so my use cases may be different, but I have never had an issue with capitalization or which interfaces are implemented. The tooling is by far some of the best I have used in a language. Paired with a good editor (I personally use VS Code on Ubuntu 18.04 as my main setup) and I have yet to miss exceptions or wonder what my code is capable of doing. That being said, Go isn't perfect by any stretch. Sometimes panic ins Go routines can be very hard to trace. The transition to Go modules is challenging for larger projects with versions beyond 1.x (when I started it was Glide, then dep, now go mod, which has been a bit frustrating). However, I wouldn't go back to Java, C#, PHP, or NodeJS if I had the choice. My go to in the server space is Go and Elixir. I don't feel a desire or need for anything else, but again, that's me. You know your use case better than a stranger on the internet :)

AlchemistCamp 7y ago
That's really interesting. How do you use Go with Elixir? I've never really gotten into Go, partially because I feel like there's a lot of overlap with what it does and what Elixir does. I could see using it for CLIs and various Unix scripting, but I've been doing that with Ruby, for the most part. I also considered learning Go for creating some native binaries for a few critical paths, but Rust seems like the best choice for that. A NIF that crashes is one of the few things that will take down the Erlang VM, so Rust's strong safety guarantees (might) make it worth the steep learning curve.
- Thaxll 7y ago
  For one Elixir is very slow compare to Go.
  - Herrin 7y ago
    For what purpose? See: https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixir/ https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi...
    - coder543 7y ago
      I feel like that article just supports the comment you're replying to. I mean, look at this: https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixir/100K-cpu.png https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi... If the article had gone up to 250K connections, Elixir would have fallen down similarly to what happened to Node... although the reasons for Node being unable to keep up were unclear in the article, and I think warranted further investigation that the article didn't do. For another comparison, feel free to click around on the tabs here: https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=query&l=zg1rzj-1 https://www.techempower.com/benchmarks/#section=data-r17&hw=... The plaintext benchmark is about as far from a computationally intensive task as you can get... it should basically be network-bound, supposedly an ideal task for the BEAM VM, yet the results are clear. If you turn on additional languages and frameworks, you'll note that Elixir or Erlang are significantly faster than, say, Rails, but Elixir or Erlang are a good 5x to 25x slower than Go. People have built massive, successful companies on Ruby on Rails, such as GitHub, so don't think that I'm discounting these languages wholesale. You just have to accept that you will be paying substantially higher infrastructure costs if your infrastructure needs begin scaling beyond a single server. If you think that Elixir or Ruby or whatever else is the secret sauce to make your company successful, go for it! But those are a lot slower than Go or Rust or other very fast languages.
      - liveoneggs 7y ago
        that cpu spike in BEAM is actually a runtime setting and doesn't reflect usage; it's intentionally busy-looping the connection accepts to reduce latency.
        coder543 7y ago
        huh. that seems like a lot of waste for no measurable benefit: https://stressgrid.com/blog/beam_cpu_usage/ https://stressgrid.com/blog/beam_cpu_usage/ maybe it's beneficial to someone, but I don't think that should be the default. either way, it doesn't change the picture painted by the TechEmpower benchmarks.
  - AlchemistCamp 7y ago
    Note that I wasn't asking why one would use Go instead of Elixir for a given task. If it's CPU bound, Go would be a better choice. My question was how the poster was using Go with Elixir. Since they have a big overlap in what they're commonly used for and since NIFs (Natively Invoked Functions) on the BEAM really need to be fail-safe, it's not as clear as how to use these two together as how one would use C in the same stack with Python, for example.
- losingthefight 7y ago
  Sorry if I wasn't clear. I don't really combine the two and use whichever makes the most sense. In my day to day, we are primary a Go microservices shop and are exploring Elixir for some video stuff. I've used some Elixir on side projects. Sorry I wasn't clear that I am not combining them, although I imagine if I was going to it would either be over some sort of gRPC implementation or using something like rabbit to hand over tasks.
  - AlchemistCamp 7y ago
    Ah, that makes sense!
sdegutis 7y ago
If you're just writing a REST API, I wonder, why did you choose Go for this instead of Java or Python?
- dfischer 7y ago
  I can comment on this on my own: 1. Java - did not want to adopt the entire ecosystem. This is very much wanted a banana and got the whole jungle with a gorilla type of story. 2. Python - dynamic. Don't want that. Go's minimal typing is perfect. It's easy to deploy (binaries). It's fast. It can scale well. It's opinionated (love this). Python and Java both encourage and allow developers to flex creative solutions that are hard to maintain long-term. Sure, seniority helps with that, and being part of a good team; however using Go, you just run into that less due to the conciseness of the language and strong idioms.
  - jayd16 7y ago
    You can write small Java services. You really don't need Spring or anything. You should try it some time.
    - dfischer 7y ago
      I think Java is ok. I just don't like all the weight you inherit with the ecosystem. There's a lot of buttons you have to learn and history. It's working a submarine vs purposed craft (bad example).
    - tomohawk 7y ago
      You can, but you can't deploy them. If you really want to keep your services separate, you need a separate JVM installation and jars for each service. Go gives you this automatically with a simple binary. Go's standard library is an order of magnitude (at least) better than Java's, much more comprehensive, much more cohesive, and much more capable.
      - carterehsmith 7y ago
sdegutis 7y ago
The "Capitalization feature" is actually objectively worse because of the reason OP mentioned, of having to rename all semi-local usages when visibility changes. But good IDEs can help mitigate the difficulty of this. But even more significant is that the Go authors cannot seem to grasp the importance of pre-existing conventions. Almost every language I've used in the past decade allows and encourages the variable, Class, CONSTANT convention. It reminds me of people who want everyone to use CE and BCE instead of AD and BC, ignoring the inertia and relevance of the latter and almost seeming like we live in a vacuum where fresh ideas have as equal weight as old ones, and history doesn't matter at all. I don't know how to explain this better, but this is basically the core reason I don't like Go, above and beyond any specific features or lack of features. I once heard Go described as "what if we took the good ideas of C and started from scratch?" But it feels like they take that very literally, as if they were saying, "what if it was actually 1970 right now, and we didn't have C, and the next 49 years never happened?" (This is a separate reply than my other one because someone already upvoted that.)
- jayd16 7y ago
  WRT renaming, I find that refactoring code is often such an oversight from language designers. I consider C# to be an elegant language in this way. Public fields and properties look the same in C# so you can effortlessly refactor between them, for example. I wish more languages thought about this stuff.
  - pjmlp 7y ago
    A design introduced by Eiffel, copied by Delphi, before Anders went to Microsoft designed J++ and then C#, with the said feature.
  - sdegutis 7y ago
    I liked a similar aspect of Ruby: attributes and 0-args methods had the same syntax, so you could easily refactor a static field into a method that returns a dynamically calculated value. Overall I don't like that feature, but that was a very handy aspect of it.
tomohawk 7y ago
After a long stint in enterprise Java land, Go was a really big adjustment. Mostly about letting go of unnecessary complexity. I didn't realize how much I didn't miss that complexity until I recently went back into Java. If you learn the golang way of doing things, the issues this guy mentions really are not something you run into.
- jstewartmobile 7y ago
  One of the commenters on lobste.rs called boilerplate-heavy Go written by programmers coming from Java "Gova". From a lot of what I've seen, that is a useful description.
  - masklinn 7y ago
    > One of the commenters on lobste.rs called boilerplate-heavy Go written by programmers coming from Java "Gova". Not exactly a novel take: https://dirtsimple.org/2004/12/python-is-not-java.html https://dirtsimple.org/2004/12/python-is-not-java.html
  - didibus 7y ago
    I think Go will suffer the same fate as Java. Any enterprise language that becomes too popular will slowly devolve into an enterprise monster. If you come to Java with a blank slate, and try using it with simplicity in mind. There's not much wrong with it. But once people add design patterns, layers of layers, reflection, annotations. Etc. You get a monster. And somehow, the enterprise world seems to always create those.
    - astrange 7y ago
      The problem with Java is that there isn't enough of it to have anything wrong with it. The programs have all those design patterns because the language lacks so much power that you have to write it all yourself. For instance, having value types would really help. The one thing they should take away is namespaces. You can't write unreadable enterprise software if you can't put every 10-line class six packages deep for no reason.
pstuart 7y ago
Agreed on the ternary operator.
User23 7y ago
I've been entirely satisfied with Go when using it to interact with kubernetes and AWS and do what doesn't amount to much more than CRUD and logging. I've never implemented any non-trivial algorithms with it though, which is what the article appears to be about.

AlchemistCamp 7y ago

That's really interesting. How do you use Go with Elixir? I've never really gotten into Go, partially because I feel like there's a lot of overlap with what it does and what Elixir does. I could see using it for CLIs and various Unix scripting, but I've been doing that with Ruby, for the most part. I also considered learning Go for creating some native binaries for a few critical paths, but Rust seems like the best choice for that. A NIF that crashes is one of the few things that will take down the Erlang VM, so Rust's strong safety guarantees (might) make it worth the steep learning curve.

Thaxll 7y ago
For one Elixir is very slow compare to Go.
- Herrin 7y ago
  For what purpose? See: https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixir/ https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi...
  - coder543 7y ago
    I feel like that article just supports the comment you're replying to. I mean, look at this: https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixir/100K-cpu.png https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi... If the article had gone up to 250K connections, Elixir would have fallen down similarly to what happened to Node... although the reasons for Node being unable to keep up were unclear in the article, and I think warranted further investigation that the article didn't do. For another comparison, feel free to click around on the tabs here: https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=query&l=zg1rzj-1 https://www.techempower.com/benchmarks/#section=data-r17&hw=... The plaintext benchmark is about as far from a computationally intensive task as you can get... it should basically be network-bound, supposedly an ideal task for the BEAM VM, yet the results are clear. If you turn on additional languages and frameworks, you'll note that Elixir or Erlang are significantly faster than, say, Rails, but Elixir or Erlang are a good 5x to 25x slower than Go. People have built massive, successful companies on Ruby on Rails, such as GitHub, so don't think that I'm discounting these languages wholesale. You just have to accept that you will be paying substantially higher infrastructure costs if your infrastructure needs begin scaling beyond a single server. If you think that Elixir or Ruby or whatever else is the secret sauce to make your company successful, go for it! But those are a lot slower than Go or Rust or other very fast languages.
    - liveoneggs 7y ago
      that cpu spike in BEAM is actually a runtime setting and doesn't reflect usage; it's intentionally busy-looping the connection accepts to reduce latency.
      - coder543 7y ago
        huh. that seems like a lot of waste for no measurable benefit: https://stressgrid.com/blog/beam_cpu_usage/ https://stressgrid.com/blog/beam_cpu_usage/ maybe it's beneficial to someone, but I don't think that should be the default. either way, it doesn't change the picture painted by the TechEmpower benchmarks.
- AlchemistCamp 7y ago
  Note that I wasn't asking why one would use Go instead of Elixir for a given task. If it's CPU bound, Go would be a better choice. My question was how the poster was using Go with Elixir. Since they have a big overlap in what they're commonly used for and since NIFs (Natively Invoked Functions) on the BEAM really need to be fail-safe, it's not as clear as how to use these two together as how one would use C in the same stack with Python, for example.
losingthefight 7y ago
Sorry if I wasn't clear. I don't really combine the two and use whichever makes the most sense. In my day to day, we are primary a Go microservices shop and are exploring Elixir for some video stuff. I've used some Elixir on side projects. Sorry I wasn't clear that I am not combining them, although I imagine if I was going to it would either be over some sort of gRPC implementation or using something like rabbit to hand over tasks.
- AlchemistCamp 7y ago
  Ah, that makes sense!

sdegutis 7y ago

If you're just writing a REST API, I wonder, why did you choose Go for this instead of Java or Python?

dfischer 7y ago
I can comment on this on my own: 1. Java - did not want to adopt the entire ecosystem. This is very much wanted a banana and got the whole jungle with a gorilla type of story. 2. Python - dynamic. Don't want that. Go's minimal typing is perfect. It's easy to deploy (binaries). It's fast. It can scale well. It's opinionated (love this). Python and Java both encourage and allow developers to flex creative solutions that are hard to maintain long-term. Sure, seniority helps with that, and being part of a good team; however using Go, you just run into that less due to the conciseness of the language and strong idioms.
- jayd16 7y ago
  You can write small Java services. You really don't need Spring or anything. You should try it some time.
  - dfischer 7y ago
    I think Java is ok. I just don't like all the weight you inherit with the ecosystem. There's a lot of buttons you have to learn and history. It's working a submarine vs purposed craft (bad example).
  - tomohawk 7y ago
    You can, but you can't deploy them. If you really want to keep your services separate, you need a separate JVM installation and jars for each service. Go gives you this automatically with a simple binary. Go's standard library is an order of magnitude (at least) better than Java's, much more comprehensive, much more cohesive, and much more capable.
    - carterehsmith 7y ago

sdegutis 7y ago

The "Capitalization feature" is actually objectively worse because of the reason OP mentioned, of having to rename all semi-local usages when visibility changes. But good IDEs can help mitigate the difficulty of this. But even more significant is that the Go authors cannot seem to grasp the importance of pre-existing conventions. Almost every language I've used in the past decade allows and encourages the variable, Class, CONSTANT convention. It reminds me of people who want everyone to use CE and BCE instead of AD and BC, ignoring the inertia and relevance of the latter and almost seeming like we live in a vacuum where fresh ideas have as equal weight as old ones, and history doesn't matter at all. I don't know how to explain this better, but this is basically the core reason I don't like Go, above and beyond any specific features or lack of features. I once heard Go described as "what if we took the good ideas of C and started from scratch?" But it feels like they take that very literally, as if they were saying, "what if it was actually 1970 right now, and we didn't have C, and the next 49 years never happened?" (This is a separate reply than my other one because someone already upvoted that.)

jayd16 7y ago
WRT renaming, I find that refactoring code is often such an oversight from language designers. I consider C# to be an elegant language in this way. Public fields and properties look the same in C# so you can effortlessly refactor between them, for example. I wish more languages thought about this stuff.
- pjmlp 7y ago
  A design introduced by Eiffel, copied by Delphi, before Anders went to Microsoft designed J++ and then C#, with the said feature.
- sdegutis 7y ago
  I liked a similar aspect of Ruby: attributes and 0-args methods had the same syntax, so you could easily refactor a static field into a method that returns a dynamically calculated value. Overall I don't like that feature, but that was a very handy aspect of it.

tomohawk 7y ago

After a long stint in enterprise Java land, Go was a really big adjustment. Mostly about letting go of unnecessary complexity. I didn't realize how much I didn't miss that complexity until I recently went back into Java. If you learn the golang way of doing things, the issues this guy mentions really are not something you run into.

jstewartmobile 7y ago
One of the commenters on lobste.rs called boilerplate-heavy Go written by programmers coming from Java "Gova". From a lot of what I've seen, that is a useful description.
- masklinn 7y ago
  > One of the commenters on lobste.rs called boilerplate-heavy Go written by programmers coming from Java "Gova". Not exactly a novel take: https://dirtsimple.org/2004/12/python-is-not-java.html https://dirtsimple.org/2004/12/python-is-not-java.html
- didibus 7y ago
  I think Go will suffer the same fate as Java. Any enterprise language that becomes too popular will slowly devolve into an enterprise monster. If you come to Java with a blank slate, and try using it with simplicity in mind. There's not much wrong with it. But once people add design patterns, layers of layers, reflection, annotations. Etc. You get a monster. And somehow, the enterprise world seems to always create those.
  - astrange 7y ago
    The problem with Java is that there isn't enough of it to have anything wrong with it. The programs have all those design patterns because the language lacks so much power that you have to write it all yourself. For instance, having value types would really help. The one thing they should take away is namespaces. You can't write unreadable enterprise software if you can't put every 10-line class six packages deep for no reason.

pstuart 7y ago

Agreed on the ternary operator.

User23 7y ago

I've been entirely satisfied with Go when using it to interact with kubernetes and AWS and do what doesn't amount to much more than CRUD and logging. I've never implemented any non-trivial algorithms with it though, which is what the article appears to be about.