34 ms·

Go is my hammer, and everything is a nail

• __s 2y ago
  as the saying goes, when you're a nail the right tool is always a hammer
  • markusw 2y ago
    I guess we're at "I am Go and also a hammer and all the nails" then. :D
• lawgimenez 2y ago
  I wish Go had a decent UI framework though.
  • lagniappe 2y ago
    Go has FyneUI, and it's great
  • bborud 2y ago
    Can you give me an example of a decent UI framework? Or frameworks? (I'm not a GUI programmer, but I've been dabbling a bit using Fyne. I figured that in the C++/C# sphere UI frameworks especially on Windows were sorted out until I read an article by some frustrated individual who listed all the problems he has with various UI frameworks on Windows. So I realized that perhaps this isn't as well sorted as I thought. I don't actually know)
    • neonsunset 2y ago
      Windows situation is kind-of a mess, but cross-platform story is in a good state mainly thanks to AvaloniaUI and Uno (and you can always use things like SDL2 or MonoGame if you feel like approaching the problem in a more “hands-on” way).
    • euroderf 2y ago
      Cogent Core looks promising.
      • bborud 2y ago
        I wasn't aware of that project. This looks pretty new, but after clicking around a bit in the documentation looks very interesting. I get the impression that it isn't as verbose as a lot of other frameworks I've seen.
    • Propelloni 2y ago
      > Can you give me an example of a decent UI framework? Or frameworks? The obvious answer is Qt, but Qt can be a bit of a chore to get into. Same is true for GTK. In my opinion more accessible options would be Fyne or Gioui. All of them have good Go bindings and are suitable for "standard fare".
    • lawgimenez 2y ago
      I mostly work on Swift and macOS, so SwiftUI.
    • theshrike79 2y ago
      Anything that has a visual designer where I can combine drawing and drag&dropping components and code depending on my needs.
  • Cthulhu_ 2y ago
    TBH this can be said about most programming languages, and this is one reason why Node / Electron based UIs are so popular because there's so many well-developed UI options then that are automatically cross-platform.
  • theshrike79 2y ago
    Very few languages do. Rust doesn't have one either. UI work requires very specific things to be integral to the language to be fluent to use.
• DarkNova6 2y ago
  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.
• caerwy 2y ago
  This article is not so much about Go but about choosing to specialize in one language ecosystem instead of spreading one's attention across several.
  • dimgl 2y ago
    Which is unfortunate because I think Go is very useful in a wide variety of business contexts.
    • the_real_cher 2y ago
      Then you would find this article very fortunate.
      • the-grump 2y ago
        It would be a misfortune indeed if I had nothing to complain about.
  • nerdponx 2y ago
    With the caveat that the broadened perspective you obtain by learning a variety of languages will make you better at your primary language.
    • Cthulhu_ 2y ago
      This is true, but it doesn't mean you should actually use a variety of languages for your day job if you're self-employed; that is, you lose some productivity if you choose an unfamiliar tool, and you'll shoot yourself in the foot if you choose a language unsuitable for the problem at hand. The other thing to watch out for if you're in a corporate setting is that if you use a language nobody else is using at your company, your project is doomed and / or it will be stupid expensive compared to other projects because it uses a different language from the rest of the organization. See also https://boringtechnology.club/ https://boringtechnology.club/
    • markusw 2y ago
• packetlost 2y ago
  For me, expertise in a particular language is rarely very useful. Expertise/specialization is mostly a time tradeoff for particularly thorny issues, but IME they rarely come up in a programming language context (usually it's domain or particular codebase-specific). That being said, Go is a really good "workhorse" language.
• read-bird 2y ago
  "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." I liked the use of this wisdom in there.
  • kingforaday 2y ago
    You'll enjoy set theory then. Just call the first set aleph-null.
  • markusw 2y ago
    Thanks! I guess I have moments of insight sometimes. :D
• deleted 2y ago
  [deleted]
• ultrablack 2y ago
  You could have written the same article about C#.
  • markusw 2y ago
    Yes, I definitely could have. But I don't know C#, so that would have been an awful blog post. :D
  • xnorswap 2y ago
    Indeed, this article would read just as well after applying s/\bgo\b/C#/ig, or should I say: Regex.Replace(articleText, @"\bgo\b", "C#", RegexOptions.IgnoreCase); Or indeed most general purpose languages, which the article itself mentions.
    • neonsunset 2y ago
      The C#'s regex engine would have run circles around Go's here though while doing so :) https://github.com/BurntSushi/rebar?tab=readme-ov-file#summary-of-search-time-benchmarks https://github.com/BurntSushi/rebar?tab=readme-ov-file#summa...
• hk1337 2y ago
  This is the same thing everyone says about PHP, negatively. Don't make Go the next PHP. PHP has some good updates recently but it still has some people with a negative experience with it.
  • Cthulhu_ 2y ago
    PHP fell foul of adopting other languages' features to try and make itself more popular though (OOP, typing, err... I don't know PHP anymore), Go is actively resistant to it. Or, resistant as in, "sell it to us" where it's a really hard sell to add something to the language that can already be done in a different way. The error handling debate from a few years ago was great, a few really well thought-out proposals were made but in the end, people were like "...this is not an improvement over how we do it right now".
    • aeyes 2y ago
      You don't have to use all these new fancy PHP features as long as you don't use any third party libraries. I still write PHP just like I did in 2002 and it works. It's not as pedantic as Python which makes it pretty useful for small data manipulation tasks which I have to do every now and then.
• nj5rq 2y ago
  > all popular programming languages can do basically anything That's just very not true...
  • nerdponx 2y ago
    Got an example?
    • randomdata 2y ago
      SQL might be the most popular programming language. Perhaps you can think of something it cannot do, practically speaking[1]? [1] Theoretically it might be able to do anything, but the context is clearly talking about what is, not what could be.
  • jimbokun 2y ago
    It's true in terms of Turing Completeness.
    • zarzavat 2y ago
      Turing complete just means you can simulate a Turing machine. A Turing machine is a mathematical model of a computer, it’s not a real computer. Real computers can do things that Turing machines can’t do, e.g. generating random numbers[0], interfacing with hardware, etc. [0] https://en.wikipedia.org/wiki/RDRAND https://en.wikipedia.org/wiki/RDRAND
  • mapcars 2y ago
    We need some example here, otherwise any language can generate code in the target language to do anything. And in the end all languages generate machine code one way or another so thats pretty much the same thing.
• jimbokun 2y ago
  None of these reasons are specific to Go. They apply just as well to any Turing complete programming language. 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.
  • markusw 2y ago
    Yep, totally agree! But I learned Go, so I wrote about that. :D I tried Brainfuck once, but I don't think my brain can wrap that enough to make it a career.
  • kunley 2y ago
    I wish "any Turing complete language" wasn't used as a catchphrase. Especially that such a claim is so stinky. In what way the Brainfuck programming language environment is giving the coder same experience as Go, huh? Because, if it's not, I just invalidated your claim.
• leecommamichael 2y ago
  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. Use what you want.
  • markusw 2y ago
    I choose to read most comments in a positive light, but thank you for your kindness. :)
  • name_nick_sex_m 2y ago
    You seem to be confusing defensiveness with sharing different perspectives
