Go is my hammer, and everything is a nail

https://www.maragu.dev/blog/go-is-my-hammer-and-everything-is-a-nail

by markusw • 2 years ago

479 797 2 years ago

maragu.dev

__s• 2 years ago

as the saying goes, when you're a nail the right tool is always a hammer

markusw22• 2 years ago

I guess we're at "I am Go and also a hammer and all the nails" then. :D

lawgimenez2• 2 years ago

I wish Go had a decent UI framework though.

lagniappe• 2 years ago

Go has FyneUI, and it's great

bborud13• 2 years 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)

neonsunset14• 2 years 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• 2 years ago

Cogent Core looks promising.

Propelloni• 2 years 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".

lawgimenez2• 2 years ago

I mostly work on Swift and macOS, so SwiftUI.

theshrike7912• 2 years ago

Anything that has a visual designer where I can combine drawing and drag&dropping components and code depending on my needs.

Cthulhu_9• 2 years 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.

theshrike7912• 2 years 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.

DarkNova68• 2 years 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• 2 years 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.

markusw22• 2 years ago

Yup, this exactly!

busterarm5• 2 years 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.

ergonaught2• 2 years 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.

Thaxll2• 2 years ago

Protobuf is not the default in Go the default is REST. What tools are a mess? Go tooling ( runtime ) and IDE integration is very good.

Go is not a hyped language, we're past that cycle, some critical and widely used software are built in Go, millions of people rely on it.

markusw22• 2 years ago

Author here. Well, it has worked pretty well for me so far, so I don't know why I would switch. Go is fast and expressive enough for my use, and it's probably outweighed by being super familiar anyway.

(BTW, in my eight years of Go, I think I've used protobufs maybe once or twice. HTTP FTW!)

azthecx2• 2 years ago

Do you have better alternatives to Protobuf?

What are the shortcomings that you find with it? At work these choices have been out of my hands but I've used JSON Avro and Protobuf and I felt like Protobuf was the least prone to errors, best surrounding tooling and easy migrations while maintaining small payloads.

azthecx2• 2 years ago

Do you have better alternatives to Protobuf?

jimbokun11• 2 years ago

Faster on what axis?

Go has maybe the fastest compile times, for example. Which is very important when you are iterating on a project.

What do you dislike about the tool chain? Seems better than most languages to me.

moomin• 2 years ago

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

kamikaz1k• 2 years ago

Go is getting hype because TS is old news. And people got tired of being nerd sniped into trying Rust and being let down.

It’s okay, hype cycles are good since it shakes up mainstream opinion and gets people to try stuff. Like a new trendy food. I don’t feel much in the ways about it.

How do you feel about Go outside of the hype cycle?

auggierose• 2 years ago

How is Go not older news than TS?

DarkNova68• 2 years ago

Go is getting hype because TS is old news. And people got tired of being nerd sniped into trying Rust and being let down.

Sounds like my impression as well.

How do you feel about Go outside of the hype cycle?

I think it's in a weird place, but I have a much higher opinion of the language ever since it got generics.

There is nothing which is inherently unique to Go, but it got some neat technical features: Static compilation, garbage collection, good model for multithreading, fast compilation times. With these qualities you can get pretty far and have good cloud readiness.

However, I'm a Java guy and the JVM is my working horse. I have seen how large projects (don't) scale once you have 8+ developers and there are shortcomings in Go for projects of this size. And I think the explicit nature of nominal typing (e.g. Java) absolutely wins over the implicit structural typing one (e.g Go).

You see this difference of philosophies by interface constraints: Java interfaces must be implemented explicitly and you can even limit who can implement them. Java is primarily a language designed for libraries & frameworks and the quality shows it.

With structural and open implementation of interfaces, your line of code-ownership becomes blurry. This is not nearly as problematic as dynamic typing, but in my mind an interface is a specification. And you there should be a contract between the provider and consumer. This also helps with understanding the connections inside/between code-bases.

Same about interfaces can be said about First Class Functions vs. Functional Interfaces. Functional Interfaces can be documented, domain-specific, extended and implemented. It feels like a perfect blend of FP and OOP, whereas with First Class Functions I feel like I am working with C-stylee primitives which don't help me express the nature of the solution I want to model nearly as much.

As for Java, I have an immeasurable amount of respect for the current language designers (can't say I have the same respect for Go Designers after the drama surrounding generics). I am an avid reader of their mailing list and time and time again, they have shown deep thought and tremendous foresight (their way of work is quite inspiring). Yes, they have to live with some nasty historical baggage, but they have a very high level of quality.

Then there are aspects such as the ever-evolving JVM, along with its choice of several garbage collectors and top-tier runtime analysis (Flight Recorder) & optimization (Hot Spot).

Sorry, this is entirely subjective but you asked me how I "feel" about it :-)

Summing it up, I'd say Go is a comfortable local maximum which can give you a whole lot, but ultimately is less flexible. But it's surely enough for 90% of applications. In this sense Go is like the big brother of PHP, which is a perfectly reasonable language if all you need in your backend are save/load database operations. Go can cope with that too, but also scale into non-trivial domains, the cloud and multi-threaded problems.

But Java is "corpoaraty" and not "trendy", so most people don't even consider it as an option. And there are enough bad devs who started their carreer in JS/TS and want to move towards something more performant, that is still as ad-hoc and don't mind sharp edges because they never learned to reason about their application in a more formal sense.

But looking at the work that is currently being done to the JVM, I'm looking forward to the near future when we can run Java-compatible bytecode on GPUs and AVX512.

neonsunset14• 2 years ago

Thanks for posting this.

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

(I prefer to think of it as a crowbar ;D)

mapcars12• 2 years ago

The problem with C# is its created by Microsoft, even if its a good language its hard to look at it and not think how much its limited while used outside of Windows.

markusw22• 2 years ago

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

danielvaughn4• 2 years ago

I just began using Go literally 2 days ago, but I could already see building most of my projects in it from here on out. It has the type system I'd need from Java or C#, while being almost as simple and readable as Python. I love the module system so far and enjoy not having to decide on my own formatter.

Go is perfectly boring and simple, and seems to get out of my way. At least, that's how it feels as a newcomer. I'm sure it will change over time, but I'm having a blast at the moment.

mapcars12• 2 years ago

Just looking at Go after having experience with Erlang and Crystal, does it still have a narrow-minded view of what features language won't support?

Like I remember there was a whole drama about generics, errors being simple strings and always returned without being able to raise them, is this attitude still there or have things changed?

DarkNova68• 2 years ago

And this is a perfectly reasonable approach. Frankly, the cost/benefit ratio of delving into another language is most often not appealing.

As a suggestion, you could have delved more into the "hammer" metaphor, mentioning that a hammer is a flexible tool: nail planks, remove nails, smash things and even as a defensive weapon! You shouldn't misuse it for drilling walls, but that is outside the required scope of your work etc.

But in the end it's a very personal post, and we typically crave here for universality and judge posts up high from a meta-perspective, haha. Often neglecting that we were not actually the intended audience.

jimbokun11• 2 years ago

I'll give it a shot.

The tools make a lot of decisions for you that are pretty arbitrary, like how to format code, freeing up brain cycles for other things.

It compiles very fast, so the iteration cycle is similar to a dynamic language with a REPL. Very little time between making a change, running and seeing the new result. The language is designed from the bottom up for fast compile times even in large projects, with features at odds with fast compilation rejected.

Decent sized community and library ecosystem.

The networking APIs are very simple and productive. More and more back end code is being written in Go for this reason.

The semantics are straight forward. The other programming environment I need to deal with at work is Spring Java, which is unjustifiably complex and obfuscated for what it does. Go allows you to read the code and run the program in your head understanding semantics and performance characteristics.

Builds single file executables that are simple to deploy.

Has just enough high level features to be productive without compromising above points about simplicity, fast compiles, and comprehensibility. Channels and go routines work very well to model concurrency across a wide array of problem domains.

Maintainers are careful about adding new features. Generics took a long time to arrive, but when it did was very well thought out and did not negatively impact performance very much.

I'm sure I'll think of more.

alemanek2• 2 years ago

I am someone with significant experience in Java, C#, C++, and JS/TS. I am a bit of a newbie to Go but have used it for a few things at work. So, I can give a bit of a comparison for you.

I really like the DevX and strong standard library of Go. Also I really like that the community around Go has a strong preference for just using the stdlib and not going crazy with third party libraries.

Languages are just tools but I have a strong preference for Go for backend services and CLI applications now. Just my 2cents.

DarkNova68• 2 years ago

Hey, thanks for the reply. That sounds really nice!

I wonder, which aspects of the "Go" std lib are considered strong? Would you say it is more like .net where the std-lib also comes with framework-grade capabilities such as REST-endpoints and setting up applications?

Because in the classical sense of a library, I think Java is fantastic (collections, strings, NIO, HTTP 2.0, etc.). But it misses framework-level out-of-the-box solutions.

daghamm2• 2 years ago

How can you call Go hype driven?

It was literally designed to be "boring".

cy_hauser3• 2 years ago

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

gnfargbl2• 2 years ago

It feels extremely strange to see Go described as a "hype" language. It was somewhat hyped around seven years ago, which is when I started using it almost exclusively. Before that, it had a strong hype peak about fourteen or fifteen years ago, just after it was born.

