8 ms·

If all you know is a Hammer… I was searching for reasons why to use the Go-Hammer when there are comparable ones such as Java, C#, etc. but the article left me

If all you know is a Hammer… I was searching for reasons why to use the Go-Hammer when there are comparable ones such as Java, C#, etc. but the article left me wanting. It strikes me that Go is riding the peak of hype languages, succeeding Rust and Node.js (which are all good pieces of technology and absolutely have their merit). And like with most hype driven decisions there is little (self) awareness of context and alternatives. Note, this is explicitly not about the languages themselves, but rather the larger cult(ure) of mainstream programmers around them.

Scarblac 2y ago
I think he could have chosen those alternatives just as well, he just happened to pick Go. His argument is that he strives to use his chosen tool in as many situations as possible instead of having a bunch of different ones.
- markusw 2y ago
  Yup, this exactly!
busterarm 2y ago
> It strikes me that Go is riding the peak of hype languages. Very much so. Also it seems to be a strange choice as a solo developer when its strengths are explicitly targeted at large organizations. And I think the tooling is actually a bit of a mess compared to some other options. God help you if as a solo developer you start building on top of protobufs (another basically default choice in the Golang world...). I just don't understand why you wouldn't choose something faster and more expressive.
- ergonaught 2y ago
  > I just don't understand why you wouldn't choose something faster and more expressive. The answer to this is as simple as genuinely asking, answering, and understanding why you don't do all of your development in assembly language.
  - busterarm 2y ago
    I didn't mean faster in terms of execution time but in terms of development time. And more expressive is doing more with less code. We're at complete opposite ends of the spectrum here -- how that indicated to you that I meant assembly...
    - ergonaught 2y ago
      It's the same principle. My own experience (I'm not the author) is that the investment required to reach the point where Go can be a "hammer" as in this case is lower (usually significantly lower) than with "faster and more expressive" languages.
    - whstl 2y ago
      Go might not be the most concise or expressive language, but it's quite fast in terms of development time, IMO/IME.
      - Cthulhu_ 2y ago
        Yeah, you just write code without worrying about whether it can be done more concise or clever, it's a very pragmatic language. The downside is code volume, but honestly that is rarely the problem in software.
    - danielvaughn 2y ago
      I'm genuinely curious which language you see as having a better development time. I don't mean that as arguing, I'm actually curious. I don't know much about Go but I just began learning it 2 days ago. I'm already 50% of the way done through a really nice TUI app, and I haven't even touched the docs. To me at least, it feels extremely productive so far.
      - laserlight 2y ago
        Developing with Python is faster.
- Thaxll 2y ago
  Protobuf is not the default in Go the default is REST. What tools are a mess? Go tooling ( runtime ) and IDE integration is very good. Go is not a hyped language, we're past that cycle, some critical and widely used software are built in Go, millions of people rely on it.
  - busterarm 2y ago
    Bazel. While not Go-specific, it's the extremely popular option in the space and I've seen it bring many-a-seasoned wizard to their knees in tears. Also managing your go dependencies if you cargo-cult other Google behaviors like monorepos tends to be painful. Basically just cargo-culting Google behavior == pain. Choosing golang can often be part of this behavior pattern.
    - tail_exchange 2y ago
      Bazel is not a Go default either. You can get very far just by using the default Go Modules, and this is much more common than repos using Bazel. Throw some Makefiles and shell scripts in the mix, if that's your thing, and that's perfectly fine.
      - busterarm 2y ago
        Obviously but if you look at a lot of Go projects you tend to see it. Especially in a corporate space. It should be obvious that I'm referring to things that you see in a professional environment with professional standards. I'm getting a lot of hate where that seems to be lost on people. And even if someone is a solo developer I don't assume that they don't ever have to work with other people's code -- that certainly wasn't my experience when solo contracting.
        tail_exchange 2y ago
        Because you are attributing things that are common in enterprise environments (Bazel, monorepos, and Protobufs) to Go. It's fine if you hate these things, but saying that these are the defaults of Go isn't right, and I bet that's why people are hating on you. There's nothing default about them in Go. If you work with enterprise-y code, it shouldn't be surprising that a lot of them are going to follow Google's steps.