• daghamm 2y ago
  The author lists multiple reasons for this, but for me the biggest one is the first one: Go is good for almost everything. 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. Why is that? Well, for me there are 3 reasosns: 1. The language is extremely simple. If you know 20% of C you are already a Go expert. 2. The core libraries are extremly well thought. 3. Batteries are included. The toolchain and the core libraries alone can do 90% of what most people will ever need. When people argue about the validity of these claims, I simply point them to this talk https://go.dev/talks/2012/concurrency.slide#42 https://go.dev/talks/2012/concurrency.slide#42
  • kaba0 2y ago
    How is it different than, say, java for this generalist purpose?
    • colonelpopcorn 2y ago
      Just from an ergonomic standpoint it's a million times easier to deploy a go binary instead of a whole jvm and a jar file.
      • pjmlp 2y ago
        When it is a pure Go application, only as CLI or UNIX server.
    • Dansvidania 2y ago
      java on its own is not a competitor to go, IMO, due to the batteries included "culture" in the go ecosystem. I would need to compare it with, for example, Java + Spring(Boot). I find Go to be simpler and more pleasant to use.
      • pjmlp 2y ago
• acyou 2y ago
  Go is not a single tool. It'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're reasonable you can use another brand, where it makes sense. You still should always try to use the right tool for the job. Doesn'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.
  • Cthulhu_ 2y ago
    While this is true, especially in larger corporate settings there needs to be some pushback if someone tries to introduce a new tool, because a new tool or language means you need to include it in hiring and training.