However, it's not a young language any more. At this point I would actually submit the opposite criticism: it is a mature language which is perhaps starting to suffer from middle-aged spread, as the bored maintainers start to stuff in more features which the language doesn't genuinely need. (Example: Iterators. Sure they're nice, but does the language really need them?) If anything, I would say it's going more the way of Java than Rust or Node.

kaba08• 2 years ago

Count the number of posts with Go in the title, vs any other programming language. It easily beats out everything both here and on lobsters.

bborud13• 2 years ago

I think the hype has already peaked for Go. When we switched to Go 8-9 years ago I already felt the hype had died down. We were late to the party. And I saw that as a good thing. To me it suggested Go was going to stick around.

And now, almost a decade later, we're still using it.

Note that at my company, we're a bunch of grumpy old guys with about 30 years of experience each. If you dangle a new and shiny language in front of us, our default instinct is to tell people to get lost. We don't do "fashionable". We tend to make investments in learning languages that we expect to get at least a decade out of.

And I don't think Go is succeeding Rust. From what I can tell, people are going in both directions.

jerf4• 2 years ago

Go and Node have some significant overlap, but Go and Rust are barely even competitors. Of course there's a lot of programs that you can use either to write. There's a lot of programs where it hardly even matters which language you pick at all because they're all perfectly acceptable solutions, though, so that really isn't saying much. But if you map languages out by the programs where language choice matters at least a little and where a given language is legitimately one of the top contenders, Go and Rust don't have a particularly strong amount of overlap in my opinion. They do, but again, lots of languages have overlap; I don't see the Rust/Go relationship being particularly heavily overlapping. (Go/Java or Rust/C++, now there's overlap, for comparison.)

gavindean90• 2 years ago

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

caerwy• 2 years 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• 2 years ago

Which is unfortunate because I think Go is very useful in a wide variety of business contexts.

the_real_cher• 2 years ago

Then you would find this article very fortunate.

nerdponx3• 2 years 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_9• 2 years 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/

markusw22• 2 years ago

I would say there are many, many other ways to broaden my perspective, not just learning and using a different programming language. There are so many things to learn!

(And I don't necessarily suggest not learning different languages, if one fancies that. I just don't use any other ones at the moment.)

markhahn2• 2 years ago

I always wonder: why do some people like to do this (spreading)? I wonder the same about people who are "distro tourists". The latter tend to spend a lot of time on what seems like unproductive diddling (desktop skins, etc).

randomdata26• 2 years ago

1. Because I like engineering more than programming. If a problem is best solved by, say, a mechanical system then I will do that instead. But even where programming provides the best solution, not all ecosystems are equal. If I have a problem best solved by, say, AI/ML, it is often impractical to avoid Python. Likewise, if I have a problem best solved in the web domain, it is often impractical to avoid Javsacript. SQL where databases are the best solution. So on and so forth.

2. Because I like to learn. In my younger days, I found a lot of value in exploring the different ways people live. In fairness, I've toured the programming world enough by now that I am less compelled to keep go on "programming language vacations" – at some point you start to feel like you've seen it all, but believe I would be a far worse programmer today had I not been able to take ideas from a wide range of different cultures over the years. There are some good ideas out there that don't seem to ever gain mass adoption outside of their originating ecosystem.

CodeMage• 2 years ago

Because there's so much to learn from having different perspectives.

Back in 2006, I was working mainly in C with a bit of C++. One of the things I was taught was that "macros are evil", period. Then, in my spare time, I decided to try Common Lisp. I had a blast. I never wrote anything more useful than a half-assed catalog for my MP3 collection, but I learned a lot. My main takeaway was the power of metaprogramming -- with all of its footguns and pitfalls -- and took that knowledge with me to my day job, where I suddenly had a more nuanced view of how preprocessor macros can avoid being evil.

Later, when I changed jobs, I went back to Java, which was my main language before the C stint. I slipped back into the comfort of having my memory managed for me and the expressiveness of OOP. But in my spare time, I discovered Self and Io, and the fact that you can have OOP without classes blew my mind.

At that same job, I undertook the task to make our proprietary in-house language not only transpile to C++, but also compile to be executed on JVM. Understanding how JVM bytecode instructions work was easier than it might have been had I not dabbled in Forth in my spare time.

These days my day job involves working with C++ full time, but my hobby projects in Rust taught me to structure my thinking about the ownership and lifecycle of memory allocations.

So yeah, most of what I do in my spare time with other languages is largely "unproductive diddling" if you only look at the code I write in those languages, but the insights I take away with me are useful.

Also, it's fun ;)

matwood3• 2 years ago

I can think of many reasons. Seeing other language perspectives definitely can help with your primary language. I have experienced this. But, I have also explored other languages as a means of procrastination or ways to do something easy when bumping into the more challenging depths of my language of choice.

intelVISA• 2 years ago

Diff langs have their strengths and weaknesses, the same reason you don't build every object out of concrete "because it's tough" you don't build every service out of Python (because it's slow).

packetlost• 2 years 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• 2 years 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• 2 years ago

You'll enjoy set theory then. Just call the first set aleph-null.

markusw22• 2 years ago

Thanks! I guess I have moments of insight sometimes. :D

ultrablack• 2 years ago

You could have written the same article about C#.

markusw22• 2 years ago

Yes, I definitely could have. But I don't know C#, so that would have been an awful blog post. :D

xnorswap• 2 years 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.

neonsunset14• 2 years 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#summa...

hk1337• 2 years 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_9• 2 years 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• 2 years 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• 2 years ago

all popular programming languages can do basically anything

That's just very not true...

nerdponx3• 2 years ago

Got an example?

randomdata26• 2 years 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.

jimbokun11• 2 years ago

It's true in terms of Turing Completeness.

zarzavat2• 2 years 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

mapcars12• 2 years 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.

jimbokun11• 2 years 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.

markusw22• 2 years 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• 2 years 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• 2 years 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.

markusw22• 2 years ago

I choose to read most comments in a positive light, but thank you for your kindness. :)

name_nick_sex_m• 2 years ago

You seem to be confusing defensiveness with sharing different perspectives

daghamm2• 2 years 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

kaba08• 2 years ago

How is it different than, say, java for this generalist purpose?

colonelpopcorn• 2 years 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.

Dansvidania• 2 years 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.

lantry• 2 years ago

IME, there are two main differences between go and java:

1) go is more "batteries included". Modules, linting, testing, and much more are all part of the standard cli. Also, the go stdlib has a ton of stuff; in java, there is almost always a well-built third party library, but that requires you to find and learn more things instead of just reaching for stdlib every time.

2) golang is "newer" and "more refined". this is pretty subjective, but golang seems to have fewer features and the features are more well-planned. It's a more "compact" or "ergonomic" language. Whereas java has built up a lot of different features and not all of them are great. You can always ignore the java features you don't like ofc, but this is still a bit of cognitive overhead and increased learning time.

aaomidi2• 2 years ago

Dependencies in Java are a pain in the ass.

Publishing libraries for your own consumption is even harder.

Publishing libraries for world consumption means now you also need to be a PKI expert.

conor-4• 2 years ago

As someone who isn't super proficient in Java I usually find Java daunting to get started with full of buckets of "meta" issues like in my other comment.

What JVM do I use? Does it matter?

Does it matter what version I install, what if I have to install/manage multiple versions?

If I want to write a web service can I use vanilla Java stdlib or do I have to use Spring or some framework? If I use Spring, do I have to get into the weeds of dependency injection and other complexity to actually get my app off the ground?

With Go, none of those questions exist. I install the latest Go, create a main.go file, I use net/http and I'm off to the races.

cube22222• 2 years ago

Yeah, this. It's just good enough for 95% of use-cases, while being very productive.

Personally, one of the biggest selling points for me is that imo modelling concurrency and asynchronicity via fibers (goroutines), rather than async/await, is just a ton easier and faster to work with. Again, there are use-cases for the alternative (mainly performance, or if you like to express everything in your type-system) but it's just great for 95% of use-cases.

sanderjd16• 2 years ago

I always find it odd when people refer to it as being "very productive". I find all the boilerplate very un-productive to work with. Every time I pick go back up I'm shocked how many manual loops and conditionals I have to write.

conor-4• 2 years ago

Go is the only language I've ever felt highly productive working in. Oftentimes in other stacks I find myself in analysis paralysis on meta things that don't matter:

- what design patterns/language features make sense to use

- what is the best lib to accomplish X

- how do you keep things up to date

With Go, the language is so simple that it's pretty difficult to over engineer or write terse code. Everything you need is in stdlib. The tooling makes dependency management and upgrades trivial because of strong backwards compatibility.

justinsaccount• 2 years ago

Yep.. say you wanted to make a simple http service that needs to

* request a json.gz file from another HTTP service * decompress it * deserialize the json, transform it a bit

That's net/http (and maybe crypto/tls), compress/gzip, encoding/json. I need to make zero decisions to get the thing off the ground. Are they the best libraries in the world for those things? no.. but will they work just fine for almost every use case.

mapcars12• 2 years ago

I do programming interviews and I found candidates struggling a lot in doing http request and parsing response json in Go while in Python its a breeze, what makes it particularly hard, is it lack of generics or dict data type?

randomdata26• 2 years ago

it's pretty difficult to over engineer

I don't know about that. Every programmer's first Go program seems to like to go to channel city. Perhaps more accurately: Over-engineering your Go program is going to quickly lead to pain. It doesn't have the escape hatches that help you paper over bad design decisions like some other languages do.

pjmlp13• 2 years ago

Sure, if everything one does is either CLI stuff, or UNIX daemons, containers, ....

Because in the reign of graphics , GUI, GPGPU, HPC, HFT, ML, game engines,numeric analysis, ... there is hardly any library that really stands out.

cookiengineer• 2 years ago

I feel the same.

Especially in the UI/UX world when you want to just start building a demo you're paralized by dozens of build toolchains in between.

Wanna get started with a starter template? Tough luck, it hasn't been updated for a year, so it takes even longer.

In go, everything is opinionater and unified upstream. Conventions matter, because they allow efficiency and reuse of patterns and architectures.

cdelsolar3• 2 years ago

