Go is my hammer, and everything is a nail

People always under-estimate the cost of properly learning a language. At any given time I tend to have a &quot;main go-to language&quot;. I typically spend 2-4 years getting to the point where I can say I &quot;know&quot; a language. Then I try to stick to it long enough for the investment to pay off. Usually 8-10 years.<p>A surprising number of people think this is a very long time. It isn&#x27;t. This is typically the time it takes to understand enough of the language, the compiler, the runtime, the standard library, and idiomatic ways to do things. It is the time it takes to where you can start to meaningfully contribute to evolving how the language is used and meaningfully coach architects, programmers and system designers. It is also what you need to absorb novices into the organization and train them fast.

I used to work for a Go shop. We dealt with financial data. I found it so annoying that many of my colleagues would use Go for one-off tasks such as aggregating CSV files, updating the database with some data, or fetching data from the database, and then trying to make a plot. I saw my colleagues again and again implementing basic algorithms such as rolling median, or finding a maximum. Instead of loading data into Pandas and doing a group by, they would create some kind of loopy solution that would use maps.<p>I totally understand why some people prefer Go in production to Python, but I could never understand why people wouldn&#x27;t just learn the standard data science tools instead of reinventing the wheel in Go, always debugging their own off-by-one errors. It was difficult for me to trust the results of such analyses, given that I knew how many of the basic functions were written on the fly and probably not even tested.<p>In the end, I didn&#x27;t think it was a good use of the company&#x27;s time. It felt more like an ego thing - thinking and showing that Go is sufficient. It reminds me of how people try to use iPads to code - only to show that they can do it.

The author lists multiple reasons for this, but for me the biggest one is the first one: Go is good for almost <i>everything</i>.<p>I have extremely good productivity when using Go. Once your project exceeds 100 lines it is usually even better than python. And yes, I am aware that Rustians did a survey where Rust was crowned as the most efficient language but in my reality (which may differ from yours) Go is simply the best tool for most tasks.<p>Why is that? Well, for me there are 3 reasosns:<p>1. The language is extremely simple. If you know 20% of C you are already a Go expert.<p>2. The core libraries are extremly well thought.<p>3. Batteries are included. The toolchain and the core libraries alone can do 90% of what most people will ever need.<p>When people argue about the validity of these claims, I simply point them to this talk <a href="https:&#x2F;&#x2F;go.dev&#x2F;talks&#x2F;2012&#x2F;concurrency.slide#42" rel="nofollow">https:&#x2F;&#x2F;go.dev&#x2F;talks&#x2F;2012&#x2F;concurrency.slide#42</a>

Go is everything I don’t want in a language for my personal projects. It’s verbose, every simple task feels like a lot to write. It’s not expressive, what would be a one-liner in Python makes you write three for loops in Go. I constantly need to find workarounds for the lack of proper enums, lack of sum types, no null safety etc.<p>I’m sure these are the exact reasons why Go is good for enterprise software, but for personal projects, I get no fun out of using it

That&#x27;s why Typescript is my hammer, unless I need a jack hammer, which is Rust.<p>With Deno and Typescript I get an even more versatile toolbox than with Go. And what&#x27;s even more important to me, Typescript is safer and more ergonomic than Go, but slightly slower. Rust is safer, more ergonomic and faster than Go, but much harder to learn.<p>Especially strict (which is a must) Typescript is underrated. Compared to Go, we get:<p>- null safety<p>- widely supported generics<p>- discriminated unions with either manually (some lines of code) or es-lint exhaustiveness checks<p>- much safer concurrency, as all Typescript code runs single-threaded. You need web workers, which are not as safe as Rust for concurrency, but much safer than Go.<p>- collection &#x2F; iterator methods<p>So far, I see only few downside. I&#x27;d be happy if people could provide more. Currently I&#x27;m scratching my head why I didn&#x27;t fall in love with Typescript (for backend and CLI) earlier. Maybe I haven&#x27;t seen the dark sides yet. So, some points where Go is stronger than Typescript:<p>- Go is much more efficient in terms of size and memory usage<p>- Go&#x27;s GC is better than V8s<p>- Go is faster on CPU bound tasks<p>- Go has a greater std lib, however, Deno&#x27;s std lib is pretty nice as well.<p>- The ecosystem is smaller, but has not as much trash as NPM. The dependency trees with NPM are usually large. By the way, Rust has this problem as well, less than Typescript but more than Go. Still, many mainstream NPM packages are safe and rock solid.<p>What else could we say against Typescript (and preferably Deno or Bun)? I&#x27;m really eager to hear people having ditched it an why.