• omeid2 2y ago
  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. No tool deserves more love or loyalty than the productivity it brings, anything more is infatuation and a game for naive and the fool.
  • markusw 2y ago
    It's not really about Go, I think. But it makes me productive, and I like that. I don't think it's a magic bullet at all. Lots of things annoy me about it. But it's _good enough_ for quite a lot of things IMO. But tying shoes with a chainsaw does sound kinda fun. :D
    • omeid2 2y ago
      I completely understand, but the productivity is superficial in my opinion, once you need to dig your teeth deeper into anything not "cloud" and "system engineering" with Go, overall productivity plummets hard. This is from some 10 years of Go experience. But like you say, it is not really about Go; my point is about the illusion of productivity that familiarity brings; it is very deceptive and hurts productivity in the long term.
      • markusw 2y ago
        I don't understand. How can it be an illusion of productivity when it actually produces something that's very easy to see?
        • randomdata 2y ago
          He is saying what is very easy to see in certain contexts is not transferrable to the abstract. Go can be shockingly productive at certain tasks, but it also falls flat on its face at others. If you take your limited experience with Go (or whatever; this applies to all tools) where you found it to be highly productive and then conclude that it is always productive and therefore a tool you can use in all situations, you are bound to encounter negative productivity when you have a different problem to solve. Need to write, say, a network service? Go can no doubt give just about anything else a productivity run for their money. Need to solve a machine learning problem? ... Good luck. It can be done, of course, but you're quite likely in for a whole lot of extra work not needed in other ecosystems, destroying any semblance of productivity. In other words, the comment is a thinly veiled "use the right tool for the job".
• fifilura 2y ago
  Where I feel go is lacking is for data wrangling. Group by, filter, map, join. It is just very error prone, inconvenient and slow to implement with for loops.
  • Cthulhu_ 2y ago
    Go does support functional programming constructs (as it has first-class functions) and there are some FP libraries out there, but they are discouraged because the execution is so much slower; Go is not optimized for FP, and chooses "clumsy" for loops over clever functional programming because the loops have mechanical sympathy and are simply faster in execution speed. That said, if you have a use case with a lot of data wrangling like that, Go may not be the best choice and a functional programming language may be a better fit.
    • zarzavat 2y ago
      Perhaps I’m thick but what kind of programming doesn’t involve data wrangling? What are Go programmers doing that they don’t feel the need for map/filter/etc? BTW there’s no reason why map and filter would be slower than loops, efficiently lowering such functions to loops was solved a very long time ago.
      • Kamq 2y ago
        > What are Go programmers doing that they don’t feel the need for map/filter/etc? As a refugee from a scala project that went badly (we eventually ported the entire thing to go), it's not so bad when you're just using map and filter and friends. But eventually there's so many of those little methods each with their own nuances and I don't want to have to remember them all (`sliding` comes to mind), and it's just exhausting. I don't want to deal with it any more. The for loop is freeing, I've written the map/filter/reduce/groupBy functions a couple time, but I never end up using them. I don't miss them anymore. I guess, those methods were sold to me originally as less powerful than a for loop. You had guarantees about what they're doing, and eventually there were enough of them that something flipped. The for loop feels easier. I can see everything that it's doing. It's all right there. Same things with monads after a certain point. Result/Option are sorta fine, but I'd rather just deal with remembering to close a file than use a Resource. I don't want to have to think about Semigroups and Applicative Functors. I just want to call the function and do the thing. Eventually FP felt like my experiences with bad OO projects where I spent 80% of my time trying to figure out the platonic ideal of something and where it fit to make everything elegant. And then tracing my way through things was significantly worse when things went wrong (and they did still go wrong). I decided it wasn't worth it. And, yeah. Sometimes I find a gronky loop somewhere that's doing too much. I just re-write it while I'm passing through so it doesn't get out of control, and I move on.
• curious_cat_163 2y ago
  I grew up writing C/C++ and I could write this same blog post but about Python for the same reasons that the author cites :-) 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.
• andrew_eu 2y ago
  I can't really disagree with the points the article makes in favor of Go, and it's not selling it over some other language/framework/tool but just celebrating how great of an ecosystem Go has. And it's true -- Go's ecosystem has matured into something very pleasant to work with. By the same token I know professors who still write their simulation scripts in QBASIC because that's what they are familiar with and they can solve their problems quickly. You can use all sorts of tools to drive a nail. On Go, it'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's not unique of course -- tons of languages have some FFI solution for C libraries -- but Go's is I believe one of the most straightforward to use if you're already familiar with the language. And while there are portability/stability sacrifices you make when you call a native library, it does also expand the available dependencies even beyond "basically infinite." [0] https://go.dev/blog/cgo https://go.dev/blog/cgo
  • markusw 2y ago
    You're totally right about CGo. For example, I'm very happy that I can use the insanely well-tested original SQLite C library directly in Go, and sleep easy that it's not some half-ported pure Go library. (I know there's an auto-transpiled SQLite lib as well, which is probably just as good. But then I have to rely on no bugs in the transpilation process, and I don't like that. That may be superstition though. ;) )
  • ljm 2y ago
    You might like Zig too. The C interop is amazing. Last time I checked you could use Zig to just compile C straight up.
  • metaltyphoon 2y ago
    Go has one of the worst FFI support IMO. Code as comments? It doesn’t ever support C callback without a “bridge” method. MSVC support? Try debugging when CGO is enabled. Worst of it all, it’s also one of the slowest too.