Go has ruined all other languages for me. I really fell in love with Gleam recently and was trying to implement a fun side project in it. The problem is I really don’t have enough time to learn the intricacies of it, with a startup, two kids, etc. As soon as I have to look at some syntax and really _think_ about what it’s doing every time I look at it, I lose interest. I kept trying and eventually implemented it in Go much faster. And while doing it in Go I kept wishing I could just use actors and whatever to make it simpler but, is it really simpler?

jayd167• 2 years ago

I'm asking this earnestly but is Go suitable for native GUI apps (not web)? 3D graphics/Games? Audio processing?

nasretdinov3• 2 years ago

For games potentially Ebiten, I believe it has some audio processing support too.

xyproto• 2 years ago

Yes, because one can either turn off the GC, allocate memory up front (arena style), or call C or Assembly from Go.

The performance is likely to be good enough with GC turned on, though, because it is unusually fast.

0cf8612b2e1e2• 2 years ago

People write games and GUI apps in Python, so why not?

ssebs• 2 years ago

I've written a GUI in Fyne, it's decent but go is not a first class GUI language. Fyne is... fine but building code is annoying.

See https://GitHub.com/ssebs/go-mmp

api• 2 years ago

Go has very little story when it comes to desktop or mobile GUI apps, which is too bad because it would be a very productive language for that kind of thing.

anta402• 2 years ago

This makes me wonder: why there's less effort on mobile side? For web, well there are plenty of stuffs.

Perhaps Go devs are not interested in native solution (like Kotlin/Swift etc) and prefer web stack (JS, React etc)?

actionfromafar• 2 years ago

My personal Python threshold is 10k lines. After that I tend to loose track of what I am doing and I start to miss static typing and nowadays, an IDE to navigate it. Maybe future Python IDEs can AI scan the codebase and compensate.

JodieBenitez• 2 years ago

Wait... in what year was this comment written ? ;)

There's type hinting and IDEs do navigate it.

sanderjd16• 2 years ago

Type annotations plus modern IDEs have (in my experience) made this mostly a non-issue. It does require a bit more setup to get passable static analysis set up, which comes "for free" in languages with good compilers (like go!), but it's at least possible now to get to a (IMO) good point.

(FWIW, I moved away from python and ruby over a decade ago because of exactly this frustration, but I'm finding modern python to be pretty pleasant.)

danpalmer2• 2 years ago

When people argue about the validity of these claims, I simply point them to this talk https://go.dev/talks/2012/concurrency.slide#42

There's nothing impressive in these slides. This may have been pretty good in 2012, but this code looks very much like the equivalent Swift or Rust.

sapiogram4• 2 years ago

It's better in Swift or Rust. Go channels are the worst thing about the language, even trivial use cases are difficult to get right.

eweise4• 2 years ago

Personally I don't find it great for prototyping. There's just too much boilerplate, which is why I use other languages for fun/personal projects.

pants2• 2 years ago

Is there much boilerplate aside from err checks and JSON tags? Even then, your IDE / copilot should automatically insert those along with imports and package names.

sanderjd16• 2 years ago

Absolutely, it's my least favorite prototyping environment. It forces me to think about a bunch of stuff I don't want to think about up front.

drdaeman• 2 years ago

I can totally agree that Go is good enough for most projects, to the extent it's a go-to choice for many. However, it's not always the best tool - frequently it wins just because it allows to prototype quicker. YMMV, but for me, it's not a love relationship, it's a love-hate relationship.

The language is extremely simple.

Simplicity is a double-edged sword. It didn't even have basic generics for a long while, and it's painful to remember how bad it was without them. Still doesn't have a lot of stuff anyone would expect from a modern language.

If you know 20% of C you are already a Go expert.

Strong disagree. Knowing $language means knowing the patterns and caveats and (sorry for a cliche term, I'm not fond of it, but I don't have a better term so I hope you get the meaning) "best practices". Those are drastically different between C and Go. Especially when it comes to concurrency and parallelism.

The toolchain and the core libraries alone can do 90% of what most people will ever need.

This is provably false. Virtually every serious project out there pulls a ton of dependencies, like database drivers, configuration toolkits, tracing and logging libraries and so on. Heck, I think a lot of shops have project templates for this reason - to standardize on the layout and pull the company-preferred set of libraries for common stuff. Core libraries are slowly getting there but so far they don't have very basic stuff like MapSet[T] or JSON codecs for nullable types like sql.NullString, so you gotta pull third-party stuff.

AnimalMuppet2• 2 years ago

"Good enough" plus "I already know it" almost always beats the perfect tool that I don't already know.

ternaryoperator• 2 years ago

Agreed on all points except #3 re the core libraries. Coming from the Java ecosystem, it was a bit of a shock to see how small the standard libraries are. For example, the minuscule collections library, among others.

Yoric4• 2 years 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'd nuance that claim.

I haven't found Go to be _particularly good_ at any specific task I've undertaken, but Go was _good enough_ for many of these tasks. Which makes Go a reasonable general programming language.

sanderjd16• 2 years ago

This is true, but there are a number of _good enough_ languages, and personally I don't think go is top-tier at this use case of being the go-to swiss army knife. I do think it is top-tier at being a good choice for tools in its niche. But not as "default language I reach for when I don't want to waste time thinking about it".

lenkite4• 2 years ago

Go is not good for data science and ML. It doesn't even have a proper, maintained dataframe library for data-science. R and Python beat it hands on. Rust also beats it now thanks to polars. And mobile ? gomobile is not maintained. Fyne is amateur level on mobile.

AFAIK Go has no maintained 3d game engines.

Go has its well-established niche for middle-ware services and CLI tools. And that's about it. If your domain is outside this, its best to choose another language.

merlindru• 2 years ago

Also anything that requires interop/FFI, syscalls, and lower level stuff. It's extremely hard to record your screen on Go, for example. On Rust this is much more doable and there even are crates for it

It's not impossible with Go, though. There's an amazing windows impl here: https://github.com/kirides/go-d3d

...but if you look at the code, it's clear that you have to work against the language in some capacity

Lyngbakr2• 2 years ago

Is the reason for the absence of a well-maintained dataframe library lack of demand? It looks like Gota and Dataframe-go are abandoned, while Gonum isn't particularly active. Did these wither on the vine because no one used them?

createaccount99• 2 years ago

Builtins well thought out? Have you seen the bignumber api?

sanderjd16• 2 years ago

It has not been my experience that Go is good for almost everything. On the contrary, it seems good at a couple very specific (though very common) niches: network services and cli utilities. But for most of what I do right now - data heavy work - it has not turned out to be very good (IMO). It really is just not better in any way to have to constantly write manual loops to do anything.

lnenad2• 2 years ago

I agree with this, there is a reason Python is the king of data.

ratorx3• 2 years ago

I think Go is pretty OK as a language for building data pipelines (I’m assuming you meant statistical ones, but the same argument applies to more data transform-y ones). What it is not good for is doing exploratory analysis (which is where Python shines).

Manual loops are pretty annoying when the focus is on figuring out which loops to write (exploratory phase). However, they are pretty nice once you’ve figured it out and need write a durable bit of code where your prioritise readability over conciseness (productionisation).

Going from Python to <any language> between the exploratory phase and the productionised pipeline is going to be a pain, I don’t think Go is particularly worse than others. At that point it’s all about the classic software tradeoffs (performance vs velocity vs maintainability) and I didn’t think Go is a good choice in many situations.

mjw_byrne• 2 years ago

4. Stability and backwards-compatibility. I have never seen a Go version upgrade break anything. Meanwhile I have colleagues who do a thousand-yard-stare if you so much as mention upgrading the version of Python we're using.

sanderjd16• 2 years ago

Python upgrades are fine, actually. The python library ecosystem is a bit of a mess in general, which does affect this, but the tools have actually improved to make this more manageable lately.

riku_iki• 2 years ago

Go is good for almost everything.

Java is good in more areas than go

noisy_boy3• 2 years ago

Once your project exceeds 100 lines

100 lines in which language? 100 lines in Go will probably have 50 lines of if err != nil :P

acyou• 2 years 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_9• 2 years 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.

omeid25• 2 years 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.

markusw22• 2 years 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

omeid25• 2 years 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.

steve_adams_86• 2 years ago

If someone can't tie their shoes with a chainsaw, they just haven't dedicated appropriate time to their tools :)

Side note, this reminds me of a local YouTuber who mostly films himself using a chainsaw and has a remarkably large following (516k followers right now!). He also loves axes. I present to you Buckin' Billy Ray: https://www.youtube.com/@BuckinBillyRaySmith

I'm pretty sure this guy ties his shoes with a chain saw

fifilura4• 2 years 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_9• 2 years 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.

zarzavat2• 2 years 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.

neonsunset14• 2 years ago

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.

So are iterators in Rust which allow you to write idiomatic iterator experessions. Hell, even LINQ in C# has improved dramatically and now makes sense in general purpose code where you would have erred on the side of caution previously. You can pry ‘var arr = nums.Select(int.Parse).ToArray();’ from my cold dead hands.

At the end of the day, it is about having capable compiler that can deal with the kind of complexity compiling iterator expressions optimally brings.

erik_seaberg3• 2 years ago

Mechanical sympathy now favors SIMD instructions and hyperthreads because sequential loops are slower even unrolled.

jimbokun11• 2 years ago

With generics you can now write all of those in Go.

ivanjermakov• 2 years ago

And it would be an order of magnitude slower than plain loop because compiler is not smart enough to optimize it.

curious_cat_163• 2 years 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• 2 years 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

markusw22• 2 years 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. ;) )

ljm3• 2 years 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.

metaltyphoon2• 2 years 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• 2 years 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• 2 years 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• 2 years 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.

theshrike7912• 2 years 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.

bborud13• 2 years 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.

cube22222• 2 years 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• 2 years 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.

Klonoar• 2 years ago