Go is my favorite general-purpose tool (combination of language + standard library + 3rd party libraries + tooling + documentation). Everything just works out of the box and is simple to use and understand. No collection of dozens of external tools with fiddly configuration, a simple command to compile and simple deployment via a single executable with no additional setup required. No other language gives me such a simple and hassle-free all-around experience.<p>I certainly think other languages (Java, C#, Rust, JS&#x2F;TS) have a lot of advantages over Go in some areas, but everything I&#x27;ve worked with so far has some other aspects that I absolutely hate.<p>POV from a (mainly) B2B fullstack SE

I&#x27;ve been coding in Go for over five years. I <i>like</i> Go, but I don&#x27;t <i>love</i> it. It&#x27;s never my first choice, although I don&#x27;t advocate for rewrites just to move away from it.<p>The tooling is a mess. Go modules still feel like a &#x27;first pass&#x27; implementation that never got finished. There&#x27;s no consistency in formatting or imports (even though Go claims there is). Generics are a good step but are still very primitive (no generics on interfaces, no types as a first-class object).<p>It still feels very unfinished as an ecosystem. I hope it&#x27;ll get better as the Go team mature things, like iterating on generics. But I can&#x27;t see Go modules continuing without a fundamental rewrite.

There are a lot of aspects of Go that I’m really not a fan of, but I’ve been writing an increasing amount of it over the last few months and on the whole I’m finding it really enjoyable—even though I’m not sure I could empirically explain why.<p>The tooling is <i>heaven</i> compared to other stuff we do a lot of at work (TS&#x2F;JS of course being the main offender), and generally I find I spend less time thinking about things that aren’t directly related to the problem I’m trying to solve. Though, that might just be because I’m not an expert and simply don’t yet know about other things I could be thinking about!

Life is barely long enough to get good at one thing so you should choose your thing wisely. That&#x27;s wisdom I&#x27;ve held for quite some time.<p>Coincidentally, I chose Go as my language of choice as well. The factors that led me to that choice were many, but to highlight some:<p>- incredible standard library<p>- simple to read and write<p>- single static binary builds (assets included, like html&#x2F;images, etc)<p>- don&#x27;t need a container (my binary is the container)<p>- can be used anywhere (webdev, desktop apps, gamedev, embedded, etc)

I really like most aspects of Go, but as someone who writes a lot of numerical code, no operator overloading is a deal breaker. It&#x27;s so hard to accept something like Add(Scale(s1, vec1), Scale(s2, vec2)) over s1 * vec1 + s2 * vec2. So I stick with Python and C++ for now.<p>Rust is really appealing as a C++ replacement, but it has too many rules to replace Python for one-off scripts. Still need to try Nim and Swift, I guess...

At the peak of my honeymoon phase with Golang, I went down this path too, and oh boy does it feels great and liberating, like finding a magic bullet, but soon as you start to scratch beyond the surface and dig deeper, you will find yourself trying to screw screws with a hammer, or tie your shoes with a chainsaw and ungodly things like that.<p>No tool deserves more love or loyalty than the productivity it brings, anything more is infatuation and a game for naive and the fool.

&quot;The world is laaaarge. The number of projects are basically infinite. Even if I carve out a tiny subset of infinite, that’s still infinite.&quot; I liked the use of this wisdom in there.

This article is not so much about Go but about choosing to specialize in one language ecosystem instead of spreading one&#x27;s attention across several.

The author feels happy and contented and you all are getting defensive. He’s a solo dev, just recognize that that scopes his projects and stop trying to shoot him down.<p>Use what you want.

I can&#x27;t really disagree with the points the article makes in favor of Go, and it&#x27;s not selling it over some other language&#x2F;framework&#x2F;tool but just celebrating how great of an ecosystem Go has. And it&#x27;s true -- Go&#x27;s ecosystem has matured into something very pleasant to work with.<p>By the same token I know professors who still write their simulation scripts in QBASIC because that&#x27;s what they are familiar with and they can solve their problems quickly. You can use all sorts of tools to drive a nail.<p>On Go, it&#x27;s almost a footnote in the context of the post, but I think a seriously underrated feature is its C-interoperability. Here [0] is an example. It&#x27;s not unique of course -- tons of languages have some FFI solution for C libraries -- but Go&#x27;s is I believe one of the most straightforward to use if you&#x27;re already familiar with the language. And while there are portability&#x2F;stability sacrifices you make when you call a native library, it does also expand the available dependencies even beyond &quot;basically infinite.&quot;<p>[0] <a href="https:&#x2F;&#x2F;go.dev&#x2F;blog&#x2F;cgo" rel="nofollow">https:&#x2F;&#x2F;go.dev&#x2F;blog&#x2F;cgo</a>

I understand the sentiment. My goto hammer is Kotlin, which I like a bit better than Go. But that&#x27;s a highly subjective thing of course. And I use plenty of other languages as well (including very occasionally some Go).<p>It&#x27;s not about what is better in general but about what is better for you. Better here means less time wasted with figuring out syntax, tools, APIs, frameworks, etc. Once you know how to do a certain thing in one language, having to relearn to do the same things in another is slightly annoying. Although, LLMs are actually hugely helpful for this these days.<p>IMHO we&#x27;re about to see a minor renaissance in web development. I was playing with the Kotlin WASM compiler a few weeks ago just to verify that I could use existing web APIs. As it turns out, it&#x27;s are all there. Using them might not be the fastest right now but I&#x27;m sure that will get improved over time. Garbage collection is already in (and coming soon to Safari as well). There are some inefficiencies with making calls into js that need some attention. But that&#x27;s not really a show stopper unless you are doing this many times per second.<p>What that means is that you can just do web application in wasm; use all the stuff from the browser that you normally use but without any javascript (except for a tiny wrapper that loads the wasm). I actually use kotlin-js so it&#x27;s not a big leap for me. But wasm loads a bit faster and probably compiles a bit faster too. No more webpack uglification needed (which is actually slower than the kotlin compiler). So that&#x27;s 2x compiler performance right there.<p>The point here is not kotlin or javascript but that this now works with any language that you can get going with wasm. Including Go if you want. Javascript becomes completely optional. I&#x27;m sure some will be upset about that. But that would be mainly because it&#x27;s their preferred hammer.

Heard from someone: &quot;C++ is a hammer, but then everything starts to look like your finger&quot;

If all you know is a Hammer…<p>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.<p>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.<p>Note, this is explicitly not about the languages themselves, but rather the larger cult(ure) of mainstream programmers around them.

Different strokes for different folks. Used Go for ~5 years, would be happy to never use it again. Typescript is in a similar bucket, lots of professional usage (sadly still using it) would also be happy to never touch it again.<p>Kotlin&#x2F;JVM became my hammer and I currently don&#x27;t feel like there are any gripes I have about it except maybe that the Gradle&#x2F;Maven dichotomy and associated anxiety that build systems give people makes it harder to sell people on it.<p>Otherwise language feature wise and runtime wise it&#x27;s about as good as you are going to ever need for 99.99% of (non-frontend) use cases. You have C++&#x2F;Rust&#x2F;Zig to fill in the few places where a runtime isn&#x27;t viable.

Where I feel go is lacking is for data wrangling.<p>Group by, filter, map, join. It is just very error prone, inconvenient and slow to implement with for loops.

None of these reasons are specific to Go. They apply just as well to any Turing complete programming language.<p>Not to say the arguments are bad. Just that the argument is for picking one tool and using it for everything to benefit from your investment in that tool across all your projects.

I really want to love Go for side projects but it’s just so verbose and time consuming.<p>I understand that a framework with ”batteries” goes against Go principles, but coming from Rails, which solves the common boring problems for me, Go just makes it too much of a pain.<p>At least as far as web dev goes, I’m sure Go is great for other stuff.

Related:<p>Java for Everything<p><a href="https:&#x2F;&#x2F;www.teamten.com&#x2F;lawrence&#x2F;writings&#x2F;java-for-everything.html" rel="nofollow">https:&#x2F;&#x2F;www.teamten.com&#x2F;lawrence&#x2F;writings&#x2F;java-for-everythin...</a><p>Previously HN discussion of &quot;Java for Everything&quot;:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26934297">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26934297</a>

I find Go akin to C ; it&#x27;s really fast to pick up, I can use it without internet if I have to, it has enough functionality and enough stable libraries for me not really to have to bother with the latest and the greatest of everything like in the javascript world.<p>I use it when I cannot use CL (for basically everything) or Racket (language &#x2F; code generation), which basically means &#x27;if my clients doesn&#x27;t accept the above&#x27;.<p>For web&#x2F;desktop&#x2F;backend CL and Go are both incredibly productive. CL for me is more productive, mostly because the effortless starting, far more expressive (do a lot with very little code), better repl, debugging, save and die etc. Single binaries are great about both and so is lightning fast compilation.<p>I guess I have two hammers; one of them has a more comfortable handle for whacking in those slightly more difficult nails.<p>Lately I cheat by using a subset of CL and generating the Go code.

&gt; So, what, I’m going to limit my career options?<p>I don&#x27;t quite get this sentiment. In my experience, the career opportunities come from solving worthy problems, as opposed to using a particular language. Plus, I don&#x27;t believe that an engineer should be identified by a language, as in a Go programmer, or a Java programmer.

You could have written the same article about C#.

For me, this is very true. Most bioinformatics is done in python, but over the last ~4 years I&#x27;ve ported everything I do over to Go: <a href="https:&#x2F;&#x2F;github.com&#x2F;koeng101&#x2F;dnadesign">https:&#x2F;&#x2F;github.com&#x2F;koeng101&#x2F;dnadesign</a><p>I&#x27;m just massively more productive, and the fact that I can read code I wrote years ago and fully understand what I was thinking at the time is amazing, and I haven&#x27;t experienced that in other languages. I&#x27;ve learned other languages quite in depth, but with Go it is simple enough that when I write code, I&#x27;m not thinking about code, it is purely the problem being solved, and the code just comes out onto the keyboard.<p>Ironically enough, I&#x27;ve recently started porting my entirely-go bioinformatics package to be a python package, mainly because I realize I&#x27;m not gonna convince everyone else in my field that Go &gt; python

For me, expertise in a particular language is <i>rarely</i> very useful. Expertise&#x2F;specialization is <i>mostly</i> a time tradeoff for particularly thorny issues, but IME they <i>rarely</i> come up in a programming language context (usually it&#x27;s domain or particular codebase-specific). That being said, Go is a really good &quot;workhorse&quot; language.

Been using go for nearly a year. Don’t like the strange formatting and naming standards and arbitrary rules surrounding it.<p>The worst thing I hate is the packaging rules. Once something is out in a folder it becomes a package. Once something is in a package there can’t be circular dependencies.<p>There can be circular dependencies within packages and files but not with other packages. This is fine except in golang and life in general people like to organize things by creating new packages. Why? Because people like folders. It’s instinctive. Rather than programming a project in one flat folder people like to throw their code into little modules by making a bunch of folders organized by semantic meaning rather then dependencies.<p>This ocd drive that I believe is some intrinsic part of human nature to organize things by semantic meaning in folders results in almost every golang project becoming some massive organization problem on the right place to put a function or a method. You spend an inordinate amount of time organizing things thinking that if go tells you there’s a circular dependency you did something wrong.<p>Nothing is further from the truth but people just love go so much that they trust this. What is happening is, the go way of making packages and your semantic methodology of organizing things into folders is colliding. Go doesn’t say there’s anything wrong with circular dependencies. The language completely permits circular dependencies in that if you want to create something with circular dependencies (which is an extremely common thing in languages and complex things outside of languages) go says you can’t have folders.<p>It’s the most strangely arbitrary choice and turns every project into an exercise of organization. Golang pits the human desire to organize things semantically with an opposing rule of organizing things into a tree of dependencies. A lot of people love spend so much extra time resolving this conflict because it makes them think they’re making things “more” organized and cleaner when it’s, in reality, a pointless effort trying to resolve two arbitrary and conflicting rules.<p>I know people love go. This is just my personal opinion of it. I don’t really like it. I want program organization to be seamless and simple. Go is not this program for me.<p>Rust handles organization better. Just better ux by allowing people to use folders as they intended to use them. Rust also has its own set of usability problems. But those problems are explicitly implemented for a specific tradeoff. In go the folder thing is completely arbitrary.

The article claims Go supports building GUI apps and links to this.<p>&gt;Wails is a project that enables you to write desktop apps using Go and web technologies<p>At that point why not just use Electron and Node JS.<p>I like Golang, I truly do. But after building mobile apps in both Golang and Fluter, I&#x27;m well aware of Go&#x27;s limitations.<p>Making anything look remotely nice is painful. Things get really difficult when you use the wrong tool for the job.<p>A much better argument could be made for JavaScript being a language that can do anything. Even then when ever you run npm install you need to pray the house of cards that is modern JavaScript doesn&#x27;t collapse.<p>C# is also a contender, but people, particularly the FOSS crowd doesn&#x27;t like it because Microsoft == Bad.

Sorry, you have been blocked You are unable to access maragu.dev Why have I been blocked? This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.<p>What can I do to resolve this? You can email the site owner to let them know you were blocked. Please include what you were doing when this page came up and the Cloudflare Ray ID found at the bottom of this page.

I feel mostly the same as the author. The Go ecosystem is so simple, logical and smooth that it is hard to reach out for something else. I do use other languages for one-off programs of course, be it bash, perl or javascript, depending on the task.<p>On bigger projects, the first pain point to appear for me is dependency management. It feels so antiquated in most other ecosystems, with loose compatibility contracts that add mental overhead. Go let’s you focus on the problem you are trying to solve, and you get so used to that luxury that using anything else quickly becomes painful.

I really hope that Julia catches on. It feels like it solves a lot of pain points Python programmers have, while still being Data Science focused. It just needs to continue to grow its ecosystem

as the saying goes, when you&#x27;re a nail the right tool is always a hammer

I wish Go had a decent UI framework though.

&gt; But why? When the common wisdom is to always take the problem at hand, analyze it, and then choose the tools, why would I ignore that and go<p>Sounds like they <i>are</i> choosing the right tool for the job.<p>When considering languages, familiarity is a significant aspect. And, the smaller the duration&#x2F;size of the project, the more significant it is. A decent analysis wouldn&#x27;t ignore this.<p>If the language you&#x27;re most productive with is appropriate for a project (and go is appropriate for a wide variety of things), you need a good reason <i>not</i> to use it.

I recently tried to setup a PHP &#x2F; Laravel dev environment on Suse Linux box. Installed PHP and all the stuff accordingly, then following one of the get started doc from Laravel. You know what happened? Doesn&#x27;t work, broken. I assume that way Laravel created Sail, which I didn&#x27;t use. Much different case with Go, installing the toolkit and development environment is easy. Even with free vscode, everything is just work, PHP+Laravel seems encourage you to buy all dev things.

The GUI apps built with fyne framework are, at best, toy projects. I am not convinced go is a robust solution for building native GUI interfaces.<p>&gt; Reason 1: Go can do basically anything That is a weak argument. All languages can do everything (for example, you can build GUI desktop apps in PHP). If omnipotency is the main criteria, then C# or Java are better alternatives than go - you can even build an OS on CLR&#x2F;JVM.

I would argue that a language&#x27;s ecosystem matters much more than the language itself. This is why Java is still so popular, and why certain languages are better suited to certain tasks than others. For example, if you&#x27;re doing numeric or scientific related development, it&#x27;s hard to beat Python even if Go itself is better, because of the great set of robust libraries you get for free. (Yes, Go has some equivalent, but not as tried and true as numpy, scipy etc.)

Go is not a single tool. It&#x27;s a vast set of tools. Using mostly Go is kind of like using mostly Milwaukee power tools. Then, when you need a tape measure or a level or a tool bag, if you&#x27;re reasonable you can use another brand, where it makes sense.<p>You still should always try to use the right tool for the job. Doesn&#x27;t mean it has to be the absolute best tool or such a thing exists, the best tools are often the ones you have ready at hand and know or can learn how to use.

This is the same thing everyone says about PHP, negatively.<p>Don&#x27;t make Go the next PHP. PHP has some good updates recently but it still has some people with a negative experience with it.

Same here. the things i do, go is great. for front-end, i use quasar(vue&#x2F;js). that&#x27;s all i need. if i ever need crazy performance, i&#x27;ll do it in zig, once it releases 1.0. chasing performance merely for the sake of performance is waste of time. use what you know first, optimize later. and go can handle anything, except 3D games. but that&#x27;s more about it being GC language more than anything else.

It&#x27;s really nice that Go and Rust have one standard package management system, and a built-in standard formatter. Both of these things seem obvious now, but they were innovative when they were introduced. They add a new set of &quot;batteries&quot; to the &quot;batteries-included&quot; mindset. And they put community and ease-of-use first, which are crucial for adoption.

I think opinions on Go depend on the quality of code you&#x27;re used to working with. I was lucky enough to be on a small team of great engineers for much of my career so far, and my impression of Go is that it prevents you from writing good code. However hearing others&#x27; opinions, I suspect it also doesn&#x27;t let the bad code get too bad, which if you&#x27;re used to bad code, is desirable.

I like that.<p>I have a similar attitude with Python and Go as back hammers and Quasar (Typescript + Vue + Vite + components) as the front hammer.<p>Whenever there is a date in Python I exclusively use Arrow (even for the simplest, most basic ones).<p>I know it is not effecive, but I am an amateur dev and having these hard rules keeps me from testing something new all the time.<p>I leave this for home automation and docker services where my motto is &quot;fix it until you break it&quot;

Java was my hammer back in the day. In a few more years, I&#x27;m banking on it being my post-retirement &quot;daddy needs a new boat&quot; solution.

s&#x2F;Go&#x2F;Haskell and I feel this 100%<p>when you have a programming language that can do everything and vibes with how you think, you&#x27;re golden

I&#x27;m totally with this idea - use the language you know best for mundane tasks.<p>I used to switch to shell or Python to do one-off scripts. But there&#x27;s not a super great reason why I can&#x27;t do the same in C++, which is what I know best. All the build stuff is easy to do in my company&#x27;s repo, so that&#x27;s not a big blocker.

I know its great and powerful but Go was always the &quot;Google language&quot; to me and as an unsufferable hipster that just turned me off to ever touch it.<p>I want all the things I spend my years studying to be built by committee or otherwise brief specimens of creative genius. Anything else makes me feel like I&#x27;m just learning Marvel lore.

I grew up writing C&#x2F;C++ and I could write this same blog post but about Python for the same reasons that the author cites :-)<p>Sometimes I wonder if I am just being lazy and justifying not learning new stuff but then I look at the new stuff that keeps landing in the Python ecosystem and conclude otherwise.

I was hesitant to learn Go after 10+ years of Python, but then I started work on a side project where performance translated into actual money savings for me. My Python code routinely took between 100-200ms to run. I was happy, but I was also curious if I could do better without rewriting it in C&#x2F;C++. Go proved to be easy to learn and being compiled it was much easier to deploy (that was before I could rely on Docker for packaging). The big surprise came when I ran my code and found out that each request would take 10-20ms to process same payloads. I have never written a line of code in another language on the backend ever since. The cherry on top is support for multithreading&#x2F;multi-core CPUs. I&#x27;ve been in Python by day client work), Golang by night (my own work) mode for many years now. It&#x27;s a great language. OK, I do admit to learning Rust, but... it&#x27;s just out of curiosity, not out of need for anything &quot;better&quot;.

I love Golang, I used for backend, have some GUI apps but I think GUI packages and frameworks for Go are still immature, none of them convince me.<p>I would like a tool in go, that could handle nice GUI, compiled for WASM and run in the browser. Any ideas?<p>I will follow you @markuwsw.

&gt; Go is my hammer, and everything is a nail<p>&gt; Less context switching<p>For the very same reason, my hammer is javascript.

I like using this great library to build progressive web apps using Declarative Syntax <a href="https:&#x2F;&#x2F;github.com&#x2F;maxence-charriere&#x2F;go-app">https:&#x2F;&#x2F;github.com&#x2F;maxence-charriere&#x2F;go-app</a>

I want to use Go, but whenever I compile a small CLI tool using it and it comes out as a 10 MB executable, I just feel ashamed. Especially when Zig and many other tools can produce the same thing at a few KB.

Go is nice but people either love or hate the error handling.<p>There have been some good proposals but because people are so passionate about all their requirements and edge cases, that I don&#x27;t think it&#x27;ll ever get improved.

I feel the same, but for me Rust is currently my hammer ;)<p>Checks all of the checkboxes.

The fact that monorepos are so easy helps make Go so versatile. It is so easy for me to make an adhoc CLI for data fixing which uses my core service code, for example.

Same, but s&#x2F;Go&#x2F;Scheme&#x2F;g. For over 20 years now.

&quot;Reason 1: Go can do basically anything&quot;<p>So how do you build an OS kernel in Go? C folks have been doing it for decades. Rust guys are slowly catching up. And Go...?

I came for the programming language discussion, but I want hear more from the author about their contentedness with being a solo developer for life.

Same here, as a solo entrenpreuner who is 50+, I love Go for it&#x27;s simplicity. And e.g. migrated my Newsletter generation pipeline from Python to Go.

Does the same apply to &#x27;platforms&#x27;? For example, is it better to learn C# + F# + Powershell instead of C# + Scala + Bash?

JavaScript and TypeScript are the hammer. Go as an oil lubricant. C# as a Swiss Army knife. Java as a toolbox.

Wish I could dedicate life to one language, like F#. I think you&#x27;ll have better luck doing it with Go.

Go is terrible at shell scripts. Too bad it’s not more like python that way.

&gt; all popular programming languages can do basically anything<p>That&#x27;s just very not true...

Granting the indie-dev, limited resources, focus-is-good, to me the key is enablement by available libraries, platforms, IDE&#x27;s, language survival and importance, etc. -- none of which the author mentions.<p>Java for the most part has libraries and IDE&#x27;s due to its history, but got tripped up on the essential web platform story: it&#x27;s only achingly small&#x2F;fast enough for real servers, and just flat out gave up on the browser after the javascript onslaught. For future-proofing, anti-Oracle bias has hamstrung Java of late (notwithstanding the excellent upgrades and engineering Oracle put in).<p>Go is great if you&#x27;re on the server side with Google-like concerns, and it&#x27;s unlikely Google would ever drop Go.<p>With Rust, the language offers the most for serious systems programming, but the learning curve limits available libraries (converse being true in javascript land). Rust is still early-adopters - likely the best talent-wise, but not scaling.<p>Swift is interesting. Can be as easy as Java, but is becoming as correct as Rust wrt lifetimes and more deployable than Go, to both server and embedded. But no real incentive from Apple for deploying on Windows or to the web, so that&#x27;s handled by a few heroes. And unfortunately, libraries are sort of an open-source zoo of minor offerings. But Apple&#x27;s betting the company on Swift, so you can, too.<p>Python pretty much lucked into popularity by supporting the scientific computing that would become data analysis and AI after building significant community inertia. It&#x27;s sort of the default prototyping language in a time when prototypes are often good enough. It&#x27;s gradually been adding typing and performance to stay good enough.<p>So Python would be my recommendation as the one language to rule them all for indie developers, who are more likely to be plumbing together applications than writing database engines. It&#x27;s also where the money is now for most developers.<p>That said, it may depend most on the market for skills. It might be easier to build an indie business as a Go developer because the supply&#x2F;demand curve favors you. And as far as I know, there&#x27;s no good data on point for that.

If you’re going to insist on using the same tool for every job, at least pick a better tool.

Does go even have a Generic list (ArratList in Java)?

go can&#x27;t do GUI go is too fat for embedded systems, tinygo won&#x27;t cut it if I can script it why should I use go go can&#x27;t really do web .... no one language covers it all

The fanboyism, in this thread, for such a mediocre language is disappointing to say the least.

I CAN’T BELIEVE NO-ONE HAS MENTIONED MY BEAUTIFUL TYPOGRAPHIC LAYOUT YET. :D<p>Just look at this beautiful test page [0]. I’m pretty sure I spent more time on that than on the blog post.<p>On a more serious note, thank you for all the discussion! It’s hard keeping up with all the comments, but I’m truly appreciative of the quality of discourse here.<p>Also, the newsletter subscription is up now, if you’re into that. [1]<p>[0]: <a href="https:&#x2F;&#x2F;www.maragu.dev&#x2F;typography" rel="nofollow">https:&#x2F;&#x2F;www.maragu.dev&#x2F;typography</a> [1]: <a href="https:&#x2F;&#x2F;www.maragu.dev&#x2F;blog&#x2F;go-is-my-hammer-and-everything-is-a-nail#newsletter-form" rel="nofollow">https:&#x2F;&#x2F;www.maragu.dev&#x2F;blog&#x2F;go-is-my-hammer-and-everything-i...</a>