• BrandoElFollito 2y ago
  I like that. I have a similar attitude with Python and Go as back hammers and Quasar (Typescript + Vue + Vite + components) as the front hammer. Whenever there is a date in Python I exclusively use Arrow (even for the simplest, most basic ones). 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. I leave this for home automation and docker services where my motto is "fix it until you break it"
• deergomoo 2y ago
  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. The tooling is heaven compared to other stuff we do a lot of at work (TS/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!
  • znkr 2y ago
    I have been writing Go code for many years, the fact that I don’t need to think about things unrelated to the problem I am trying to solve is why I love Go. I definitely learned a lot about Go and I am thinking more about certain aspects than before, but usually only in the context of API design.
  • theshrike79 2y ago
    The "not having to think" is the best bit. There are no fancy ways to do things, only the simple way. If something feels like it's hard to do it's either the inefficient way to do it or the wrong way.
• bborud 2y ago
  People always under-estimate the cost of properly learning a language. At any given time I tend to have a "main go-to language". I typically spend 2-4 years getting to the point where I can say I "know" a language. Then I try to stick to it long enough for the investment to pay off. Usually 8-10 years. A surprising number of people think this is a very long time. It isn'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.
  • cube2222 2y ago
    Agreed. Having a passing knowledge of many languages is of course easy (even being moderately productive with them, esp. with Copilot now), but knowing the ins and outs of a language and its ecosystem is a very nontrivial time investment. Thus, I'm mostly an anti-fan of the idea of polyglot environments.
  • oooyay 2y ago
    By now I know three major languages: Go, Python, and Typescript. I know tradeoffs at-a-glance, I deeply understand the syntax and its various forms, the full array of tooling and what they do, and lastly (but maybe most importantly) I can estimate more accurately because I can architect in my head. I can work in a myriad of other languages. I may be able to do some of the things above in Java or Rust but not nearly to the degree to which I can in languages I know. I think the difference is I'm probably not going to be leading a Java project or producing anything really innovative at a code level. To me, more important than picking a hammer, is knowing a variety of hammers that are good at certain tasks. I don't focus on Rust or Java as much because, frankly, I can build most things that are pertinent to the constraints of my work environment with those tools and most people I encounter also know them. The other considerable factor I have is that most things I work on can be horizontally scaled so my need for Rust is very niche. With respect to Java, I have a lot of workarounds that are cleanly abstracted enough before I need its dynamism and subsequent mental overhead.
  • 2y ago
• igtztorrero 2y ago
  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. I would like a tool in go, that could handle nice GUI, compiled for WASM and run in the browser. Any ideas? I will follow you @markuwsw.
• ManBeardPc 2y ago
  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. I certainly think other languages (Java, C#, Rust, JS/TS) have a lot of advantages over Go in some areas, but everything I've worked with so far has some other aspects that I absolutely hate. POV from a (mainly) B2B fullstack SE
• lairv 2y ago
  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. 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
  • Spartan-S63 2y ago
    I agree with this take. I find Rust a more exciting language from a personal project perspective—and it's what I go with even when it doesn't make 100% sense. Go is fine, though, and works well in a team environment. It's just clunky, but clunky in a productive way.
    • HKH2 2y ago
      Rust-script + cmd_lib = scripting using shell, and converting it to Rust when I want performance. I know it might sound dreadful but it works well for me, especially without an internet connection.
  • stuff4ben 2y ago
    Damn, everything new really is old again. Everyone said the same thing about Java. Yet it still works and gets the job done. Go does as well. I'd rather poke my eyes out with a nail than use Python.
    • the_gipsy 2y ago
      Do you write Go for fun as hobby, or do you agree with the OP?
      • stuff4ben 2y ago
        I don't program as a hobby or for fun anymore. It's my job and I do it, then I go home and do non-programming there. I use Go and Java and occasionally Python if I have to. I do agree with the OP though.
• anonzzzies 2y ago
  I find Go akin to C ; it'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. I use it when I cannot use CL (for basically everything) or Racket (language / code generation), which basically means 'if my clients doesn't accept the above'. For web/desktop/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. I guess I have two hammers; one of them has a more comfortable handle for whacking in those slightly more difficult nails. Lately I cheat by using a subset of CL and generating the Go code.
• cybrexalpha 2y ago
  I've been coding in Go for over five years. I like Go, but I don't love it. It's never my first choice, although I don't advocate for rewrites just to move away from it. The tooling is a mess. Go modules still feel like a 'first pass' implementation that never got finished. There'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). It still feels very unfinished as an ecosystem. I hope it'll get better as the Go team mature things, like iterating on generics. But I can't see Go modules continuing without a fundamental rewrite.
  • acedTrex 2y ago
    What do you mean by no consistency in formatting? go fmt is a solid formatter that does its job
    • cybrexalpha 2y ago
      Go fmt is pretty good, but it's not ideal. My biggest gripe is imports. Go fmt will just sort imports alphabetically in lists that aren't separated by a blank line. Goimports will separate out core from 3rd party imports, unless you run it with the local flag then it'll add a third block of "local" imports. But this spread means that it's not consistent across projects which style is preferred. Some examples, based on cursory looking at big Go codebases: - Kubernetes, one of the biggest public-facing Go projects, uses the 3-block style https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/cronjob/cronjob_controllerv2.go#L19 https://github.com/kubernetes/kubernetes/blob/master/pkg/con... - TIDB uses 2-block style https://github.com/pingcap/tidb/blob/master/pkg/ddl/placement/bundle.go https://github.com/pingcap/tidb/blob/master/pkg/ddl/placemen... - MinIO uses 2-block https://github.com/minio/minio/blob/master/internal/grid/connection.go https://github.com/minio/minio/blob/master/internal/grid/con... In all of those cases if you make a change and just run 'go fmt' it very well could inject any new imports in the first block, which would be wrong and you wouldn't know until project CI picks it up.
      • zik 2y ago
• stuff4ben 2y ago
  Java was my hammer back in the day. In a few more years, I'm banking on it being my post-retirement "daddy needs a new boat" solution.
• jillesvangurp 2y ago
  I understand the sentiment. My goto hammer is Kotlin, which I like a bit better than Go. But that's a highly subjective thing of course. And I use plenty of other languages as well (including very occasionally some Go). It'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. IMHO we'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's are all there. Using them might not be the fastest right now but I'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's not really a show stopper unless you are doing this many times per second. 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'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's 2x compiler performance right there. 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'm sure some will be upset about that. But that would be mainly because it's their preferred hammer.
  • markusw 2y ago
    Yeah, WASM is interesting! I haven't followed the space at all, but I guess the browser is the new JVM? :D
  • ridiculous_leke 2y ago
    I am planning a switch to Kotlin just because it seems more readable. As someone who has done both how do you rate Kotlin's STL?
    • jillesvangurp 2y ago
• hintymad 2y ago
  > So, what, I’m going to limit my career options? I don'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't believe that an engineer should be identified by a language, as in a Go programmer, or a Java programmer.
  • markusw 2y ago
    But often, a client needs a developer for an existing stack, and advertising as a Go programmer (for example) gives you an edge over someone who doesn't, in my experience.
• bitbasher 2y ago
  Life is barely long enough to get good at one thing so you should choose your thing wisely. That's wisdom I've held for quite some time. 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: - incredible standard library - simple to read and write - single static binary builds (assets included, like html/images, etc) - don't need a container (my binary is the container) - can be used anywhere (webdev, desktop apps, gamedev, embedded, etc)
  • jayd16 2y ago
    What game engines use Go?
    • jayd16 2y ago
      I should say what 3D game engines use Go?*
      • throwawaythekey 2y ago
        Not sure if you're being intentionally cheeky by pointing out a use case one wouldn't use Go for but will answer anyway. A language with a GC (like go) typically isn't a good fit for a 3d engine. Almost all serious engines are C++, at least for the core code, for that reason.
        • jayd16 2y ago
          > pointing out a use case one wouldn't use Go for but will answer anyway. The thread is about using Go everywhere and I make games so I'm asking about it. Unity and Godot have C# scripting which most game code will be in. Unreal has garbage collecting for game assets. GC is just another tradeoff to work with and certainly not a deal breaker for games. I'm mostly curious about whether someone has done the work to integrate goroutines with a 3D engine in a performant way as typical techniques require a lot of synchronization with native threads that seem at odds with Go's design. But I'm curious to see it done.
      • 2y ago
• textlapse 2y ago
  Heard from someone: "C++ is a hammer, but then everything starts to look like your finger"
  • zupa-hu 2y ago
    had such a good laugh, I’m going to steal that :)
• blt 2y ago
  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'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. 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...
  • gcau 2y ago
    Is this something Go intentionally didn't add?
    • sbhitz 2y ago
      https://go.dev/doc/faq#overloading https://go.dev/doc/faq#overloading
    • jagged-chisel 2y ago
      Yes. Because "things are simpler without it." Presumably "simpler" from the point of view of the language implementer as opposed to the user of the language.
    • abtinf 2y ago
      Operator overloading essentially makes code unreadable without deep diving past the interface boundary. In Go, you can generally look at any snippet of code and know precisely what it does.
      • dsfasfd 2y ago
        Not having operator overload making the code more readable is the same argument that was brought up with generics and it is still false. Go does have operator overloading, for example + is overloaded for float.., int.. and even non numeric types like string. And it does so for a very good reason: having operator overloading makes code much more readable when used correctly. It's just that the language designers didn't trust their users. As long as you know the types of x and y you always know precisely what x + y does, same as you know what x.Add(y) does. There's no difference.
• azangru 2y ago
  > Go is my hammer, and everything is a nail > Less context switching For the very same reason, my hammer is javascript.
• beepbooptheory 2y ago
  I know its great and powerful but Go was always the "Google language" to me and as an unsufferable hipster that just turned me off to ever touch it. 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'm just learning Marvel lore.
• jmull 2y ago
  > 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 Sounds like they are choosing the right tool for the job. When considering languages, familiarity is a significant aspect. And, the smaller the duration/size of the project, the more significant it is. A decent analysis wouldn't ignore this. If the language you're most productive with is appropriate for a project (and go is appropriate for a wide variety of things), you need a good reason not to use it.
• adrianlmm 2y ago
  Does go even have a Generic list (ArratList in Java)?
• w10-1 2y ago
  Granting the indie-dev, limited resources, focus-is-good, to me the key is enablement by available libraries, platforms, IDE's, language survival and importance, etc. -- none of which the author mentions. Java for the most part has libraries and IDE's due to its history, but got tripped up on the essential web platform story: it's only achingly small/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). Go is great if you're on the server side with Google-like concerns, and it's unlikely Google would ever drop Go. 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. 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's handled by a few heroes. And unfortunately, libraries are sort of an open-source zoo of minor offerings. But Apple's betting the company on Swift, so you can, too. Python pretty much lucked into popularity by supporting the scientific computing that would become data analysis and AI after building significant community inertia. It's sort of the default prototyping language in a time when prototypes are often good enough. It's gradually been adding typing and performance to stay good enough. 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's also where the money is now for most developers. 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/demand curve favors you. And as far as I know, there's no good data on point for that.
• insane_dreamer 2y ago
  I would argue that a language'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're doing numeric or scientific related development, it'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.)
• riiii 2y ago
  Go is nice but people either love or hate the error handling. There have been some good proposals but because people are so passionate about all their requirements and edge cases, that I don't think it'll ever get improved.
• danpalmer 2y ago
  I think opinions on Go depend on the quality of code you'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' opinions, I suspect it also doesn't let the bad code get too bad, which if you're used to bad code, is desirable.
• deleted 2y ago
  [deleted]
• iaabtpbtpnn 2y ago
  If you’re going to insist on using the same tool for every job, at least pick a better tool.
• whateveracct 2y ago
  s/Go/Haskell and I feel this 100% when you have a programming language that can do everything and vibes with how you think, you're golden
• ninetyninenine 2y ago
  Been using go for nearly a year. Don’t like the strange formatting and naming standards and arbitrary rules surrounding it. 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. 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. 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. 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. 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. 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. 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.
• 999900000999 2y ago
  The article claims Go supports building GUI apps and links to this. >Wails is a project that enables you to write desktop apps using Go and web technologies At that point why not just use Electron and Node JS. I like Golang, I truly do. But after building mobile apps in both Golang and Fluter, I'm well aware of Go's limitations. Making anything look remotely nice is painful. Things get really difficult when you use the wrong tool for the job. 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't collapse. C# is also a contender, but people, particularly the FOSS crowd doesn't like it because Microsoft == Bad.
• theappsecguy 2y ago
  I really want to love Go for side projects but it’s just so verbose and time consuming. 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. At least as far as web dev goes, I’m sure Go is great for other stuff.
  • srameshc 2y ago
    Back in 2012 or sometime around it, I was trying Akka a Java library and trying concurrency and stuff. Around the same time I gave Go a try and it was much less verbose and simple. Never looked at Java after that, but I never felt Go is verbose.
• greenSunglass 2y ago
  I like using this great library to build progressive web apps using Declarative Syntax https://github.com/maxence-charriere/go-app https://github.com/maxence-charriere/go-app
• FrustratedMonky 2y ago
  Wish I could dedicate life to one language, like F#. I think you'll have better luck doing it with Go.
• corn13read2 2y ago
  Go is terrible at shell scripts. Too bad it’s not more like python that way.
  • gen2brain 2y ago
    Check https://github.com/bitfield/script https://github.com/bitfield/script for shell-like scripts in Go.
• bitwize 2y ago
  Same, but s/Go/Scheme/g. For over 20 years now.
• WuxiFingerHold 2y ago
  That's why Typescript is my hammer, unless I need a jack hammer, which is Rust. With Deno and Typescript I get an even more versatile toolbox than with Go. And what'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. Especially strict (which is a must) Typescript is underrated. Compared to Go, we get: - null safety - widely supported generics - discriminated unions with either manually (some lines of code) or es-lint exhaustiveness checks - 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. - collection / iterator methods So far, I see only few downside. I'd be happy if people could provide more. Currently I'm scratching my head why I didn't fall in love with Typescript (for backend and CLI) earlier. Maybe I haven't seen the dark sides yet. So, some points where Go is stronger than Typescript: - Go is much more efficient in terms of size and memory usage - Go's GC is better than V8s - Go is faster on CPU bound tasks - Go has a greater std lib, however, Deno's std lib is pretty nice as well. - 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. What else could we say against Typescript (and preferably Deno or Bun)? I'm really eager to hear people having ditched it an why.
  • scubbo 2y ago
    Amen. I was unreasonably opposed to TypeScript at first after lots of bad experiences with messy JavaScript when I was first learning development - but after immersing myself in it for a year or so at $NEW_JOB, I absolutely love it. The only ways in which I can see that Go outperforms TypeScript is in performance, but frankly I don't care and most developers shouldn't - unless you're writing truly low-level high-performance utilities, you should (within reason) bias for being able to write (and iterate) fast over being able to execute fast. You can always re-write in Rust if you find that performance is a bottleneck.
    • Escapado 2y ago
      I have been using typescript as my primary language for years and since I am used to it I actually enjoy it (much more than I enjoyed Java or Python in the past). And depending on what you built I agree, especially for one off scripts or if you plan on hosting just one or two things somewhere. On the other hand I recently saw a video by webdev Cody that got me thinking, where he was comparing a dead simple api server in go and in bun hosted on railway and their memory usage was different by an order of magnitude in favour of go plus you can compile your program down to a few megabytes instead of bundling a ~100megabyte runtime. So if you have a couple dozen of side projects where you host servers/apis that difference can end up in a noticeable operating cost differential. He made a few other points such as throughput, the more complete standard library and tooling such as go fmt and that writing the equivalent server in go wasn’t really all that different from the typescript code. You’re right that rewriting is always an option but for all over the place folks like me the next 3 projects are half done before I even think about optimising my hosting bill. But as I said, strongly depends on what you build. I guess there are no winners, just tradeoffs. I wonder if one use case for llms in the future could be feeding a sizeable typescript/python codebase into it and then have it spit out an equivalent in idiomatic rust/zig/c. I am aware that transpilers and assembly script and static Hermes exist but what I mean is more of a result that produces a maintainable rewritten version making use of the idiomatic libraries and coding conventions of the target language.
• synergy20 2y ago
  go can't do GUI go is too fat for embedded systems, tinygo won't cut it if I can script it why should I use go go can't really do web .... no one language covers it all
• mayoff 2y ago
  Related: Java for Everything https://www.teamten.com/lawrence/writings/java-for-everything.html https://www.teamten.com/lawrence/writings/java-for-everythin... Previously HN discussion of "Java for Everything": https://news.ycombinator.com/item?id=26934297 https://news.ycombinator.com/item?id=26934297
• KingOfCoders 2y ago
  Same here, as a solo entrenpreuner who is 50+, I love Go for it's simplicity. And e.g. migrated my Newsletter generation pipeline from Python to Go.
• surfingdino 2y ago
  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/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/multi-core CPUs. I've been in Python by day client work), Golang by night (my own work) mode for many years now. It's a great language. OK, I do admit to learning Rust, but... it's just out of curiosity, not out of need for anything "better".
• pkolaczk 2y ago
  I feel the same, but for me Rust is currently my hammer ;) Checks all of the checkboxes.