It’s not just the time to understand those nuances, but to keep up with the pace of changes. There’s an aspect of navigating those in some languages (JS…) that can be time consuming depending on where it’s deployed.

tengbretson2• 2 years ago

Not only is it the nuances and pace of changes, but theres also a temporal element of seeing cause and effect over time from within an ecosystem. Is there a way to just parachute in and learn how to judiciously use classes in JavaScript the way one would if they were out there assigning Thing.prototype.method = function () {}? Can Udemy give you the same a-ha moment learning Promises today that someone got when they were drowning in callback pyramids in their Express v3 app?

bborud13• 2 years ago

I think JS is a degenerate case. The reason I stay as far away from JS/TS as possible is that everything seems sloppy and therefore people try to "fix" things by replacing them every N months.

Indeed, when you see so many commenters advocating not bothering to learn a language deeply, you kind of get a taste for how prevalent the sloppiness mindset is. JS seems to attract a very high proportion of unskilled programmers.

I would struggle to name a single project I have been involved in where the JS/TS based front-end hasn't been reimplemented multiple times, from what I can tell, because people get lost.

pjmlp13• 2 years ago

Naturally one can't know all the languages of the world.

Even so, I have done consulting since 1999, with a small 2 years pause in research, and have several languages that I keep switching, every couple of months when project reassignment takes place.

The usual T-shape kind of consultant, know some stuff really well, and others good enough to deliver.

BiteCode_dev4• 2 years ago

And then you have the ever changing ecosystem, that can take years so sort out on it's own and must be constantly studied.

E.G: if you arrive in Python right now, numpy is in version 2 and polars is stable. uv is all the rage, pydantic gained so much perf it's not even funny, toml is part of the stdlib and textual is looking very good. Type hints are much better than 2 years ago, htmx is used a lot in the web department, fasthtml is having a moment in the light and pyscript got a platform. Is any of those information worth acting on? Should you ignore them all for the sake of productivity? Should you carefully evaluate each proposition?

Now if you have to do that with rust and erlang as well, it's a lot of time you could spend on coding instead.

otteromkram• 2 years ago

IMHO, that's not part of learning the language. You don't really even need half of the packages you mentioned unless you don't know the language and, instead, rely upon third-party crutches.

jaapz• 2 years ago

Instead of constantly trying to keep up with everything in an ecosystem (which is simply impossible), just keep up with the stuff you are using to get your product working. Keep a side eye on the rest of the ecosystem to see if something neat is developing that you might use, but no need to study every hyped package coming out. In the end they are all tools to get something that works.

We still use flask and it's been great all the way, and it still holds up really well, there's no reason to move to any of the other packages just because that's the next new shiny thing.

aragilar8• 2 years ago

I would think the best option is to always be suspicious of hype, unless you understand why something is being hyped? I'd also argue its worth understanding where your stack falls down, so you know when you need to look for alternative stacks.

The other bit is it's worth understanding how your stack interacts with related stacks (to use your examples, does uv and pydantic using rust vs. being pure python cause issues), but your OS is also changing, are your tools still going to work?

Daishiman5• 2 years ago

Python has _remarkably little_ ecosystem churn compared to a lot of languages. New packages come and go all the time but the older packages are very well maintained and nobody's forcing you to switch to the new ones.

nemo1618• 2 years ago

One of the most important qualities of Go is that it is actually possible to fully understand the language -- in the sense that you never see a snippet of Go code and think "wtf, you can do that?" or "hang on, why does that work?"

Getting to that point takes many years, to be sure. But the language is simple enough, and changes slowly enough, that it is not an unrealistic goal -- the way it would be in C++, or Rust, or just about any other mainstream language.

tialaramex3• 2 years ago

in the sense that you never see a snippet of Go code and think "wtf, you can do that?" or "hang on, why does that work?"

I am extremely doubtful that this is true and would like evidence.

EE84M3i2• 2 years ago

Personally my biggest issue with reading go code has come from the //go: magic comments that I never seem to fully understand.

For example, what the heck is a //go:cgo_import_dynamic? As far as I can tell this is only documented on GitHub issues and mailing list comments.

mingusrude• 2 years ago

This is similar to the experience that I had with Erlang. After having spent time with it, I was hardly every surprised looking at any code and my brain could deal with the actual problems at hand without having to figure out how to apply what I knew about the language.

Dylan168079• 2 years ago

Why is that important?

Let's say one language has me find a weird rabbit hole every 50 hours of use, and I spend half an hour learning about it.

Let's say another language has no rabbit holes, but I'm 5% slower at coding in it.

Why would I not prefer the first language?

(And 5% is supposed to be an intentional lowball. I'm confident I can find language pairs where my productivity differs by significantly more.)

bborud13• 2 years ago

I've been doing Go for a long time now and I still occasionally come across snippets of code that I don't understand or understand the purpose of. So I think "never" is too strong a word. I'd say "rarely" rather than "never".

georgeecollins2• 2 years ago

I also think it is a good idea to learn a few very different languages when you are starting out so that you have a sense of the tradeoffs and the different ways things can be done. When I was in college they taught C and Lisp (I am dating myself) which seemed very different to me at the time but also useful in different ways. Close to the hardware, vs supporting objects, lambda functions, etc. Later I learned a number of other languages and now I try hard to avoid switching languages because of the lost productivity.

Now if I were starting out I think I would try to focus on two different languages, but more modern ones. Maybe Rust and Python?

brightball• 2 years ago

This is actually how I feel about Ruby. Not full on Rails because there is a lot more to learn there which comes with the time investment (which is also worth it in many cases).

But for most scripting work especially, just raw Ruby and maybe the Sequel library for a database just makes my productivity soar.

jalopy• 2 years ago

Do you have any open source examples (either your own or others) of simple Ruby + Sequel that are particularly elegant + productive that you could point to? Would love to see this.

I agree Ruby is the most elegant and enjoyable language to develop in.

saghm• 2 years ago

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 think these criteria in particular are much more than a lot of people mean when they say "learn a language", which would explain why their estimates are lower than yours. You're talking about expertise, whereas plenty of people are speaking of basic competency. This seems more like (natural) language semantics about what it means to "know" and the definition of "properly learn" than about the accuracy of people's estimates.

bb8810• 2 years ago

2012: Python is Awesome!

2014: Python is a great language, but there are a few pitfalls

2016: Python is a good language with the right IDE, tooling, and process. The people are pretty cool though.

2018: I like python, but I wish more people used type annotations.

2020: You know, metaclasses are freaking awesome! They saved me so much work!

2022: Why can't people code the most obvious solution in python?

2024: Celery! Jesus H. Christ! What were you thinking?!

ramijames• 2 years ago

I don't think it is that long. Think of learning any spoken language. We expect that it takes AT LEAST ten years to be able to master it, and typically it takes much longer to meaningfully add to the compendium of literature. Usually we are talking about decades. It isn't just about the tool (speaking, writing) but being so fluent that you can successfully express yourself in a way that has impact.

If you can do it in ten years with a software stack, I'd say that's pretty impressive.

irjustin• 2 years ago

ChatGPT accelerates this timeline significantly. As a senior programmer you can largely skip the "junior" phase of the learning, almost like pair programming with a very proficient junior programmer.

pjmlp13• 2 years ago

I am fully convinced that programming language generation out of stuff like ChatGPT is an intermediate step on their evolution, just like early compiler adopters wouldn't trust compilers that wouldn't show the Assembly output.

Eventually we will achieve another milestone in what it means to program computers, where tools like ChatGPT will directly produce executables, or perform actions, and only when asked it will produce something akin to source code for cross-checking.

bborud13• 2 years ago

I disagree. ChatGPT is like pair programming with someone who is on drugs and tends to lie a lot. Co-Pilot is even worse as it constantly bombards you with poor suggestions and interrupts your flow when you should be left alone to think about the problem you are solving.

What separates a senior developer from a junior is that the language is no longer a barrier so your spend most of your time thinking about the problem you are solving and how you balance requirements, take into account human elements, and try to think ahead without prematurely spending time on things you aren't going to need.

Being shown a bunch of possible solutions to choose from doesn't help you develop the ability to think about problems and come up with better solutions.

Yes, ChatGPT can occasionally help you when you need a nudge to pick a direction or you come across something you don't know anything about. But it is not a substitute for knowing stuff and it can't actually teach you how to think.

p0w3n3d• 2 years ago

I totally agree with you. Only after min 2 years of fully coding a viable production solution can one learn most of the pitfalls of given language. I would add frameworks which give another level of complexity and sometimes a framework is like a separate language.

lifthrasiir3• 2 years ago

It takes forever to "properly learn" a language in my opinion, because it would mean the total emersion into the ecosystem and most prominent libraries built around that language as well, and they will be always moving targets even though the language itself might be static. Go is no exception, and in fact there are only a handful of languages that can be ever "properly learned" if we are strict about that. The trick is not to properly learn, but to know how to learn enough of anything you need and make the best use out of that.

Etheryte• 2 years ago

Agreed, there's such a wide knowledge gap between "I read about this language design choice online" and "I know this from first principles". Truly, thoroughly understanding the languages and tools you work with every day unlocks a deeper level of understanding that you can't substitute with anything else. It's what people often describe when they first learn Lisp, but the same actually holds for every language, tool, etc. There is tremendous value in depth. However, since there is considerable opportunity cost in choosing what you put your time and effort into, do be mindful of the tools you decide to acquire this amount of knowledge in.

_xiaz6• 2 years ago

I believe people over-estimate the benefit of properly learning a language.

3-12 months seems to be sufficient for the specialisation benefits to outweigh the small hit to language competency.

My strategy is to be a generalist superficially learning specialized languages.

tmountain2• 2 years ago

Whatever time frames you apply, the only way to really learn a language is to use it. Reading a book, blog articles, and watching videos on YouTube won't give you the hands on experience necessary to internalize how everything works.

bborud13• 2 years ago

The way to become good at something is to do it for a long time and to be willing to think about what you are doing and continually improve.

There's much more to learning a language properly than just learning the language spec itself. Especially if we're talking about languages such as Java, where you have to know quite a bit about how the runtime works in order to be able to make good design decisions. And Go isn't really that simple either when we start to get into the weeds of performant concurrent systems that also need to be robust. It requires quite a bit of work to be able to make full use of what Go offers. It may look simple, but concurrency never is.

You're essentially arguing in favor of not being good at what you do, or at best being mediocre at lots of things. And I'm sure there are lots of jobs where that is okay. The thing is: why would you want to spend a lifetime being mediocre, to work on mediocre projects with other people who are mediocre?

simiones8• 2 years ago

I completely disagree. I have been successful in building a new project for my company with myself and the entire team being completely new to Go when we started. Did we have growing pains, and some sub-par decisions? Absolutely. Do we right better Go code today, 4 years later? Absolutely. Did this mean that the project was in any way significantly slowed down by our use of Go compared to the C# or Java we knew before after the first 1-2 months? No, not really. The ways in which Go fit better for our chosen domain completely made up for that (and this all despite my continued belief that Go as a language is inferior to Java and C#).

Now, there are other languages where I'm sure that we would have had significant issues if we tried to adopt them. In particular, switching from the GC languages we were used to to a native memory language like C++ or Rust or C would have surely been a much bigger problem. The same would have probably been true if we had switched to a dynamic language.

But generally, deep language proficiency has less value in my experience than general programming proficiency, and much less than relevant domain knowledge. I would hire a complete Go novice that had programmed in Python in our specific domain over someone who has worked in Go for a decade but has only passing domain knowledge any day.

m_a_g• 2 years ago

Here is the thing: many software engineers don't need to learn a language "properly."

When you start a new job, there will almost always be an existing code base, and you'll have to make contributions to it. Pattern recognition will get you a long way before you need to dive deep into the language internals.

rkangel• 2 years ago

This is true, and it makes the people who do actually know the language in depth extra valuable.

bborud13• 2 years ago

You are mixing two things. Learning a language and learning a codebase. Those are not the same thing. Besides, you are also just talking about what happens during the first N months. Most companies I've worked for allow for time to learn the language(s) being used. Some of them will fire you if you can't show sufficient progress over time.

vouaobrasil• 2 years ago

That's true. I agree. Python is the only language I ever really learned to a deep level and properly, and it makes a huge difference! (And I'm still learning of course.)