- markusw 2y ago
  Author here. Well, it has worked pretty well for me so far, so I don't know why I would switch. Go is fast and expressive enough for my use, and it's probably outweighed by being super familiar anyway. (BTW, in my eight years of Go, I think I've used protobufs maybe once or twice. HTTP FTW!)
- azthecx 2y ago
  Do you have better alternatives to Protobuf? What are the shortcomings that you find with it? At work these choices have been out of my hands but I've used JSON Avro and Protobuf and I felt like Protobuf was the least prone to errors, best surrounding tooling and easy migrations while maintaining small payloads.
- azthecx 2y ago
  Do you have better alternatives to Protobuf? What are the shortcomings that you find with it? At work these choices have been out of my hands but I've used JSON Avro and Protobuf and I felt like Protobuf was the least prone to errors, best surrounding tooling and easy migrations while maintaining small payloads.
- jimbokun 2y ago
  Faster on what axis? Go has maybe the fastest compile times, for example. Which is very important when you are iterating on a project. What do you dislike about the tool chain? Seems better than most languages to me.
  - kaba0 2y ago
    Java’s toolchain may leave some to be desired in ergonomics, but compile time is just as fast if not faster.
    - DarkNova6 2y ago
      What do you see missing in the Java toolchain? Frankly, I see it as one of the most complete and deep of all languages.
      - kaba0 2y ago
        Only ergonomics, I do actually like most of it (maven central/repository model and gradle). It is one of two truly general build tools (other being Bazel), and being that generic/capable does mean that it can’t be as user friendly as a single-language build tool like Go’s or Rust’s. But these all break down the moment you introduce another language/build step/whatever, while Gradle can build the whole hodgepodge that is the Android platform just fine, which is quite a testament to its power.
moomin 2y ago
I think it’s fine. Honestly I think there’s a lot more deep developers out there than broad developers. It’s just they don’t blog about depth the way broad developers blog about their shiny new toy.
kamikaz1k 2y ago
Go is getting hype because TS is old news. And people got tired of being nerd sniped into trying Rust and being let down. It’s okay, hype cycles are good since it shakes up mainstream opinion and gets people to try stuff. Like a new trendy food. I don’t feel much in the ways about it. How do you feel about Go outside of the hype cycle?
- auggierose 2y ago
  How is Go not older news than TS?
  - danielvaughn 2y ago
    I think hype is more about trends than it is about age. PHP is going through a bit of a hype phase right now, for instance, mostly because of Laravel and the fact that the language has been silently improving a lot since the wordpress days, and developers are just now starting to realize it.
    - markusw 2y ago
      I believe there are many different hype cycles at once, depending on ones vantage point. The world is large!
- DarkNova6 2y ago
  > Go is getting hype because TS is old news. And people got tired of being nerd sniped into trying Rust and being let down. Sounds like my impression as well. > How do you feel about Go outside of the hype cycle? I think it's in a weird place, but I have a much higher opinion of the language ever since it got generics. There is nothing which is inherently unique to Go, but it got some neat technical features: Static compilation, garbage collection, good model for multithreading, fast compilation times. With these qualities you can get pretty far and have good cloud readiness. However, I'm a Java guy and the JVM is my working horse. I have seen how large projects (don't) scale once you have 8+ developers and there are shortcomings in Go for projects of this size. And I think the explicit nature of nominal typing (e.g. Java) absolutely wins over the implicit structural typing one (e.g Go). You see this difference of philosophies by interface constraints: Java interfaces must be implemented explicitly and you can even limit who can implement them. Java is primarily a language designed for libraries & frameworks and the quality shows it. With structural and open implementation of interfaces, your line of code-ownership becomes blurry. This is not nearly as problematic as dynamic typing, but in my mind an interface is a specification. And you there should be a contract between the provider and consumer. This also helps with understanding the connections inside/between code-bases. Same about interfaces can be said about First Class Functions vs. Functional Interfaces. Functional Interfaces can be documented, domain-specific, extended and implemented. It feels like a perfect blend of FP and OOP, whereas with First Class Functions I feel like I am working with C-stylee primitives which don't help me express the nature of the solution I want to model nearly as much. As for Java, I have an immeasurable amount of respect for the current language designers (can't say I have the same respect for Go Designers after the drama surrounding generics). I am an avid reader of their mailing list and time and time again, they have shown deep thought and tremendous foresight (their way of work is quite inspiring). Yes, they have to live with some nasty historical baggage, but they have a very high level of quality. Then there are aspects such as the ever-evolving JVM, along with its choice of several garbage collectors and top-tier runtime analysis (Flight Recorder) & optimization (Hot Spot). Sorry, this is entirely subjective but you asked me how I "feel" about it :-) Summing it up, I'd say Go is a comfortable local maximum which can give you a whole lot, but ultimately is less flexible. But it's surely enough for 90% of applications. In this sense Go is like the big brother of PHP, which is a perfectly reasonable language if all you need in your backend are save/load database operations. Go can cope with that too, but also scale into non-trivial domains, the cloud and multi-threaded problems. But Java is "corpoaraty" and not "trendy", so most people don't even consider it as an option. And there are enough bad devs who started their carreer in JS/TS and want to move towards something more performant, that is still as ad-hoc and don't mind sharp edges because they never learned to reason about their application in a more formal sense. But looking at the work that is currently being done to the JVM, I'm looking forward to the near future when we can run Java-compatible bytecode on GPUs and AVX512.
neonsunset 2y ago
Thanks for posting this. It’s an unfortunate choice of “one hammer to rule them all” given Go does not offer necessary coverage at both low and high ends of abstraction (and performance) the way C# does. For me, it’s a similar kind of hammer. (I prefer to think of it as a crowbar ;D)
- mapcars 2y ago
  The problem with C# is its created by Microsoft, even if its a good language its hard to look at it and not think how much its limited while used outside of Windows.
  - neonsunset 2y ago
    It seems that you might be asking this question in bad faith. But on the off chance you are not, please find previous replies that address the same kind of question below: https://news.ycombinator.com/item?id=41037792 https://news.ycombinator.com/item?id=41037792 https://news.ycombinator.com/item?id=41189309 https://news.ycombinator.com/item?id=41189309 https://news.ycombinator.com/item?id=41211767 https://news.ycombinator.com/item?id=41211767 https://news.ycombinator.com/item?id=41197493 https://news.ycombinator.com/item?id=41197493 https://news.ycombinator.com/item?id=41218353 https://news.ycombinator.com/item?id=41218353
    - mapcars 2y ago
      I understand its probably not the case today, just that C# shares some of the MS reputation and its hard to get rid of. Especially when there are dozens of open-source independent languages around.
      - neonsunset 2y ago
        I think phrasing with insistence that it is "probably not the case today" despite demonstrable evidence of certainty means that the motivation for this reply was not to learn something new or share something you know but to try to get a raise with low-effort bait. This is both tiresome and goes against guidelines. Somehow we all can normally discuss programming languages without bringing practices of Google or Oracle into the picture and focus instead on programming language development initiatives that they drive and sponsor, that are themselves sufficiently independent. Let's keep it that way. Also https://news.ycombinator.com/item?id=41218353 https://news.ycombinator.com/item?id=41218353 (which was the last link in the list).
markusw 2y ago
I wasn't aiming for that. My point is more: I know Go already, it's good enough for my purposes, so I'm using that as my hammer. I could just as well have been Java or C# I learned eight years ago and used that for everything. :)
- danielvaughn 2y ago
  I just began using Go literally 2 days ago, but I could already see building most of my projects in it from here on out. It has the type system I'd need from Java or C#, while being almost as simple and readable as Python. I love the module system so far and enjoy not having to decide on my own formatter. Go is perfectly boring and simple, and seems to get out of my way. At least, that's how it feels as a newcomer. I'm sure it will change over time, but I'm having a blast at the moment.
  - markusw 2y ago
    It actually gets even better! :D Enjoy the journey!
  - kamaal 2y ago
    What about the absence of exception handling? Plus OO has its own advantages, even if you don't use it all that much, its one of the best ways to fit problems into neat design patterns. Go seems to be missing those features.
    - danielvaughn 2y ago
      This is my first time working with a language that exclusively uses errors as values, and I haven't had time to develop any strong feelings about it. So far it feels nice because it makes error handling crystal clear, but I could also see it becoming cumbersome over time.
      - jimbokun 2y ago
        It can get verbose, but I'm willing to live with it for all the other benefits of the language.
jimbokun 2y ago
I'll give it a shot. The tools make a lot of decisions for you that are pretty arbitrary, like how to format code, freeing up brain cycles for other things. It compiles very fast, so the iteration cycle is similar to a dynamic language with a REPL. Very little time between making a change, running and seeing the new result. The language is designed from the bottom up for fast compile times even in large projects, with features at odds with fast compilation rejected. Decent sized community and library ecosystem. The networking APIs are very simple and productive. More and more back end code is being written in Go for this reason. The semantics are straight forward. The other programming environment I need to deal with at work is Spring Java, which is unjustifiably complex and obfuscated for what it does. Go allows you to read the code and run the program in your head understanding semantics and performance characteristics. Builds single file executables that are simple to deploy. Has just enough high level features to be productive without compromising above points about simplicity, fast compiles, and comprehensibility. Channels and go routines work very well to model concurrency across a wide array of problem domains. Maintainers are careful about adding new features. Generics took a long time to arrive, but when it did was very well thought out and did not negatively impact performance very much. I'm sure I'll think of more.
alemanek 2y ago
I am someone with significant experience in Java, C#, C++, and JS/TS. I am a bit of a newbie to Go but have used it for a few things at work. So, I can give a bit of a comparison for you. I really like the DevX and strong standard library of Go. Also I really like that the community around Go has a strong preference for just using the stdlib and not going crazy with third party libraries. Languages are just tools but I have a strong preference for Go for backend services and CLI applications now. Just my 2cents.
- DarkNova6 2y ago
  Hey, thanks for the reply. That sounds really nice! I wonder, which aspects of the "Go" std lib are considered strong? Would you say it is more like .net where the std-lib also comes with framework-grade capabilities such as REST-endpoints and setting up applications? Because in the classical sense of a library, I think Java is fantastic (collections, strings, NIO, HTTP 2.0, etc.). But it misses framework-level out-of-the-box solutions.
  - metaltyphoon 2y ago
    Not STD comes close to .NET, IMO.
  - alemanek 2y ago
    So take this with a big mountain of salt as I am newer to Go and my experience with .Net is a bit dated but I do have 7 YoE with C#. The C# stdlib is larger and more batteries included for sure. But, it feels less focused than Go to me. Over its history it has supported a ton of different styles of programming. Whereas Go’s maintainers have been, at least so far, more obsessive on keeping the language small. As a result you get libraries and codebases that have a mix of legacy and modern flavors of .NET. That isn’t the fault of the language but more of its large history and wider scope. GoLang doesn’t have a rich UI library built in for example whereas .NET has 3 if I am remembering correctly. I like the focus of Go but C# is a great language and .NET is an excellent framework. Here are some things that I think Go does better though: - TLS and x509 stdlib is fantastic - Explicit error returns instead of Exception throwing - A developer culture around idiomatic Go. It’s subjective but it sets a tone for a single coding style. - Less “magic”. This is more of a sin of Java frameworks but .NET has lots of higher level abstractions the push lots of interactions behind the curtain. - tiny docker images and super fast startup. Here are some things I miss from C#: - really nice Enums - Better support for functional programming. - LINQ to objects - Annotations, specifically validation logic as annotations. - JSON handling is more straightforward .NET is super capable though. Nothing wrong with using it and it is much more broadly applicable than Go in my opinion. But, I like the ergonomics of Go and for backend services and CLI tools I think it is a strong choice. But, I wouldn’t choose it to build a game or a desktop/mobile GUI application currently.
daghamm 2y ago
How can you call Go hype driven? It was literally designed to be "boring".
- cy_hauser 2y ago
  I think it was the Go Marketing Team who decided to call it a boring language. "Boring" tested well for hyping the language.
gnfargbl 2y ago
It feels extremely strange to see Go described as a "hype" language. It was somewhat hyped around seven years ago, which is when I started using it almost exclusively. Before that, it had a strong hype peak about fourteen or fifteen years ago, just after it was born. However, it's not a young language any more. At this point I would actually submit the opposite criticism: it is a mature language which is perhaps starting to suffer from middle-aged spread, as the bored maintainers start to stuff in more features which the language doesn't genuinely need. (Example: Iterators. Sure they're nice, but does the language really need them?) If anything, I would say it's going more the way of Java than Rust or Node.
- kaba0 2y ago
  Count the number of posts with Go in the title, vs any other programming language. It easily beats out everything both here and on lobsters.
  - gnfargbl 2y ago
    Well, it's a very usable language which is strongly typed (by any layman's definition), easy to pick up, easy to get stuff done in, relatively easy to live with and easy to maintain. If it's hyped then it's only in the same way The Beatles and Pizza are hyped.
    - markusw 2y ago
      I like that! Go is basically pizza! :D
  - kjksf 2y ago
    Maybe, but 80% of those are complains of some sort. That's the opposite of hype.
  - cy_hauser 2y ago
    I did this about 1-1/2 years ago and just reran the numbers. Today: "written|built in Rust" 1113 (1036|77) "written|built in Go/Golang" 1050 (889|25) / (119|17) "written|built in Python": 452 (422|30) "written|built in Javascript/JS" 286 (233|14) / (34|5) "written|built in Java" 115 (109|6) "written|built in TypeScript" 97 (89|8) "written|built in C#" 46 (43|3) "written|built in Stone" 13 (13|0) Feb 2023 "written|built in Go/Golang" 918 (792|17) / (102|7) "written|built in Rust" 832 (790|42) "written|built in Python": 390 (364|26) "written|built in Javascript/JS" 269 (220|14) / (32|3) "written|built in Java" 107 (101|6) "written|built in TypeScript" 66 (61|5) "written|built in C#" 41 (38|3) "written|built in Stone" 10 (10|0)
bborud 2y ago
I think the hype has already peaked for Go. When we switched to Go 8-9 years ago I already felt the hype had died down. We were late to the party. And I saw that as a good thing. To me it suggested Go was going to stick around. And now, almost a decade later, we're still using it. Note that at my company, we're a bunch of grumpy old guys with about 30 years of experience each. If you dangle a new and shiny language in front of us, our default instinct is to tell people to get lost. We don't do "fashionable". We tend to make investments in learning languages that we expect to get at least a decade out of. And I don't think Go is succeeding Rust. From what I can tell, people are going in both directions.
- jerf 2y ago
  Go and Node have some significant overlap, but Go and Rust are barely even competitors. Of course there's a lot of programs that you can use either to write. There's a lot of programs where it hardly even matters which language you pick at all because they're all perfectly acceptable solutions, though, so that really isn't saying much. But if you map languages out by the programs where language choice matters at least a little and where a given language is legitimately one of the top contenders, Go and Rust don't have a particularly strong amount of overlap in my opinion. They do, but again, lots of languages have overlap; I don't see the Rust/Go relationship being particularly heavily overlapping. (Go/Java or Rust/C++, now there's overlap, for comparison.)
  - bborud 2y ago
    > Go and Node have some significant overlap, but Go and Rust are > barely even competitors. Among the people I know Go and Rust seem to be at the top of their list. Almost all people I know who program Rust also know Go. Not as many Go programmers I know program in Rust as well, but some know Rust and even more want to learn it. Which probably isn't too peculiar because Rust is more of a kerfuffle to program in. I'm not denying your observation. I'm just reporting that from where I am, things look a bit different. I agree that it mostly doesn't matter that much which language you choose -- as long as it is a language that can meet certain minimum standards. In my view there is only about a handful of languages to actually choose from. The first is that it must be possible to produce proper binaries. For instance, Python is unacceptable to me since it tends to place a large burden on the user. Next, it has to be a somewhat mainstream language with a sufficiently large community. With that sorted the more technical stuff needs to be evaluated. Like its standard library, how ergonomic the tooling, what quality software/libraries the community produces is etc.
gavindean90 2y ago
Honestly it gave me the feeling of not arguing to use Go but instead arguing to use the full featured language you know the best. The caveat being that it is of you are a single developer making all the decisions and writing all the code. Seemed to make a good case for that

Scarblac 2y ago

I think he could have chosen those alternatives just as well, he just happened to pick Go. His argument is that he strives to use his chosen tool in as many situations as possible instead of having a bunch of different ones.

markusw 2y ago
Yup, this exactly!

busterarm 2y ago

> It strikes me that Go is riding the peak of hype languages. Very much so. Also it seems to be a strange choice as a solo developer when its strengths are explicitly targeted at large organizations. And I think the tooling is actually a bit of a mess compared to some other options. God help you if as a solo developer you start building on top of protobufs (another basically default choice in the Golang world...). I just don't understand why you wouldn't choose something faster and more expressive.

ergonaught 2y ago
> I just don't understand why you wouldn't choose something faster and more expressive. The answer to this is as simple as genuinely asking, answering, and understanding why you don't do all of your development in assembly language.
- busterarm 2y ago
  I didn't mean faster in terms of execution time but in terms of development time. And more expressive is doing more with less code. We're at complete opposite ends of the spectrum here -- how that indicated to you that I meant assembly...
  - ergonaught 2y ago
    It's the same principle. My own experience (I'm not the author) is that the investment required to reach the point where Go can be a "hammer" as in this case is lower (usually significantly lower) than with "faster and more expressive" languages.
  - whstl 2y ago
    Go might not be the most concise or expressive language, but it's quite fast in terms of development time, IMO/IME.
    - Cthulhu_ 2y ago
      Yeah, you just write code without worrying about whether it can be done more concise or clever, it's a very pragmatic language. The downside is code volume, but honestly that is rarely the problem in software.
  - danielvaughn 2y ago
    I'm genuinely curious which language you see as having a better development time. I don't mean that as arguing, I'm actually curious. I don't know much about Go but I just began learning it 2 days ago. I'm already 50% of the way done through a really nice TUI app, and I haven't even touched the docs. To me at least, it feels extremely productive so far.
    - laserlight 2y ago
      Developing with Python is faster.
Thaxll 2y ago
Protobuf is not the default in Go the default is REST. What tools are a mess? Go tooling ( runtime ) and IDE integration is very good. Go is not a hyped language, we're past that cycle, some critical and widely used software are built in Go, millions of people rely on it.
- busterarm 2y ago
  Bazel. While not Go-specific, it's the extremely popular option in the space and I've seen it bring many-a-seasoned wizard to their knees in tears. Also managing your go dependencies if you cargo-cult other Google behaviors like monorepos tends to be painful. Basically just cargo-culting Google behavior == pain. Choosing golang can often be part of this behavior pattern.
  - tail_exchange 2y ago
    Bazel is not a Go default either. You can get very far just by using the default Go Modules, and this is much more common than repos using Bazel. Throw some Makefiles and shell scripts in the mix, if that's your thing, and that's perfectly fine.
    - busterarm 2y ago
      Obviously but if you look at a lot of Go projects you tend to see it. Especially in a corporate space. It should be obvious that I'm referring to things that you see in a professional environment with professional standards. I'm getting a lot of hate where that seems to be lost on people. And even if someone is a solo developer I don't assume that they don't ever have to work with other people's code -- that certainly wasn't my experience when solo contracting.
      - tail_exchange 2y ago
        Because you are attributing things that are common in enterprise environments (Bazel, monorepos, and Protobufs) to Go. It's fine if you hate these things, but saying that these are the defaults of Go isn't right, and I bet that's why people are hating on you. There's nothing default about them in Go. If you work with enterprise-y code, it shouldn't be surprising that a lot of them are going to follow Google's steps.
markusw 2y ago
Author here. Well, it has worked pretty well for me so far, so I don't know why I would switch. Go is fast and expressive enough for my use, and it's probably outweighed by being super familiar anyway. (BTW, in my eight years of Go, I think I've used protobufs maybe once or twice. HTTP FTW!)
azthecx 2y ago
Do you have better alternatives to Protobuf? What are the shortcomings that you find with it? At work these choices have been out of my hands but I've used JSON Avro and Protobuf and I felt like Protobuf was the least prone to errors, best surrounding tooling and easy migrations while maintaining small payloads.
azthecx 2y ago
Do you have better alternatives to Protobuf? What are the shortcomings that you find with it? At work these choices have been out of my hands but I've used JSON Avro and Protobuf and I felt like Protobuf was the least prone to errors, best surrounding tooling and easy migrations while maintaining small payloads.
jimbokun 2y ago
Faster on what axis? Go has maybe the fastest compile times, for example. Which is very important when you are iterating on a project. What do you dislike about the tool chain? Seems better than most languages to me.
- kaba0 2y ago
  Java’s toolchain may leave some to be desired in ergonomics, but compile time is just as fast if not faster.
  - DarkNova6 2y ago
    What do you see missing in the Java toolchain? Frankly, I see it as one of the most complete and deep of all languages.
    - kaba0 2y ago
      Only ergonomics, I do actually like most of it (maven central/repository model and gradle). It is one of two truly general build tools (other being Bazel), and being that generic/capable does mean that it can’t be as user friendly as a single-language build tool like Go’s or Rust’s. But these all break down the moment you introduce another language/build step/whatever, while Gradle can build the whole hodgepodge that is the Android platform just fine, which is quite a testament to its power.

moomin 2y ago

I think it’s fine. Honestly I think there’s a lot more deep developers out there than broad developers. It’s just they don’t blog about depth the way broad developers blog about their shiny new toy.

kamikaz1k 2y ago

Go is getting hype because TS is old news. And people got tired of being nerd sniped into trying Rust and being let down. It’s okay, hype cycles are good since it shakes up mainstream opinion and gets people to try stuff. Like a new trendy food. I don’t feel much in the ways about it. How do you feel about Go outside of the hype cycle?

auggierose 2y ago
How is Go not older news than TS?
- danielvaughn 2y ago
  I think hype is more about trends than it is about age. PHP is going through a bit of a hype phase right now, for instance, mostly because of Laravel and the fact that the language has been silently improving a lot since the wordpress days, and developers are just now starting to realize it.
  - markusw 2y ago
    I believe there are many different hype cycles at once, depending on ones vantage point. The world is large!
DarkNova6 2y ago
> Go is getting hype because TS is old news. And people got tired of being nerd sniped into trying Rust and being let down. Sounds like my impression as well. > How do you feel about Go outside of the hype cycle? I think it's in a weird place, but I have a much higher opinion of the language ever since it got generics. There is nothing which is inherently unique to Go, but it got some neat technical features: Static compilation, garbage collection, good model for multithreading, fast compilation times. With these qualities you can get pretty far and have good cloud readiness. However, I'm a Java guy and the JVM is my working horse. I have seen how large projects (don't) scale once you have 8+ developers and there are shortcomings in Go for projects of this size. And I think the explicit nature of nominal typing (e.g. Java) absolutely wins over the implicit structural typing one (e.g Go). You see this difference of philosophies by interface constraints: Java interfaces must be implemented explicitly and you can even limit who can implement them. Java is primarily a language designed for libraries & frameworks and the quality shows it. With structural and open implementation of interfaces, your line of code-ownership becomes blurry. This is not nearly as problematic as dynamic typing, but in my mind an interface is a specification. And you there should be a contract between the provider and consumer. This also helps with understanding the connections inside/between code-bases. Same about interfaces can be said about First Class Functions vs. Functional Interfaces. Functional Interfaces can be documented, domain-specific, extended and implemented. It feels like a perfect blend of FP and OOP, whereas with First Class Functions I feel like I am working with C-stylee primitives which don't help me express the nature of the solution I want to model nearly as much. As for Java, I have an immeasurable amount of respect for the current language designers (can't say I have the same respect for Go Designers after the drama surrounding generics). I am an avid reader of their mailing list and time and time again, they have shown deep thought and tremendous foresight (their way of work is quite inspiring). Yes, they have to live with some nasty historical baggage, but they have a very high level of quality. Then there are aspects such as the ever-evolving JVM, along with its choice of several garbage collectors and top-tier runtime analysis (Flight Recorder) & optimization (Hot Spot). Sorry, this is entirely subjective but you asked me how I "feel" about it :-) Summing it up, I'd say Go is a comfortable local maximum which can give you a whole lot, but ultimately is less flexible. But it's surely enough for 90% of applications. In this sense Go is like the big brother of PHP, which is a perfectly reasonable language if all you need in your backend are save/load database operations. Go can cope with that too, but also scale into non-trivial domains, the cloud and multi-threaded problems. But Java is "corpoaraty" and not "trendy", so most people don't even consider it as an option. And there are enough bad devs who started their carreer in JS/TS and want to move towards something more performant, that is still as ad-hoc and don't mind sharp edges because they never learned to reason about their application in a more formal sense. But looking at the work that is currently being done to the JVM, I'm looking forward to the near future when we can run Java-compatible bytecode on GPUs and AVX512.

neonsunset 2y ago

Thanks for posting this. It’s an unfortunate choice of “one hammer to rule them all” given Go does not offer necessary coverage at both low and high ends of abstraction (and performance) the way C# does. For me, it’s a similar kind of hammer. (I prefer to think of it as a crowbar ;D)

mapcars 2y ago
The problem with C# is its created by Microsoft, even if its a good language its hard to look at it and not think how much its limited while used outside of Windows.
- neonsunset 2y ago
  It seems that you might be asking this question in bad faith. But on the off chance you are not, please find previous replies that address the same kind of question below: https://news.ycombinator.com/item?id=41037792 https://news.ycombinator.com/item?id=41037792 https://news.ycombinator.com/item?id=41189309 https://news.ycombinator.com/item?id=41189309 https://news.ycombinator.com/item?id=41211767 https://news.ycombinator.com/item?id=41211767 https://news.ycombinator.com/item?id=41197493 https://news.ycombinator.com/item?id=41197493 https://news.ycombinator.com/item?id=41218353 https://news.ycombinator.com/item?id=41218353
  - mapcars 2y ago
    I understand its probably not the case today, just that C# shares some of the MS reputation and its hard to get rid of. Especially when there are dozens of open-source independent languages around.
    - neonsunset 2y ago
      I think phrasing with insistence that it is "probably not the case today" despite demonstrable evidence of certainty means that the motivation for this reply was not to learn something new or share something you know but to try to get a raise with low-effort bait. This is both tiresome and goes against guidelines. Somehow we all can normally discuss programming languages without bringing practices of Google or Oracle into the picture and focus instead on programming language development initiatives that they drive and sponsor, that are themselves sufficiently independent. Let's keep it that way. Also https://news.ycombinator.com/item?id=41218353 https://news.ycombinator.com/item?id=41218353 (which was the last link in the list).

markusw 2y ago

I wasn't aiming for that. My point is more: I know Go already, it's good enough for my purposes, so I'm using that as my hammer. I could just as well have been Java or C# I learned eight years ago and used that for everything. :)

danielvaughn 2y ago
I just began using Go literally 2 days ago, but I could already see building most of my projects in it from here on out. It has the type system I'd need from Java or C#, while being almost as simple and readable as Python. I love the module system so far and enjoy not having to decide on my own formatter. Go is perfectly boring and simple, and seems to get out of my way. At least, that's how it feels as a newcomer. I'm sure it will change over time, but I'm having a blast at the moment.
- markusw 2y ago
  It actually gets even better! :D Enjoy the journey!
- kamaal 2y ago
  What about the absence of exception handling? Plus OO has its own advantages, even if you don't use it all that much, its one of the best ways to fit problems into neat design patterns. Go seems to be missing those features.
  - danielvaughn 2y ago
    This is my first time working with a language that exclusively uses errors as values, and I haven't had time to develop any strong feelings about it. So far it feels nice because it makes error handling crystal clear, but I could also see it becoming cumbersome over time.
    - jimbokun 2y ago
      It can get verbose, but I'm willing to live with it for all the other benefits of the language.

jimbokun 2y ago

I'll give it a shot. The tools make a lot of decisions for you that are pretty arbitrary, like how to format code, freeing up brain cycles for other things. It compiles very fast, so the iteration cycle is similar to a dynamic language with a REPL. Very little time between making a change, running and seeing the new result. The language is designed from the bottom up for fast compile times even in large projects, with features at odds with fast compilation rejected. Decent sized community and library ecosystem. The networking APIs are very simple and productive. More and more back end code is being written in Go for this reason. The semantics are straight forward. The other programming environment I need to deal with at work is Spring Java, which is unjustifiably complex and obfuscated for what it does. Go allows you to read the code and run the program in your head understanding semantics and performance characteristics. Builds single file executables that are simple to deploy. Has just enough high level features to be productive without compromising above points about simplicity, fast compiles, and comprehensibility. Channels and go routines work very well to model concurrency across a wide array of problem domains. Maintainers are careful about adding new features. Generics took a long time to arrive, but when it did was very well thought out and did not negatively impact performance very much. I'm sure I'll think of more.

alemanek 2y ago

I am someone with significant experience in Java, C#, C++, and JS/TS. I am a bit of a newbie to Go but have used it for a few things at work. So, I can give a bit of a comparison for you. I really like the DevX and strong standard library of Go. Also I really like that the community around Go has a strong preference for just using the stdlib and not going crazy with third party libraries. Languages are just tools but I have a strong preference for Go for backend services and CLI applications now. Just my 2cents.

DarkNova6 2y ago
Hey, thanks for the reply. That sounds really nice! I wonder, which aspects of the "Go" std lib are considered strong? Would you say it is more like .net where the std-lib also comes with framework-grade capabilities such as REST-endpoints and setting up applications? Because in the classical sense of a library, I think Java is fantastic (collections, strings, NIO, HTTP 2.0, etc.). But it misses framework-level out-of-the-box solutions.
- metaltyphoon 2y ago
  Not STD comes close to .NET, IMO.
- alemanek 2y ago
  So take this with a big mountain of salt as I am newer to Go and my experience with .Net is a bit dated but I do have 7 YoE with C#. The C# stdlib is larger and more batteries included for sure. But, it feels less focused than Go to me. Over its history it has supported a ton of different styles of programming. Whereas Go’s maintainers have been, at least so far, more obsessive on keeping the language small. As a result you get libraries and codebases that have a mix of legacy and modern flavors of .NET. That isn’t the fault of the language but more of its large history and wider scope. GoLang doesn’t have a rich UI library built in for example whereas .NET has 3 if I am remembering correctly. I like the focus of Go but C# is a great language and .NET is an excellent framework. Here are some things that I think Go does better though: - TLS and x509 stdlib is fantastic - Explicit error returns instead of Exception throwing - A developer culture around idiomatic Go. It’s subjective but it sets a tone for a single coding style. - Less “magic”. This is more of a sin of Java frameworks but .NET has lots of higher level abstractions the push lots of interactions behind the curtain. - tiny docker images and super fast startup. Here are some things I miss from C#: - really nice Enums - Better support for functional programming. - LINQ to objects - Annotations, specifically validation logic as annotations. - JSON handling is more straightforward .NET is super capable though. Nothing wrong with using it and it is much more broadly applicable than Go in my opinion. But, I like the ergonomics of Go and for backend services and CLI tools I think it is a strong choice. But, I wouldn’t choose it to build a game or a desktop/mobile GUI application currently.

daghamm 2y ago

How can you call Go hype driven? It was literally designed to be "boring".

cy_hauser 2y ago
I think it was the Go Marketing Team who decided to call it a boring language. "Boring" tested well for hyping the language.

gnfargbl 2y ago

It feels extremely strange to see Go described as a "hype" language. It was somewhat hyped around seven years ago, which is when I started using it almost exclusively. Before that, it had a strong hype peak about fourteen or fifteen years ago, just after it was born. However, it's not a young language any more. At this point I would actually submit the opposite criticism: it is a mature language which is perhaps starting to suffer from middle-aged spread, as the bored maintainers start to stuff in more features which the language doesn't genuinely need. (Example: Iterators. Sure they're nice, but does the language really need them?) If anything, I would say it's going more the way of Java than Rust or Node.

kaba0 2y ago
Count the number of posts with Go in the title, vs any other programming language. It easily beats out everything both here and on lobsters.
- gnfargbl 2y ago
  Well, it's a very usable language which is strongly typed (by any layman's definition), easy to pick up, easy to get stuff done in, relatively easy to live with and easy to maintain. If it's hyped then it's only in the same way The Beatles and Pizza are hyped.
  - markusw 2y ago
    I like that! Go is basically pizza! :D
- kjksf 2y ago
  Maybe, but 80% of those are complains of some sort. That's the opposite of hype.
- cy_hauser 2y ago
  I did this about 1-1/2 years ago and just reran the numbers. Today: "written|built in Rust" 1113 (1036|77) "written|built in Go/Golang" 1050 (889|25) / (119|17) "written|built in Python": 452 (422|30) "written|built in Javascript/JS" 286 (233|14) / (34|5) "written|built in Java" 115 (109|6) "written|built in TypeScript" 97 (89|8) "written|built in C#" 46 (43|3) "written|built in Stone" 13 (13|0) Feb 2023 "written|built in Go/Golang" 918 (792|17) / (102|7) "written|built in Rust" 832 (790|42) "written|built in Python": 390 (364|26) "written|built in Javascript/JS" 269 (220|14) / (32|3) "written|built in Java" 107 (101|6) "written|built in TypeScript" 66 (61|5) "written|built in C#" 41 (38|3) "written|built in Stone" 10 (10|0)

bborud 2y ago

I think the hype has already peaked for Go. When we switched to Go 8-9 years ago I already felt the hype had died down. We were late to the party. And I saw that as a good thing. To me it suggested Go was going to stick around. And now, almost a decade later, we're still using it. Note that at my company, we're a bunch of grumpy old guys with about 30 years of experience each. If you dangle a new and shiny language in front of us, our default instinct is to tell people to get lost. We don't do "fashionable". We tend to make investments in learning languages that we expect to get at least a decade out of. And I don't think Go is succeeding Rust. From what I can tell, people are going in both directions.

jerf 2y ago
Go and Node have some significant overlap, but Go and Rust are barely even competitors. Of course there's a lot of programs that you can use either to write. There's a lot of programs where it hardly even matters which language you pick at all because they're all perfectly acceptable solutions, though, so that really isn't saying much. But if you map languages out by the programs where language choice matters at least a little and where a given language is legitimately one of the top contenders, Go and Rust don't have a particularly strong amount of overlap in my opinion. They do, but again, lots of languages have overlap; I don't see the Rust/Go relationship being particularly heavily overlapping. (Go/Java or Rust/C++, now there's overlap, for comparison.)
- bborud 2y ago
  > Go and Node have some significant overlap, but Go and Rust are > barely even competitors. Among the people I know Go and Rust seem to be at the top of their list. Almost all people I know who program Rust also know Go. Not as many Go programmers I know program in Rust as well, but some know Rust and even more want to learn it. Which probably isn't too peculiar because Rust is more of a kerfuffle to program in. I'm not denying your observation. I'm just reporting that from where I am, things look a bit different. I agree that it mostly doesn't matter that much which language you choose -- as long as it is a language that can meet certain minimum standards. In my view there is only about a handful of languages to actually choose from. The first is that it must be possible to produce proper binaries. For instance, Python is unacceptable to me since it tends to place a large burden on the user. Next, it has to be a somewhat mainstream language with a sufficiently large community. With that sorted the more technical stuff needs to be evaluated. Like its standard library, how ergonomic the tooling, what quality software/libraries the community produces is etc.

gavindean90 2y ago

Honestly it gave me the feeling of not arguing to use Go but instead arguing to use the full featured language you know the best. The caveat being that it is of you are a single developer making all the decisions and writing all the code. Seemed to make a good case for that