• liampulles 2y ago
  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.
• indulona 2y ago
  Same here. the things i do, go is great. for front-end, i use quasar(vue/js). that's all i need. if i ever need crazy performance, i'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's more about it being GC language more than anything else.
• afiodorov 2y ago
  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. I totally understand why some people prefer Go in production to Python, but I could never understand why people wouldn'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. In the end, I didn't think it was a good use of the company'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.
  • physicsguy 2y ago
    I've had exactly the same experience, it's a nice language but using it for things it's not suited for like data exploration makes no sense to me. Production data pipelines on the other hand, but only after testing them well and as you say, making sure there's good testing if you're implementing things like numerical routines.
    • Lyngbakr 2y ago
      Do you have experience implementing ETL pipelines in Go? I think it'd be a better fit for us over our current language, but I'm curious to hear from people who've actually done it.
      • fifilura 2y ago
        What is current language and have considered doing it in SQL? I don't think go will be the right choice. It is just not its strength.
• OezMaster 2y ago
  Does the same apply to 'platforms'? For example, is it better to learn C# + F# + Powershell instead of C# + Scala + Bash?
• laerus 2y ago
  The fanboyism, in this thread, for such a mediocre language is disappointing to say the least.
• lcof 2y ago
  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. 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.
• todotask 2y ago
  JavaScript and TypeScript are the hammer. Go as an oil lubricant. C# as a Swiss Army knife. Java as a toolbox.