machiaweliczny• 2 years ago

Using esoteric lang constructs is bad idea IMO. Makes software harder to read/port/maintain. It’s useful for some hack & high perf stuff but not typical apps.

bborud13• 2 years ago

Agreed. But knowing a bit about how a language (and runtime) actually works can make a huge difference when you design stuff.

For instance, I've seen lots of examples of people implementing LRU caches in Java, and then scratching their heads when performance drops because they have no idea how the GC works. Or complicating things immensely because they realize memory is tricky and then ending up with some complex pooling scheme that constantly breaks rather than realizing that often more naive code that exploits the low cost of ultra short-lived local objects.

If you know what you are doing it becomes easier to choose solutions that are performant and understandable.

jamwt• 2 years ago

IME, engineers and "the discourse" when we argue on the Internet often conflate "ease of use" and "ease of learning". When we say "ease of use", we usually mean "ease of learning."

If you're a hobbyist, yeah, you should heavily value "ease of learning." If you're a professional, the learning curve is worth it if the tool's every day leverage is very high once you're ramped up. Too many developers don't put those 3-4 months in, in part due to the over-emphasis on "ease of learning" in our discussions/evaluations of things.

I was a part of a very large go project (https://news.ycombinator.com/item?id=11282948) and go-based company infra generally some years ago, and go is emblematic of the classic tool that is amazing at ease of learning, and quite mediocre at "ease of use" as time goes on.

I personally end up resenting those tools because I feel tricked or condescended to. (This is a little silly, but emotions are silly.)

I'd wager this is also why Rust is a perennial "most loved" winner in the surveys: it gets better as your relationship with it deepens, and it keeps its promises. Developers highly value integrity over trickery, and hard-earned but deep value feels like integrity and wins in the long run. (other examples: VIM, *nix, git)

igtztorrero• 2 years 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• 2 years 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

lairv2• 2 years 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• 2 years 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• 2 years 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.

stuff4ben3• 2 years 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_gipsy3• 2 years ago

Do you write Go for fun as hobby, or do you agree with the OP?

matwood3• 2 years ago

I'd rather poke my eyes out with a nail than use Python.

Glad I'm not the only one. Every time I'm forced to use Python I cringe. What version disaster and I'm going to run into today? The 2->3 transition happened a long time ago at this point and I still run into lingering effects. Also, for short 'script' like things Python doesn't feel any quicker or easier to write. Go is my Goto (hehe) for short scripts.

And while I'm ranting, I'll also say that modern/latest version Java is also really nice.

maccard6• 2 years ago

I would rather go had real enums, and I would _prefer_ if there were sum types.

I agree it's more verbose, but I don't find that that verbosity really bothers me most of the time. Is

    res= [x for x in foo if "banned" in x]

really actually more readable than

    var result []string
    for _, x := range foo {
        if strings.Contains(x, "banned") {
            result = append(result, x)
        }
    }

? I know it's 6 lines vs 1, but in practice I look at that and it's just as readable.

I think go's attitude here (for the most part) of "there's likely only one dumb, obvious way to do this" is a benefit, and it makes me think more about the higher level rather than what's the most go-esque way to do this.

aaomidi2• 2 years ago

The new lines were eaten so it does make the python version more readable but I agree with you.

randomdata26• 2 years ago

Go has real enums. All an enum does is count.

You're probably thinking of value constraints? Or, perhaps, exhaustive case analysis? Go certainly lacks those future.

And, indeed, they sound like nice features, but, to be fair, not well supported in any popular programming language. At best we get some half-assery. Which always questions if the popular languages are popular because of their lacking type systems?

thornewolf• 2 years ago

I argue:

- The list comprehension is ever slightly more readable. (Small Positive)

- It is a bit faster to write the code for the Python variant. (Small Positive)

So this would be a small positive when using Python.

Furthermore, I believe there is this "small positive" trade-off on nearly every aspect of Python, when compared to Go. It makes me wonder why someone might prefer Go to Python in almost any context.

Some common critiques of Python might be:

- Performance in number crunching

- Performance in concurrency

- Development issues in managing a large code base

I believe the ecosystem is sufficiently developed that Numpy/Numba JIT can address nearly all number crunching performance, Uvicorn w/ workers addresses concurrency in a web serving context, ThreadPool/ProcessPool addresses concurrency elsewhere, and type hints are 90% of what you need for type safety. So where does the perceived legitimacy of these critiques come from? I don't know.

halfcat• 2 years ago

”Is <python code> really actually more readable than <go code>?”

I mean, I mostly work in Python, but, yes absolutely.

There’s something to be said for locality of behavior. If I can see 6x as many lines at once that’s worth a lot in my experience.

This becomes blatantly apparent in other languages where we need 10 files open just to understand the code path of some inheritance hierarchy. And it’s not nearly that extreme in go, but the principle is the same.

But there is something to be said for the one way to do it, and not overthinking it.

skitter• 2 years ago

I agree that list comprehensions aren't any easier to read. A proper streaming interface on the other hand lets you easily follow how the data is transformed:

    foo
      .stream()
      .filter(x -> x.contains("banned"))
      .collect(Collectors.toList());

As an aside, Go conflating lists and views irks me, in part due to what weird semantics it gives to append (e.g. if you have two disjunct slices and append an element to one slice, that might modify the other slice).

jodrellblank2• 2 years ago

Filtering a container by a predicate is 50 year old technology and a very common thing. It's unbelievable that a "modern" language has no shorter or clearer idiom than that convoluted boilerplate filled Ministry of Silly Walks blob. Python had filter() and then got list comprehensions from Haskell list comprehensions. PowerShell has Where-Object taking from C# LINQ .Where() which takes from SQL's WHERE. Prolog has include/3 which goes back to sublist(Test, Longer, Shorter) and LISP-Machine LISP had sublist in the 1970s[1]. APL has single character / compressing an array from a bitmask result of a Boolean test in the original APL/360 in 1968 and it was described in the book in 1962[2].

Brian Kernighan gave a talk on the readability of code and not getting too clever[3] "Elements of Programming Style" where he talks about languages having one way to write one thing so that you can spot mistakes easily. I am aware he's one of the Go designers and I will mention that again in a moment. In Python the non-list-comprehension version might be:

    result = []
    for x in foo:
        if "banned" in x:
            result.append(x)

Which is still clearer than the Go, simply by having less going on. I usually argue that "readable" merely means "familiar" and Python is familiar to me and Go isn't. Your Go code makes me wonder:

- "var" in C# does type inference. You declare []string but don't declare types for _ x or the tuple _,x what's up with the partial type inference? What is "var" adding to the code over classic "int x" style variable declarations?

- What is "range" doing? From _ I guess it does enumeration and that's a throwaway for the index (if so it has an unclear name). If you have to enumerate and throw away the index into _ because there isn't another way to iterate then why does keyword "range" need to exist? Conversely if there are other ways to iterate and the keyword "range" is optional, why do it this way with a variable taking up visual space only to be thrown away? (The code equivalent of saying "for some reason" and drawing the audience's attention to ... nothing). And why is range a keyword instead of a function call, e.g. Python's "for (idx, elem) in enumerate(foo):" ?

- Why is there assignment using both := and = ?

- Why string.Contains() with a module name and capital letter but append() with no module and all lowercase? Is there an unwritten import for "strings"?

- The order of arguments to Contains() and append(); Prof. Kernighan calls this out at 10m10s in that talk. C# has named arguments[3] or the object.Method() style haystack.Contains(needle) is clear, but the Go code has neither. It would be Bad Prolog(tm) to make a predicate Contains(String1, StringA) because it's not clear which way round it works, but "string_a in string_1" is clear in Python because it reads like English. AFAIK a compiler/type system can't help here as both arguments are strings, so it's more important that the style helps a reader notice if the arguments are accidentally the wrong way around, and this doesn't. We could ask the same about the _, x as well.

- "result =" looks like it's overwriting the variable each time through the loop (which would be a common beginner mistake in other languages). If append is not modifying in place and instead returning a new array, is that a terrible performance hit like it is in C#? Python list comprehensions are explicitly making a completely new list, but if the Go code said "result2 = append(result, x)" is it valid to keep variable "result" from before the append, or invalid, or a subtle bug? The reader has to think of it, and know the answer, the Python code avoids that completely.

- And of course the forever curly brace / indent question - are the closing } really ending the indented block that they look like they are ending judging from the dedent? I hear Go has mandatory formatting which might make that a non-issue, but this specific Python line has no block indentation at all so it's less than a non-issue.

- The Python has five symbols =[""] to mentally parse, pair and deal with, compared to twenty []_,:={.(,""){=(,)}} in the Go.

Step back from those details to ask "what is the code trying to achieve, and is this code achieving the goal?" in the Go the core test ".Contains()" is hiding in the middle of the six lines. I'm not going to say you need to be able to read a language without learning it, but in the long-form Python what is there even to wonder about? B. Kernighan calls that out about 12:50 in the talk "you get the sense the person who is writing the code doesn't really understand the language properly". You say code is meant to be read more than written, and I claim it's more likely that a reader won't understand details, than will. Which means code with fewer details and which "just works" the way it looks like (Pythonic) is more readable. As BWK said in the talk "It's not that you can't understand [the Go], it's that you have to work at it, and you shouldn't have to work at it for a task this simple".

[1] https://old.reddit.com/r/ProgrammingLanguages/comments/14tvu...

[2] https://keiapl.org/archive/APL360_UsersMan_Aug1968.pdf 3.38 or PDF page 94, dating back to the original A Programming Language (APL) book in 1962, source https://aplwiki.com/wiki/Replicate#History

[3] https://www.youtube.com/watch?v=8SUkrR7ZfTA

[4] https://learn.microsoft.com/en-us/dotnet/csharp/programming-...

poorlyknit• 2 years ago

IMO the Python version provides more information about the final state of res than the Go version at a glance: It's a list, len(res) <= len(foo), every element is an element of foo and they appear in the same order.

The Go version may contain some typo or other that simply sets result to the empty list.

I'd argue that having idioms like list comprehension allows you to skim code faster, because you can skip over them (ah! we're simply shrinking foo a bit) instead of having to make sure that the loop doesn't do anything but append.