• wejick 2y ago
  I recently tried to setup a PHP / 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't work, broken. I assume that way Laravel created Sail, which I didn'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.
  • _xiaz 2y ago
    At the same time using purely php is about as convenient as it gets. Just rsync, ftp or scp your index.php to the server and deployment is done. PHP+Laravel is more akin to ruby on rails or python django. Pure PHP is similar to Go in terms of the deployment scenario
• jpgvm 2y ago
  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. Kotlin/JVM became my hammer and I currently don't feel like there are any gripes I have about it except maybe that the Gradle/Maven dichotomy and associated anxiety that build systems give people makes it harder to sell people on it. Otherwise language feature wise and runtime wise it's about as good as you are going to ever need for 99.99% of (non-frontend) use cases. You have C++/Rust/Zig to fill in the few places where a runtime isn't viable.
  • markusw 2y ago
    I'm happy you found your hammer as well! :D
• markusw 2y ago
  I CAN’T BELIEVE NO-ONE HAS MENTIONED MY BEAUTIFUL TYPOGRAPHIC LAYOUT YET. :D Just look at this beautiful test page [0]. I’m pretty sure I spent more time on that than on the blog post. 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. Also, the newsletter subscription is up now, if you’re into that. [1] [0]: https://www.maragu.dev/typography https://www.maragu.dev/typography [1]: https://www.maragu.dev/blog/go-is-my-hammer-and-everything-is-a-nail#newsletter-form https://www.maragu.dev/blog/go-is-my-hammer-and-everything-i...
• jebarker 2y ago
  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.
• Daunk 2y ago
  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.
  • giancarlostoro 2y ago
    In my case after hearing one of the main devs of Go (I forgot his name tbh) in an interview saying they'd NEVER implement generics, it just rubbed me the wrong way. The other thing is, despite having touched Go since its early days (late 2000s) I don't have enough real world experience with it. I'm too self-critical to ever apply for jobs I don't feel confident in. So until someone just offers me work with it I probably wont use it as much as I could.
    • sethops1 2y ago
      > it just rubbed me the wrong way. On the other hand, they did implement generics - indicating a willingness to listen to community feedback and change their position. Isn't that what you want in project leadership?
• anta40 2y ago
  "Reason 1: Go can do basically anything" 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...?
• koeng 2y ago
  For me, this is very true. Most bioinformatics is done in python, but over the last ~4 years I've ported everything I do over to Go: https://github.com/koeng101/dnadesign https://github.com/koeng101/dnadesign I'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't experienced that in other languages. I've learned other languages quite in depth, but with Go it is simple enough that when I write code, I'm not thinking about code, it is purely the problem being solved, and the code just comes out onto the keyboard. Ironically enough, I've recently started porting my entirely-go bioinformatics package to be a python package, mainly because I realize I'm not gonna convince everyone else in my field that Go > python
• Decabytes 2y ago
  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
• pradn 2y ago
  It'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 "batteries" to the "batteries-included" mindset. And they put community and ease-of-use first, which are crucial for adoption.
• pradn 2y ago
  I'm totally with this idea - use the language you know best for mundane tasks. I used to switch to shell or Python to do one-off scripts. But there's not a super great reason why I can't do the same in C++, which is what I know best. All the build stuff is easy to do in my company's repo, so that's not a big blocker.
• brass9 2y ago
  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. > 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/JVM.
• mathfailure 2y ago
  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. 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.