This even goes both ways: do-notation in Haskell can make code harder to skim because you have to consider what monad you're currently in as it reassigns the meaning of "<-" (I say this as a big Haskell fan).

At the same time I've seen too much Go code that does err != nil style checking and misses a break or return statement afterwards :(

kjksf2• 2 years ago

So you're ok with Python, which doesn't have sum types or null safety, 2 out of 3 things you say are missing in Go.

In fact, Python didn't have any compile-type type until recently and compared to Go is slow and bloated.

So maybe the issue is not Go's lacking some features but something entirely different.

lairv2• 2 years ago

class A: def __init__(): pass def f(self): pass

def g(a: A | None): a.f()

(edit: I don't know how to format code on HN)

If I activate type-checking in VS Code this will highlight an error, although the python interpreter will indeed try to run it without compile time error

As I said, for my side projects this is enough for me to model my problems properly without having to resort to multiple hacks

And I took Python as an example, I also enjoy using Ocaml and Rust

mapcars12• 2 years ago

Mypy supports those for like 3-4 years already

xigoi2• 2 years ago

Python is dynamically typed, so everything is a sum type.

RandomThoughts36• 2 years ago

That's why I love Go so much.

You want to write a very clever library using elegant abstraction and generics to have a cool innovative interface to solve your problem? Tough luck, you can't. So instead, you will just have to write a bog standard implementation with for-loops and good old functions which you will have to copy and tweak as needed where you really need something more complicated. It will work perfectly fine and end up being very readable for you and for the other persons reading your code.

Go is basically anti-Haskell. It forces you to be less clever and that's great.

GaryNumanVevo3• 2 years ago

Take a look at a JSON parser or ORM written in Go. It's god awful the things they have to do to work around Go's type system. The average developer won't see these things, they're typically just writing glue code between Go's great stdlib (which also contains wild things if you take a look) and other 3rd party dependencies.

therealdrag0• 2 years ago

For loops? Dang that’s some clever syntax you have there. Personally I prefer a big standard while loop. /s

Aeolun2• 2 years ago

It will work perfectly fine and end up being very readable for you and for the other persons reading your code.

And make all future work both 3 times simpler, and take 3 times as long. I suppose there’s situations in which this is great, but I’m partial to requiring more.

I’ll admit that hasn’t worked out very well for me unless I’m working my myself though.

kerkeslager8• 2 years ago

"Simple" is a cop-out word. Things can be simple along a lot of vectors. The vector you've chosen seems to be "does less for you" which taken ad absurdum would have you using assembly. Go does have elegant abstractions, and they aren't the simplest along this vector, nor would anyone want them to be. Coroutines, for example, are actually quite conceptually complicated in some ways.

I prefer "understandable"--it appears this is what you're trying to get when you say "simple", but I think you're drastically overselling the understandability of go code. Sure, you understand any given line easily (what you described as "readable"), but you're not usually trying to understand one line of code. Since go's sparse feature set provides few effective tools for chunking[1] your mental model of the program, complex functionality ends up being in too large of chunks to be understood easily. This problem gets worse as programs grow in size.

Another poster mentioned that they start running into problems and wishing they had explicit types with Python programs over 10K LOC, which approximately matches my experience. But comparing to go, you've got to realize that 10K LOC of Python does a whole lot more than 10K LOC of Go; you'd have to write a lot more Go to achieve the same functionality because of all the boilerplate. That's not necessarily a downside because that boilerplate is giving you benefits, and I don't think entering your code into the computer is the limiting factor in development speed. But it does mean that a fair comparison of equally-complex programs is going to be a lot more lines of Go than Python, i.e. a fair comparison of might be 10K LOC of Python vs 50K LOC of Go. I say "might be" because I don't know what the numbers would be exactly.

How many people have written or worked on projects in Go of that complexity? How many people have written or worked on programs of equivalent complexity in other languages to compare? I'm seeing people discuss how easy it is to start a project in Go, but nobody is talking about how easy it is to maintain 50K LOC of Go.

I've worked on projects of >200K LOC in Python, and the possibly-equivalent >500K LOC in C#. I think the C# was easier to work with, but that's largely because the 200K lines of Python made heavy use of monkey patching, and I've worked in smaller C# codebases that made heavy use of dependency injection to similar detriment. I'm honestly not sure which feels more maintainable to me, given a certain level of discipline to not use certain misfeatures.

I haven't written as much Go, and I wouldn't, because the features of C# which make it viable for projects of this complexity simply aren't present, and unlike Python, Go doesn't provide good alternatives. I suspect the reason we don't have many people talking about this is that not many projects have grown to this complexity, and when they do these problems will become apparent.

The real weak point is Go's type system--it's genuinely terrible, because the features that came standard in other modern statically-typed languages decades before Go was invented were bolted onto Go after the fact. Gophers initially claimed they didn't need generics for a few years. As a result you've got conflicting systems developed before `go generate` (using casts), after `go generate` but before generics (using go generate), and after generics (using generics). It's telling that you seemingly reject generics ("clever library using elegant abstraction and generics") even though go has them now.

Attacking Haskell is sort of a straw man--so far I haven't seen anyone in this thread propose Haskell as a go alternative. I think we agree Haskell is far too dogmatic about its abstractions when it's impractical to be used as a general-purpose language (because I don't think it's intended as a general-purpose language).

[1] https://en.wikipedia.org/wiki/Chunking_(psychology)

eweise4• 2 years ago

You can write abstractions in Go and it has generics. Its just that the abstraction aren't as good so you end up with harder to read code.

pjmlp13• 2 years ago

And yet they had to reach out to Haskell folks to fix their generics story.

tome6• 2 years ago

Go is basically anti-Haskell. It forces you to be less clever and that's great.

This is a bit of tangent, but I think it's worth pointing out the value in Haskell (at least as far as I see it) is not that it allows you to write "clever" code, but that it allows you to define precise interfaces. I suspect some people like Haskell because they can be "clever", and I suspect to be able to define precise interfaces you have to allow some degree of cleverness (because you need things like higher order functions and higher kinded types), but cleverness is not, in itself, the value of Haskell.

georgeecollins2• 2 years ago

I feel like autocomplete has reduced the problem of verbosity for all languages. And if I am writing something that is going to have to be supported a lot I want something that is very explicit and easy to read. For me that is the "verbose" languages.

cortesoft2• 2 years ago

This is exactly what I was going to say... ever since I started using Copilot, verbosity bothers me a lot less. It isn't painful when I don't have to type/copy/etc most of it.

robinsonrc• 2 years ago

I feel the opposite way about this, and find this kind of verbosity reduces the signal to noise of the intention behind the code

AtlasBarfed• 2 years ago

For personal stuff I use use groovy.

Has the jvm and jdk and all the associated jars /library ecosystem?

Has tons of really good stuff from python/Ruby

Typing is optional so you can get full speed, static typing, but you can go dynamic when you need it.

That said, it's basically a deadend language career wise.

_xiaz6• 2 years ago

I'm in the same boat. I believe it's a matter of taste mostly. We prefer expressiveness and power, other prefer simplicity of semantics and verbose code

cies• 2 years ago

lack of proper enums, lack of sum types, no null safety etc

I miss the same for work.

I wonder how long it will take for Go to be the new PHP. Zealotism is through the roof. I read here people say "lack of proper enums, lack of sum types, no null safety" is a good thing. I read here people say "you can do anything with Go". It's simply not true, and very uninformed.

I wish everyone a good experience with their lang of choice.

anonzzzies• 2 years 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.

cybrexalpha7• 2 years 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• 2 years ago

What do you mean by no consistency in formatting? go fmt is a solid formatter that does its job

cybrexalpha7• 2 years 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/con... - TIDB uses 2-block style https://github.com/pingcap/tidb/blob/master/pkg/ddl/placemen... - MinIO uses 2-block 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.

Mesopropithecus• 2 years ago

Funnily, 1.5 decades after Golang popularized formatters, in 2024 it is the only language that I work in that requires me to think about formatting. Mostly line length, but super annoying.

tuetuopay2• 2 years ago

After using rustfmt, I feel gofmt is not up to snuff. My main gripe with it is there are multiple formattings that are valid: there is not one true format. E.g. gofmt does not enforce line length which makes diverging styles possible, like for function declarations.

jerf4• 2 years ago

Not sure what you mean by "no generics on interfaces"? https://go.dev/play/p/jGINeUt1JTE

Also echoing not sure what you mean by "no consistency in formatting or imports". It is increasingly difficult to use Go without gofmt getting run, since I have to imagine fewer and fewer people nowadays are using an editor that has neither custom support for their language nor LSP integration, and integration with gopls automatically runs goimports on save.

cybrexalpha7• 2 years ago

Not sure what you mean by "no generics on interfaces"?

I didn't word this very well. You can have a generic interface, and functions on that interface can refer to generic types. But you can't have a generic method on an interface that uses a different generic type. For example you can't have:

``` type YieldThing[T any] interface { Yield() T DoOperation[U any](U) } ```

icholy4• 2 years ago

Not sure what you're comparing to, but Go modules are probably the best dependency management system in any language.

cybrexalpha7• 2 years ago

It does a lot well. For example it correctly pins dependencies by hash in go.sum. It's by no means the worst dependency management system I've ever used.

IMO the biggest miss with Go modules is conflating the identity of a dependency with how you get it. This means that renaming a repo not only breaks the module itself (as you self-import other modules in the same source tree using the full path), but all of your dependencies. I've seen repos be renamed from github.com/foo/proj to github.com/bar/proj as part of organisational reshuffles, and then there's a big warning somewhere that says "never make a github.com/foo/proj repo or it'll break GitHub's automatic forwarding for renamed repos, and you'll break every package that depends on us."

There are workarounds like using replace directives. But that makes an even worse situation where you can read a source file and assume a dependency is at github.com/foo/proj but actually it's elsewhere. But ultimately a real fix involves touching every single file that imports your dependency. If Go modules left the way of pulling a dependency in go.mod alone it wouldn't.

You should use a Go modules proxy to solve this, and a custom import path. But by the time most orgs realise they need this it's too late and adopting one would be a huge change. So you end up with a patchwork of import issues.

udev4096• 2 years ago

Exactly. What is he even comparing go modules with? npm and pip? The dependency disaster management which keeps breaking unless I create a new virtual environment for every project?

tuetuopay2• 2 years ago

Between conflating imports and URLs, the weird go.mod syntax, and the nonsense that are GOPROXY, GOPRIVATE and such, yes, it’s a mess.

Honestly, aside from left-pad stuff, even npm is much better. I personally find cargo to be the best one I’ve tried yet. Feature flags, declarative, easy overrides, easy private registry, easy mixing and matching of public/private repos through git, etc. And like go it properly handles multiple versions of the same dep being used, but the compiler will help you when it happens.

stuff4ben3• 2 years 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.

jillesvangurp3• 2 years 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.

markusw22• 2 years 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• 2 years 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?

jillesvangurp3• 2 years ago

The standard library plus the growing number of multi platform libraries covers a lot of stuff at this point. There are still some things that are a bit lacking but most of those things have people working on them.

vips7L3• 2 years ago

It barely has a standard library. You’ll be dependent on the standard library of whatever platform you are targeting. JVM -> Java, Web -> JS.

zeroc8• 2 years ago

But you also need the GUI part. Flutter seems to be the main competitor here. What's the current situation with Kotlin? Is there a decent Compose for Web yet?

jillesvangurp3• 2 years ago

With browser dom support and CSS, that would be doable. Compose web is in alpha currently; it renders to a canvas.

hintymad• 2 years 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.

markusw22• 2 years 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.

bitbasher3• 2 years 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)

jayd167• 2 years ago

What game engines use Go?

jayd167• 2 years ago

I should say what 3D game engines use Go?*

sedatk2• 2 years ago

I chose C# for the same reasons. It's probably easier to make C# unreadable than Go due to plethora of features, but it all comes down to how you discipline yourself about writing code.

mats852• 2 years ago

https://github.com/bflattened/bflat

christophilus• 2 years ago

My main beef with C# was the culture. I spent around 15 years building stuff in C# (since 1.0), and absolutely loved the language. But, man. The Microsoft shops were so full of Kool-Aid drinkers, and there was so much enterprisey crap that often came along with that. I miss C#, but I don't miss the culture.

liampulles2• 2 years ago

"it all comes down to how you discipline yourself about writing code."

I don't think controlling one's own code is a problem. I'm more worried about the opportunities the language gives for Bob (my junior coworker) to slowly introduce all sorts of unclear cutting-edge language nonsense. Go is pretty good for this in my opinion.

_xiaz6• 2 years ago

The whole issue of readability is overstated and can be reduced to familiarity with syntax and idioms

bb8810• 2 years ago

I appreciate the Rust approach where Rust <-> C and Rust <-> Python get along really well together. They really thought about interoperability with existing infrastructure.

Java wanted everyone to rewrite everything in Java because that was easier than to interface with the existing libraries on the OS.

textlapse• 2 years ago

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

zupa-hu• 2 years ago

had such a good laugh, I’m going to steal that :)

blt3• 2 years 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• 2 years ago

Is this something Go intentionally didn't add?

sbhitz• 2 years ago

https://go.dev/doc/faq#overloading

jagged-chisel• 2 years 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• 2 years 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.

hello_computer• 2 years ago

Something like Elixir's function composition operator (->) would go a long way toward smoothing that out, but they rejected that as well.

I think the best we can do at the moment is runtime expression evaluation with something like this:

https://github.com/expr-lang/expr

or this: https://github.com/Knetic/govaluate

dudeinjapan• 2 years ago

Elixir's function composition operator is |>

SatvikBeri2• 2 years ago

We switched from Python to Julia for numeric code. It's generally much faster (and easier to optimize), and has slightly better syntax for mathy code.

It's worth noting that Julia is very similar to go, despite superficial differences. They're both small languages with big libraries, use the same concurrency model, use a mark-and-sweep GC with an emphasis on making it easy for the programmer to reduce garbage/allocations, and both use structs + functions rather than classes.

blt3• 2 years ago

Julia looks like a great language, but has the "time to first plot" issue been fixed yet? I don't want a REPL-centric workflow.

dilyevsky• 2 years ago

Numerical programs seems like a great fit for DSLs, say Starlark[0] ;-) That's what many C++ libs basically achieve with their heavy use of overloading, tmp, etc

[0] https://github.com/google/starlark-go or alternatively https://github.com/facebook/starlark-rust

aragilar8• 2 years ago

But why would someone use a new DSL, vs an existing (general-purpose-ish) language that supports numerics (there are enough out there, e.g. R, Python, or the numerous paid ones like matlab, mathematica or IDL)? You have no ecosystem, plus now you're got to wrap 50+ years of numerical libraries...

bouncycastle• 2 years ago

in my case, I prefer to see that the code is calling functions, so that I'm aware that they take extra resources such as stack space and it's easy to quickly jump into the functions to find what they are doing. Code that uses op overloading is hard to navigate and sometimes causes intense debugging pain. Simplicity always beats fancy features imo.

stouset• 2 years ago

Functions, especially functions like numerical operations, tend to get trivially inlined and consume no stack space.

blt3• 2 years ago

Operator overloading can be bad when abused for non-numeric types. But for numeric types, it is indispensable.

It's not hard to remember that `__add__` is using extra resources when I'm working with big matrices in NumPy.

tgv5• 2 years ago

In the same line of reasoning, Go also doesn't support getters/setters. You can't write v.a = 1 and expect it to call v.SetA(1). And that's a good thing. Cosmetically, because it avoids that all thickheads add a trivial get/set for each and every member. Functionally, because it can make code appear to do something it doesn't do, and this also goes for other operator overloading.

I've worked on C# code where db.open was a test to check for a database connection, but assigning to it would open or close the database. It should simply not be possible to hide that behind an assignment symbol. It's like having db.Query(...) delete the data.

azangru• 2 years ago

Go is my hammer, and everything is a nail
Less context switching

For the very same reason, my hammer is javascript.

beepbooptheory• 2 years 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• 2 years 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• 2 years ago

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

w10-1• 2 years 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• 2 years 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• 2 years 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.

danpalmer2• 2 years 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.

iaabtpbtpnn• 2 years ago

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

whateveracct3• 2 years 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• 2 years 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• 2 years 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• 2 years 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• 2 years 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• 2 years ago

I like using this great library to build progressive web apps using Declarative Syntax https://github.com/maxence-charriere/go-app

FrustratedMonky• 2 years ago

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

corn13read2• 2 years ago

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

gen2brain• 2 years ago

Check https://github.com/bitfield/script for shell-like scripts in Go.

bitwize2• 2 years ago

Same, but s/Go/Scheme/g. For over 20 years now.

WuxiFingerHold• 2 years 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.

scubbo5• 2 years 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• 2 years 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.

tgv5• 2 years ago

- Typescript doesn't protect you at all against external data.

- A Go program runs single-threaded, unless you explicitly tell it not too, so I don't quite see that as a plus for Typescript.

- Go is quite a bit faster than Typescript.

- I haven't had a versioning problem in Go, and I can still compile and run old code. Typescript still beats Python in that respect, but Go wins stability.

And I say this as someone who really likes Typescript. It's a blessing for frontend browser work.

sapiogram4• 2 years ago

- A Go program runs single-threaded, unless you explicitly tell it not too, so I don't quite see that as a plus for Typescript.

I don't think this is a fair comparison. Almost all software needs some kind of concurrency, and multi-threading is the only way to do concurrency in Go. For example, the http server in Go's stdlib runs each request in its own goroutine, which I guess you technically asked for, but also can't be avoided.

GraduateDescent• 2 years ago

If you want TS-supported deserialization, just use runtime schema validation. I don't see the issue. It's dead-simple and is the way everyone does it.

synergy20• 2 years 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• 2 years ago

Java for Everything

https://www.teamten.com/lawrence/writings/java-for-everythin...

Previously HN discussion of "Java for Everything":

https://news.ycombinator.com/item?id=26934297

KingOfCoders• 2 years 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• 2 years 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• 2 years ago

I feel the same, but for me Rust is currently my hammer ;)

Checks all of the checkboxes.

liampulles2• 2 years 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• 2 years 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• 2 years 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.

physicsguy4• 2 years 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.

Lyngbakr2• 2 years 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.

caeril• 2 years ago

it's a nice language but using it for things it's not suited for like data exploration

Pedantic point, but this is an issue of library support, not the language.

For whatever reason, data scientists and ML researchers decided to write their libraries and tools in a Kindergartner's language with meaningful whitespace, dynamic typing, and various other juvenile PL features specifically aimed at five year olds and the mentally infirm.

arberavdullahu• 2 years ago

You don’t need to spend time learning standard data science tools. These tasks are well-defined, thoroughly documented in different blogs, and with today’s AI-driven code generation, basic programming knowledge is sufficient. Attempting to manipulate CSV data and generate visualizations in Go would be a waste of time, delivering subpar results.

theshrike7912• 2 years ago

I used to work for a Go shop. We dealt with financial data.

People dealing with finance are THE MOST risk-averse people I know. No new tool will be used without years of vetting and it'll still be blamed if something goes wrong - even if the new tool never touched that bit of the process =)

Source: Consulted for a finance company and it was Ye Olde Java and COBOL all the way down =)

Someone• 2 years ago

If they’re risk averse, they shouldn’t, as the OP claimed, implement basic algorithms such as rolling median, or finding a maximum instead of loading data into Pandas and doing a group by, would they?

classified2• 2 years ago

I'm surprised they were adventurous enough to use Java.

sanderjd16• 2 years ago

Using Go for data analysis is not the risk averse choice. If the comment were "everyone was using excel and maybe R and I couldn't get them to use python", then the risk aversion comment would be spot on :)

lolinder• 2 years ago

It sounds like every single data operation in this shop was done with a "new tool" written on the spot in Go.

zerkten2• 2 years ago

> People dealing with finance are THE MOST risk-averse people I know. No new tool will be used without years of vetting and it'll still be blamed if something goes wrong - even if the new tool never touched that bit of the process =)

What exactly do you mean by "finance" in your context? Even within a huge organization like Bank of America you can have an extremely conservative part and an innovative part. Obviously, most employees are likely working for the conservative part, but that doesn't mean that there aren't some people playing using modern technology. It just doesn't get evenly distributed, and you can be many layers from that usage in your department.

martinclayton• 2 years ago

My experience is different to that.

I'd say people and businesses that best understand and balance risks against potential rewards are the most successful. I know a couple of skydiving accountants...

Use of innovative tech in finance is one way for companies to gain an "edge" which can make them a lot of money. I wouldn't characterise people working in those particular areas as more risk averse.

OTOH finance businesses (esp. those that manage other peoples money) are regulated and can't put new tech into Production without careful change control. But this evolves over time, and controls were looser in the past.

There's a steady creep of regulation and control into tech used in finance outside and around IT: so called EUC (End-User Computing). This can be a source of "wrong tool for the job" syndrome. I've seen some hellish SQL written by non-IT people, but it got the job done. It's also an area where source code control, testing, and release processes are inevitably more human and error-prone.

There is a culture clash internal to large finance between "move fast and break things!" and "nothing can change, ever - too risky!" This leads to a mixture of the very old and very new, and inevitably, more complexity. Achieving homogeneity once the heterogeneous is out of the bottle is very hard - attempts to do so often (always?) lead to a variation on the xkcd "Standards" situation https://xkcd.com/927/

murray-buttchin• 2 years ago

I don't think this is true of every financial institution. Nubank runs almost entirely on Clojure except for some of its Data Science tooling which is in Scala. Sure it's JVM, but it doesn't exactly scream risk-averse to me.

dagw2• 2 years ago

Depends what you mean with "dealing with finance". If you're talking about core back office 'plumbing' the yes. Other parts are far more adventurous. Poke around any huge financial institution and you'll probably find everything from COBOL to some experimental in-house variant of Haskell.

noisy_boy3• 2 years ago

People who are saying Finance == assembly/COBOL/Java either have never worked in the area or have decided about the elephant by touching a very small part it.

Within a bank, you can have the accounting department using tested and tried approaches and/or vendor products whereas the machine learning group may be using the latest tech. But finance is not all banks - you can have non-banking financial orgs, rating firms, investment consultancies, private equity, hedge funds and on and on. A hedge fund probably uses super cutting edge stuff in one team while the other has been chugging along with stored procedures and Java.

It is too big and varied to generalize.

classified2• 2 years ago

Instead of loading data into Pandas and doing a group by

SQL can do `group by`. No need for overkill with "data science tools".

sanderjd16• 2 years ago

If you have a csv, pandas is the "less overkill" route than loading it into a database to use sql.

infecto3• 2 years ago

While definitely doable, using a SQL database to do data discovery is obtuse.

wejick2• 2 years ago

I have done the same like your colleagues. Recently I discovered that pandas + jupyter notebook is much better tools. However as gopher that needs occasional data cruncher, I totally relying on LLM chat agent to do my work.

But the rest of the work is still go, so the context switching is there but bare able. Imagine a go crawler dumping csv and a python script crunching the csv.

umvi2• 2 years ago

I've mostly seen the opposite - pandas and jupyter notebooks shipped directly to production because the data scientists and AI guys didn't know how to do anything but python. As a result, the solutions were not performant and often had lots of runtime crashes due to python's more loose typing

Spivak• 2 years ago

I'm not sure how you're going to fix this given the data science tools are in Python. Are you gonna implement a half-broken 20% of numpy/scipy for a one-off program and then try to port?

These libraries hide a lot of complexity and implementing even a few operators is a project.

philote• 2 years ago

If they're shipping notebooks to production and having so many crashes, I'd question that they even know how to do Python.

whateveracct3• 2 years ago

I used to work for a Go shop. We dealt with financial data.

Hopefully you never forgot to initialize a numeric field and had it default to 0!

ratorx3• 2 years ago

I think you are implying that this is incorrect behaviour. Could you explain why?

The alternative would be to have it be undefined, which seems clearly worse. Or do you mean that it should be a compiler warning/error instead?

RandomThoughts36• 2 years ago

rolling median, or finding a maximum

The real question is why are you writing code to make a plot when you can load a csv in excel and get a clean plot in 2 minutes.

noisy_boy3• 2 years ago

Maybe because they need to do that every day with variations and automating away the monotonous chore is one of the main points of writing code.

rcxdude• 2 years ago

Because Excel sucks at plotting, especially if you have non-trivial amounts of data.

pantsforbirds2• 2 years ago

I've almost entirely replaced Pandas with DuckDB in my day-to-day work. I wonder if it would be an easier lift for someone who is familiar with SQL, and doesnt want to pick up Pandas/Polars.

ansgri• 2 years ago

This comment might finally push me to try DuckDB, thanks. I’m quite proficient with scientific python in general, but Pandas API is just alien (and slow). SQL is more natural for its domain.

bitbasher3• 2 years ago

For that kind of processing, I prefer to use the database itself. I mean, it is a "data" base and it's pretty good at it. I get it-- sometimes you have a half cooked spreadsheet someone sends you and you need to run some analysis on it.. in that case I don't see any harm in using Go, using visidata, importing it in sqlite or using pandas or whatever.

senkora• 2 years ago

XTX? I know that they use a lot of Go.

richrichie• 2 years ago

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.

Isn’t this trivial? I use these functionalities and maintain my own Go package for such utilities. A software firm should be able to do this without much issue. In fact, it is better done in house. Don’t have to worry about dependency management and downloading the entire Pandas library for just rolling means, etc.

OezMaster• 2 years ago

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

laerus• 2 years ago

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

lcof• 2 years 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• 2 years ago

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

wejick2• 2 years 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.

_xiaz6• 2 years 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• 2 years 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.

markusw22• 2 years ago

I'm happy you found your hammer as well! :D

markusw22• 2 years 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 [1]: https://www.maragu.dev/blog/go-is-my-hammer-and-everything-i...

jebarker• 2 years 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• 2 years 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• 2 years 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.

sethops12• 2 years 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?

anta402• 2 years 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• 2 years 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

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• 2 years 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

pradn2• 2 years 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.

pradn2• 2 years 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• 2 years 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• 2 years 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.

Go is my hammer, and everything is a nail

Related Stories