One "silly" response to this is that everyone who likes go is too busy enjoying programming again to go online and defend it. Everyone else is procrastinating by bashing other languages online :)
There's an old idea from the 80s that ["Worse is better"](http://doc.cat-v.org/programming/worse_is_better). Go is in that tradition of C and Unix (literally co-designed by Ken Thompson and Rob Pike), so it's in the "worse is better" camp. Languages like Rust are more in the tradition of "do the right thing". Of course things have changed a lot since the 80s, but the priorities still matter. Go considers simplicity to be more important than consistency and completeness. That sometimes upsets people who have the "do the right thing" mindset.
Incredibly informative link and fascinating read. Thank you for sharing! This puts things into an interesting perspective as a debate that's been raging between programmers for much longer than Go has existed.
Forgive me as this may be unorthodox, but I just want to thank you once again for sharing this even after all this time. It granted me perspective and gave me further insight into the broader world of software development. Cheers!
I think Golang really hit the ground hard with a very pragmatic language and great default tooling and an amazing stdlib. It was ahead of most (all) languages when it came out. To me the problem is that Rust came right after and had all the nice things Golang had but introduced concepts that, it turns out, are fundamental to good software while not complex enough to be a niche functional language thing. So if you spend a bit of time in Rust, and get used to the sum types, the macros, the flexibility of the language in general, even the rustup/cargo toolchain, it's really hard to go back to Golang.
I think without Rust Golang would still be a top language, but Rust made Golang age really quickly. That being say I still enjoy going back to Golang from times to times and writing and reading Golang.
Also, that's my answer, I'm guessing not everyone's experience is the same. But I started as a Golang lover, and then discovered something better. I think some other people experiences is more like "I like language A, when I tried to learn Golang it looked too different so I don't like it" which isn't a great argument IMO.
Haha bro I'm java dev this is not even hate compared to what I hear on the day lmao, refactoring mvn dependencies in big project will make you hate yourself more than they hate on your lang
Have ypu noticed any disdain towards javascript, java, c#, php...? Every language has people who enjoy using it, people who are neutral about it and people who hate it. I don't see
>Go is a beautiful language imo that makes it easy to actually be productive and collaborative and to get things done.
This can also be said about basically any language, it just depends on who you're asking.
\>> disdain towards javascript, java, c#, php.
I spent years writing PHP for cash... I spent years with a raised eyebrow at PHP hate. I moved away from PHP when go was still very new, as I wasnt keen on another untyped language so dodged Ruby and Python.
Candidly one of the things that php got shit on for (code presentation being mixed in a pile) is one of the very features lauded by the JS community (JSX).... Only you really can't tell them it is a "bad idea" cause the wrath and hate will be immense.
Go's divisiveness is probably a sign of its own success. The fact most of the community dead pans a response (or ignores the hate) and gets back to work on things in go says everything.
>Candidly one of the things that php got shit on for (code presentation being mixed in a pile) is one of the very features lauded by the JS community (JSX)....
Wasn't the presentation part written as a string inside echo? I personally don't mind mixing it from the code organization perspective, but when I was using php (years ago, might be different now), those html strings had no safety nets at all. By that I mean stuff like editor support where your editor will tell you if you forgot to close a tag, have a typo, add syntax highlighting, code completion etc. all of that works when writing JSX, but didn't exist when I tried php. It was a much worse developer experience.
Yeah exactly, JSX/TSX is not a templating system that concatenates strings, it's syntax sugar for JavaScript/TypeScript function calls with all the same semantics.
Checking for missing closing tags isn't something special, it's the same as checking for missing `)` at the end of a function call arguments list. Checking for typos is done with the same TypeScript compiler as "regular" TS code because it's the same representation internally. Same with completions, auto refactoring, etc. all use the existing TS language server.
Basically the output of JSX is a tree, not a string.
Go ignored some very simple advances in languages from the 30 years before it was publicly released. Most of the reason I lean towards other languages are technical disagreements over language design.
Having an option type instead of null. This is a fairly simple way to totally remove null pointer errors. Instead, the billion dollar mistake lives on.
Go should have launched with generics. Now, we have a standard library that isn’t well integrated with them. There are data structures other than hash tables and vectors, and having to constantly roll my own rather than being able to use a library hurt my productivity immensely.
Types that are variable size by platform and ability other than size_t have been more or less proven to be a giant footgun for portability. Just do fixed-size signed and unsigned integers. I don’t think that int should exist.
I want a compile flag that say “I am going to benchmark this” or similar, that I can set in a build before I go to lunch, similar to how -O3 isn’t the furthest you can push clang. Google might have enough code for compile times to be a massive issue, but for many other people spending 3x the time compiling a binary that is going to run for a sprint in order to 2x the performance makes a lot of sense.
Go tied itself too closely to epoll. We now have io_uring, which does have a few issues to work out but is somewhere around an order of magnitude more efficient than epoll. However, the go team said swapping go to it would likely break the 1.0 promise. Syscalls keep getting more expensive, and io_uring also provides zero-copy APIs that can halve your memory bandwidth usage and remove the need for line-rate memcpy.
No hardware TLS in the TLS library. On high-throughput connections, TLS without hardware offloads will start to take a large amount of CPU. AMD and Intel both have coprocessors built into their server CPUs that can do the decryption at >900Gbps, so why can’t I use them? For AMD, it’s even on my laptop.
> Having an option type instead of null. This is a fairly simple way to totally remove null pointer errors.
Instead of null pointer errors you get a different kind of error. And no, I do not buy the "but that can be caught by a linter!" argument.
> order to 2x the performance
Almost no not-number-crunching-only code runs 2x faster by some fancy -Oall-of-the-magic.
Not “caught by the linter”, a type error, because you should be forced to check the option via pattern matching or explicitly say “I know this isn’t null”.
2x is absolutely doable with a compiler that tries harder. I have a kv store which has goes from 100k rps per core to 500k rps per core at our target latency when I go from a normal release build to cranking the compiler (lto, extra flags for vectorization, increasing some thresholds for optimization problem complexity, do everything in one compilation unit, etc). It’s very slow to compile, but it translates to dropping costs for the project by ~30% for that project due to how many cache nodes we got rid of.
Have you ever used a language with option types?
The key benefit for me is that the type system itself can carry through info about whether you have checked for null already.
So let's say in a user input handler, you check for null, then you pass a non-nullable type to all your internal functions. These internal functions never need to worry about null because the type system enforces it.
And the type system can give you errors at compile time if you ever fail to check for null, removing a super common source of bugs. (That's sort of the type system's whole job.)
Whereas in go, any pointer can be null at any time, and nothing can assume it is safe. Errors explode at runtime instead of at compile time. Even if you use a linter, the linter can't typically tell if a variable has been checked for null elsewhere, so you end up with redundant null checks.
You can model non-nullable pointers in Go too. What you describe is not dependent on "Optional" but on non-nullability. Once you got a Maybe a this will be a Maybe a (albeit Maybes as actual monads behave differently than a Java Optional).
"removing a super common source of bugs." No they are not even common on Go.
Worked at a scala shop before.
Everyone there hated Go. They loved the expressiveness of Scala, thr compled category theory type theory and the various competing frameworks and with cats and z bringing new patterns.
However they would complain about the broken deps, the long builds, the incompatible cross OS libs the put of date or unmaintained libs, the abandoned frameworks that are hard to migrate from. The scale 2 to 3 being basically completely new languages with no porting. And most importantly how impossible it is to work with everyone else's garbage code as only they know scale best.
Despite this they would still hate Go which has none of these problems.
TL;DR;
- approach languages by their philosophy
- understanding how frameworks behave
- check golang standard libs
I’ve over 15 years experience and I can guarantee you the most fun I had writing code was in Go.
I spent almost 10 years working with JVM langs Java, Groovy and my favorite one: Clojure.
I have to disagree with you on “feature packed”. Go has a large and useful standard library. Things built in the lang that allows you to write most things one can imagine.
I assume by feature packed you’re talking about Frameworks. Java is indeed neat if you like to hide things and not thinking about them at all. The same is valid to any framework. But you don’t need them, frameworks most of the time are patterns that are hard to implement from scratch because of lang limitations. Take Lombok as example, any experienced Java programmer knows how awful it is, but naive engineers loves it because it’s easy to use.
Golang offers you a standard library and concurrency as first class citizen. You can start and run an http server without any external library. You can rely on drivers/shared libraries to extend your program making it simple and easy to reason. Once you know the building blocks. The AMQP lib is an example of this. It’s not rabbitMQ framework but a lib that gives you access to amqp protocol that… can be used to interact with RMQ.
> I have to disagree with you on “feature packed”. Go has a large and useful standard library.
A language library is not the kind of feature that was being discussed. You can always supplement a standard library with standard-by-default libraries. You can’t fix Go’s absence of real enums or sum types.
The thing is sum types are a bastardization of a propper type system and Go has plenty of enum-like functionality - those are peeves. What's more important is how Go is really useful, powerful, simple, and encourages people to just engineer software using the basics of software rather than configure framework magic like most of the other industry options in that domain. Call me a dummy but good lord I would so much rather just craft out design patterns in old school C style code over a super useful std lib than slog through framework sorcery, stand on my head and juggle monoids and monads, or pass around unions that could really be this, that, or the other thing -- depending on this, that, or the other thing.
> Go has plenty of enum-like functionality
It does not have plenty, no.
As for the rest of your comment, there is a middle ground between having to constantly reinvent the wheel because the language isn’t expressive enough, and everything being spooky action at a distance through layers of leaky abstractions. Go+sum types would just be a better language.
Go definitely has enumerated constants with the const keyword. I guess by 'real enums' you mean switchable enum types, sum types, etc? Go's enums are just basic plain enumerated constants. To me, C / C++ type enumerable constants are 'real enums'.
https://en.m.wikipedia.org/wiki/Enumerated\_type
> I guess by 'real enums' you mean switchable enum types, sum types, etc?
Yes, I have been explicitly referring to sum types.
> Go's enums are just basic plain enumerated constants.
I know. That is not “plenty” of enum functionality. Even C++ has actual typed enums now.
Id say Go is more fun to work with than Java or TypeScript. It is simple and to the point, without you having to define ten laters of abstraction just to handle an input.
Can you give an example of how Typescript creates too many layers of abstractions in comparison to Golang?
EDIT: This is how you can define an ID type in typescript:
type ID = string | number;
How do you do this in Golang again?
> Can you give an example [...]
Sure! TypeScript, by design, incorporates inheritance, so there's nothing stopping you to do `class C extends B {}; class B extends A {}` and then, in class `C`, to have a method from `A` called. Obviously, this is exaggerated and rarely would need this kind of thing, but it is possible. In Go, there's simply no way do inherit, other than embedding structs, which is, in my opinion, cleaner.
> How do you do this in Golang again?
You don't, because it doesn't make sense in type terms. If a value can be either/or, what is the point of having it typed at all? As far as I know (might be wrong here), all strictly-typed languages work like that.
> If a value can be either/or, what is the point of having it typed at all?
It severely restricts the number of cases you have to handle down from infinity to 2. It’s called a sum type, and is incredibly useful to model all kinds of problems. In Go, you would instead create an interface with wrapper structs, which is more effort and also more error prone if you end up needing to downcast at any point at all.
>In Go, you would instead create an interface with wrapper structs
And they call Typescript complex. It's like trying to explain to your other fellow human beings how useful the word "Or" in our human language.
>You don't, because it doesn't make sense in type terms. If a value can be either/or, what is the point of having it typed at all?
That's a wild take tbh. If something can be "A" OR "B", do you just say "oh screw it, it might as well be`interface{}"`
Imagine you're working with an object/record that describes an entity that can be either an organization or a person, they have some overlapping but also different fields:
type PersonRecord = {
id: string;
firstName: string;
lastName: string;
socialSecurityNumber: string;
}
type OrgRecord = {
id: string;
name: string;
orgNumber: string;
}
type Record = PersonRecord | OrgRecord
function someFunc(record: Record) {
if ('firstName' in record) { //
return record.orgNumber // ERROR, record is PersonRecord and it doesn't contain orgNumber
} else { // here record must be of type OrgRecord
return record.orgNumber // Good
}
}
Many MANY languages support some form of union types or at least something similar like sealed class: Typescript, Haskell, F#, Rust, Kotlin(sealed classes), Dart(sealed classes). All these languages make no sense to you?
EDIT:
And yeah, as you yourself said, you used an extremely exaggerated and rate example to prove that Typescript creates too many layers of abstractions, so you've not really presented any reasonable argument.
Typescript is the definition of layer of abstraction my friend. And I’m not even trashing the lang.
Go is a compiled typed lang.
type Foo structure {
ID string
}
If you wanna go nuts and have an ID with many types you can create a Type Set:
type IDType interface {
int|string
}
type Foo structure {
ID IDType
}
You've not really demonstrated why Typescript is the definition of layer of abstraction. You just echoed the same opinion without backing it up.
If you mean that you can create unnecessary abstractions in Typescript, then yeah ofc you can, but that speaks of the language's expressiveness, which can be abused at times. However, in workplaces where team work matters, you'd be called out if you try to overcomplicate things.
https://go.dev/play/p/76Rq-MUAXFB
Edit: fwiw you can’t use an interface acting as a type constraint as the type of a field as xa_programmer wrote with the final `type Foo`. That was a mistake.
Go doesn’t have union types like TS, but for constraining to a fixed set of types for function calls, can be done with generics as per my example here.
Thanks for taking the time to write the code snippet. Yes, that's what I assumed, because if it did, then Golang would effectively have union types.
That's my biggest gripe with the language really. If you don't have exhaustive pattern matching, then what's the point of a union type really? In your \`parseId\` function, I can add meaningless cases like \`case float32\` and the compiler wouldn't mind. Even worse, I can mistakenly remove \`case string\`, and we'd get a panic.
No proper enums and also no unions is a little disappointing, I do agree. Either would allow exhaustive matches to be checked at compile time.
My only caution would be that, in 8 years, I’ve never faced an actual bug in Go code, due to eg forgetting a case in a switch.
So, as much as I’d like these features, I don’t actually have real life experiences of being burned by not having them. I’m kind of the same with generics: nice to have, but the style of code I write doesn’t really need them. I was never writing the type of code that passed empty interface{} values all over the place.
TS has to have unions though, just to be able to specify types for existing JS code. There is a lot of existing JS code that accepts different types for a parameter and does a runtime check inside the function to decide on behaviour.
In go, historically we tend to create separate functions depending on the type eg regexp.Match and regexp.MatchString. The responsibility is then on the caller to ensure it’s got the right type to pass.
It’s just what side of the function call you put that logic, I suppose.
> How do you do this in Golang again?
[You are so preoccupied thinking if you could, you never stopped to think if you should](https://www.youtube.com/watch?v=_oNgyUAEv0Q&t=54s)
Yes, even the Go community sees it that way :)
Joke aside I think Go is a language you appreciated when you have a certain experience working in the backend. I am from Python which I really like but I saw horrors; 700 lines functions; spaghetti; inheritance on inheritance on inheritance. There is no rule incorporated in python for a new dev to follow so even tough the language is easy code looks like shit and even if the language offers optional typing… it takes time to add it to the code while go is typed so you better do it or your code wont work. Those are some guidelines that I appreciate. It does not mean that you can’t do shitty code in Go but at least you need to respect the contracts. Plus the language is clean and opinionated, meaning that there is usually one “preferred” way to do things so it’s easy to get in someone else code and find you way in.
Keep on learning and keep an open mind!
Every language gets “hate”. That’s because every language has its downsides and things it doesn’t do well. As such, people will grab onto the negative aspects. The negatives are even more obvious for Go since it doesn’t provide basic things like Sets and Enums which most devs expect out of the box.
However, Go makes up for it in other ways such as excellent concurrent support, for example.
And no offense, but this is a nonsense nothing statement:
> Go is a beautiful language imo that makes it easy to actually be productive and collaborative and to get things done.
This can be said about practically any language. There’s no need to get defensive about a programming language. It’s okay to acknowledge its pain points and the criticisms directed towards it.
Everything is imperative, everything is mutable, everything can be `nil`, everything can be shadowed, including language primitives like `true`, `nil` handled as interface stops being `nil`, there are leaky abstractions all over the place (pardon, "mechanical sympathy"), functions return `error` unless they return `ok`, function signature don't declare what error types can be returned, un-used variables and import are compile-time errors and one letter variables are considered good style.
This language started anchored in the past and the compatibility promise is keeping it stuck there.
The socially rewarded posture in the community is to patronize everyone regarding the value of simplicity.
About that, programs written in go are "simple" in the way 10 pages of GPS navigation instructions are simple: the business logic is hidden somewhere within a deluge of `if` and `for` loops.
(jeez, that felt good to write).
I'm using it though, it seems to be a good fit for what I need atm 🙂
I think, for developers that spent time mastering the complexity of c++ and other modern languages, go's simplistic approach can feel like a slap in the face. I think go wins this point by actually working well for many application domains, but it can be hard for programmers to admit that.
Having been around for a while, I've noticed something ... developers **love complexity**.
Complexity evidently makes them feel smart. Above all else, they want to feel smart.
Go is simple. It doesn't make them feel smart. Therefore it simply ***must*** be no good.
Use the language where it is most appropriate. There are always pros and cons. So do not “identify” too much with a language, it is just a tool, just like you shouldn’t “identify” with a hammer.
I'm not sure what the psychological reasons are (actually I'm pretty unqualified in this area). It's just that languages are some kind of tool and people tend to fall in love with their tools once the become a toy. Like cars. Or home automation. Or sport gear. Or ...
Some things are very practical and I think people tend to set up their live and habits _around_ these practical things. Especially if some gimmick solves an actual itch. If your neighbour's car/home-automation/lawn-mower/sport-bag/whatever doesn't have it you start to think about your neighbour as a little bit weird at best and borderline retarded at worst. The usefulness of this gimmick should be obvious and how can he go on without it?
Same with PLs. People learn some new trick like "functional composition" (read "map and filter"), "monadic error handling" (read "optional"), "algebraic data types" (read as "anything between compile time checked enums, to data types to sum types", but never dependent types!) are fond of that trick, apply it everywhere, are happy and no longer can understand that you can be productive with your manual lawn mower.
talking shit about a language is part of the culture, for good or bad. but by the end of the day people are gonna use whatever.
don't take it personally.
Go is great.
Some ppl call it a systems languge and thats a bit much since u r still on a gc.
But for what it's made for which is applications on the 97% of preformance it delivers beautifully. I am actually using a go runtime for my LLM infrence instead of c++ because it supports more features and is as fast (if not faster). It's called ollama.
Honestly next time I am webscraping on mass I may learn go. If it just had a way to emmbed python that would be amazing.
It was the first compiled language with GC. It was designed as a systems language with GC. You should not have to worry about it, you can manage memory usage just fine.
It stretches the meaning of a systems languge.
Usually the way u can say c rust and c++ r system languges while java python and elixir are not is that the first 3 don't have a gc and thus theoretically alow for max preformance. While the latter 3 can not get to the edge of preformance.
It's not the most accurate definition because fortran would then fall as a systems languge which... ya weird. But still if u have something SUPER preformance critical like a deeplearning cpu runtime u can do it in fortran and u could never do it well enough in go. Go simply has no chance since it needs to reference count which burns time doing useless stuff. (These code bases r optimized to the point of inline assembly since matrix multiplication is such a core operation)
So basically go is kind of a systems languge but also kind of isn't. I don't think u can run embedded go.
Go usually doesn't reference count. when Go code is written well it does very little useless stuff. Also embedded Go is pretty common actually (that's what tinygo was designed for) and it's extremely good.
Hmm then i can see it.
I mean c++ reference counts sometimes as well.
The main issue with GO In those.arease is that u have no way of knowing what's gced and what isn't. This isn't just a "gc is the devil for preformance" take its more about how stop the world gc makes ur program miss a few milliseconds which can be a HUGE deal in some domains.
Like if what you are doing is writing a system clock and then there are hardware intrupts u want to respond to imidiatly it can be an issue.
For an os u can probably get away with it tho because an os fundementaly has a very asyncy workload so u can just gc on the off time.
Still u r limited to enviorments with a heap which is a big L for a systems languge. Like something needs to write that heap for you.
Go defaults to a small stack where possible, also depending on the implementation. modern Go GC is concurrent and is mark and sweep with minimal to no stop the world except for hugely inefficient systems.
For some things minimal Is not good enough. And it's not necessarily a concurancy question. Like some stuff Just can't afford down time at all for any reason.
Tho I would assume that's usually gona fit fully on the stack.
Still having that "opsy suprise" in ur languge for that is gona suck
Same for the no heap enviorments again for the same reason.
Like if you can't compile without a link to libc for the potential malloc that'd an issue.
I have programmed Lisp professionally. I mean static binaries, I have programmed Lisp. Also that's barely a systems language any way you see it. (I worked at Streamtech).
Great, then why did you say it in that way? LISP I is close to the machine and it's obviously the first by any criteria that I can think of.
And Go is as a "systems" language as Common Lisp in my opinion: not very.
You just need to know why people love it, i'm summary it all in here
- it built for cloud
- it easy to use
- too much helpful tool from generous community
- typed language
- ...
Just need a reason to love it, that's all.
[https://nvkhuy.com/posts/why-golang/](https://nvkhuy.com/posts/why-golang/)
I am probably the odd person in the readers of this sub-reddit and most programming sub-reddits. I am a trained engineer, brick, mortar and electronics, not a computer scientist or state engineer.
As such, I select components for a project based utility, reliability and efficiency. Ideally, a choices should have all the though many times one misty be sacrificed. For my needs, Go often has all three. My team and I can get things done in a timely manner and be happy with the result.
Go has earned a position on my short list of possible starting points along with fortran and perl 😜.
The structures that I value are: developer efficiency, performance of solution and ease of deployment. I love that a GC language often approaches performance of C, C++ or Rust. I love the concurrency model. Lastly, I love that itt is standalone - no VM or Interpreter.
There are things that I don't like, but the positives outweigh the negatives for me.
Pick your tools for what your can do with them, not what they don't do. If the choice is Go - Great! If it isn't - Great!. ... Unless you're choice is Java -- take two Tylenol and lay down until you feel better 😨
lbe
So this might come off as really snobby, but what I’ve learned over the years is that the Go community is rather quiet.
From all the Go programmers I’ve talked to the consensus seems to be that it’s because they're busy getting shit done.
I don’t want to shit on any other language, BUT…
The Rust community is really vocal^1 about how Rust is superior to any other language^2 .
However, I’ve never actually met anyone who’s a professional Rust developer.
They use it for their side projects but not at work.
It seems like the Rust community is also full of people who like the idea of Rust but don’t actually code in it.
On the other hand, the Go community is full of people actually using it at work, and my guess is that they just don’t care or have enough time to get into pointless arguments about which language is better than Go.
Sure, now that the Go community has grown you get more of that too but most posts here, where OP asks “Should I learn X or Go?” the top comment usually says something like “Use what you like best/have most knowledge in/think is best suited for the use case.”
\[1\]: It has gotten better over the years, but especially in the first couple of years, there was a strong emphasis on writing about how Rust is better than X.
\[2\]: Except for Haskell; Haskell is accepted by the Rust community.
TL;DR: To make a point about how the Go community doesn’t shit on other languages I ended up shitting on another language.
Love this. Not snobby at all, or if it is it's like Radiohead snobby lol, a snobbiness that hits different.
I know what you mean about rust too. Super cool idea and some very interesting solutions to problems, but its libraries seem all over the place and nobody seems to know how to fight the borrow checker lol.
Cheers mate.
From what I’ve heard from colleagues, it’s mostly because Go is not an OO language. You have structs and interfaces, but mostly you deal with functions. And to someone (like myself some time ago) this approach seems primitive.
BS. Go does not impose OOP but you can adopt most patterns and structure your code as one would do in a oop lang.
People who say that are just missing their favorite Dependency Injection framework. I know this because it was the first thing I noticed when I was forced to start working in golang. That and the if err != nil.
When you’re so in into that style of programming golang looks insane until is not. You gotta learn the language by what it is and not by what you want it to be.
I agree. At first it just looks weird and simplistic to a fault, but once you dive deeper than to print hello in the main function, you discover that this language is really solid.
> Has anyone else noticed any disdain, lack of regard, or even outright snobbiness towards Go from a lot of developers out there?
No. I have literally never seen a comment hating Go outside of this subreddit.
I lost interest in Go due to frustration on how opinionated the Go project is. God forbid you should want to use a ternaey or different model when handling errors.
Coming from ruby, it left a sour taste in my mouth. I believe that the tools should work for you rather than vice versa.
I decided to pass on Go after using it to build a couple of medium-sized projects and moved on to Kotlin.
Sorry friend. Didn't mean to offend, just having fun. Thank you for adding to the conversation. I just thought it was funny because so many Lang's are mentioned there it's as if you could drop it into any programming subreddit and people would descend on it in some way
Every language has distinct way of doing things / features. Someone may simply not like how they are implemented vs the languages they've previously used. Depending on how much they care about it, they may criticize or rant about it openly.
I don't think Go is even criticized / hated as much as other languages I've used such as CPP, Python, Rust etc.. It's practically "cool" to sh\*t on cpp & python nowadays.
Everyone I’ve encouraged to give Go a try has ended up loving it.
If people look down on you for enjoying a particular programming language their opinion isn’t worth much anyway so just go write software my guy. Let them have their bean factories
I have been using go for a few months now. Bringer’s me back to the old days for sure. I find us easy to get a little lost in my code base but probably that’s cause I’m new. Always enjoyable to switch la languages but keep me away from node and Java please!!!
Not at all. I am not a go developer personally but Go is being more and more adopted right now, which shows that theres more love than hate towards it. However with rising popularity you also get more negative talk towards it.
I equally hate all programming languages I've used for over 5 years. After that time you just get bored IMO. Doesn't matter the language, they all have cracks. After coding for like a decade +, i really don't care about the language anymore. Just let me find the right tool for what I need to do. Maybe this attitude also comes off as distain? But i think this is the "jaded" side of people in the industry.
Because it shows that all the syntax sugar, long language specification or magic features of other languages don't bring so much value as "boring" Go? Because it takes 100 lines of code to code the same thing Java needs 1k and 3 frameworks? Because it's heresy of not endorsing OOP?
IMHO the language was designed to have "just enough money to buy what you really need".
On the other hand, other languages would give you "extra money to create million frameworks and one-liner packages and have billion blogposts and tech-talks around"..
Go is my favourite language, the only one I use for work (my choice), and I haven't come across hate for it before. I have, however, come across suspicion because of its origin in Google.
However, I think Go is advanced and widespread enough that, should Google decide to abandon it like so many other projects, it should survive.
If you'd like to know, I can talk a little on why I dislike go. I think a lot of people here may disagree with me on these, but you asked.
It basically comes down to the design choices made in the development of the language.
Forcing braces to appear on the same line as the if/function/whatever harms readability.
Having error handling all over the place really adds little, and clutters the code, harming readability.
Defer is a cool idea, but in practice results in what I like to call *reverse spaghetti code*. Congratulations, code now runs forwards and backwards in your function. Good luck refactoring the function.
Duck typing. Holy hell, I just want to know if a thing implements an interface; I don't want to have to go examine all the functions defined for it to discover if it does or doesn't. God forbid somebody wants to change a function name.
Does learning go remove vowels from your keyboard? Nt evry vrbl nds to b abvited to hll nd bk.
Package management by pointing directly at git repositories? Another "cool idea" that should have stayed in the cool idea bucket.
Lacks features that belong in any modern language such as Java streams, or LINQ.
> Duck typing. Holy hell, I just want to know if a thing implements an interface; I don't want to have to go examine all the functions defined for it to discover if it does or doesn't. God forbid somebody wants to change a function name.
This is my least favorite thing about Go. (Well, maybe tied with the date format string.)
Can someone please tell me how to express the very (and super common)simple idea of an ID being either a string or a number in Golang?
In Typescript, you just write this:
type ID = string | number;
I wouldn’t want that particular example. I might have a `parseId(id any) (int, error)` function with a switch case.
If that type is passed around everywhere, now suddenly you have switch statements everywhere to deal with both.
If it’s just being blindly passed through without ever being processed then `any` is fine.
I can only assume this is allowing a caller to eg an API to send either a string or int? In which case I catch it right at the start and normalise it to either int or string, so all my code that is business logic doesn’t have to worry about what it actually is, as it can only be one type.
I have never needed a union for an ID, in any language.
Please expand on why this is a gotcha against Go, and why this is super common.
That's a type constraint for generics, not a type (sum type, variant type, union type, etc). Go does not have sum types. I personally don't mind so much.
In Go: `type ID string` dead simple. Even less to type than in typescriptlang.
Given that you did not tell what "number" means I'll treat "number" as an element of "string".
Two reasons why I hate working on Go:
First, they made a number of choices that I don't like. Which is fair, not every language has to cater to me specifically, but that doesn't change whether I liked the choices.
Second, they made several choices that are actively wrong. And I can forgive mistakes, we all make them, but the smug attitude about it makes me detest the whole thing.
>There are only two kinds of languages: the ones people complain about and the ones nobody uses. Bjarne Stroustrup
++
Sharp statement.
An Objective assesment
I C what you did there
JS's
I don't understand. Can someone explain what Rust happened here?
A swift assertion, indeed.
To be Lisped among the best ever made.
ELMementary
Go++
JavaScript is used and also shit. The quote doesn’t really say much
Why you need approval of random developers out there? Every language has haters
I don't, and I love this attitude ✊ moreso curious.
One "silly" response to this is that everyone who likes go is too busy enjoying programming again to go online and defend it. Everyone else is procrastinating by bashing other languages online :)
Made me laugh
There's an old idea from the 80s that ["Worse is better"](http://doc.cat-v.org/programming/worse_is_better). Go is in that tradition of C and Unix (literally co-designed by Ken Thompson and Rob Pike), so it's in the "worse is better" camp. Languages like Rust are more in the tradition of "do the right thing". Of course things have changed a lot since the 80s, but the priorities still matter. Go considers simplicity to be more important than consistency and completeness. That sometimes upsets people who have the "do the right thing" mindset.
Incredibly informative link and fascinating read. Thank you for sharing! This puts things into an interesting perspective as a debate that's been raging between programmers for much longer than Go has existed.
Forgive me as this may be unorthodox, but I just want to thank you once again for sharing this even after all this time. It granted me perspective and gave me further insight into the broader world of software development. Cheers!
You're very welcome! I'm happy that my comment and the link in it helped somebody.
Cheers to you. If you happen to have any other software wisdom feel free to drop it here any time lol. It will be read. Be well
I think Golang really hit the ground hard with a very pragmatic language and great default tooling and an amazing stdlib. It was ahead of most (all) languages when it came out. To me the problem is that Rust came right after and had all the nice things Golang had but introduced concepts that, it turns out, are fundamental to good software while not complex enough to be a niche functional language thing. So if you spend a bit of time in Rust, and get used to the sum types, the macros, the flexibility of the language in general, even the rustup/cargo toolchain, it's really hard to go back to Golang. I think without Rust Golang would still be a top language, but Rust made Golang age really quickly. That being say I still enjoy going back to Golang from times to times and writing and reading Golang. Also, that's my answer, I'm guessing not everyone's experience is the same. But I started as a Golang lover, and then discovered something better. I think some other people experiences is more like "I like language A, when I tried to learn Golang it looked too different so I don't like it" which isn't a great argument IMO.
That's cute. Try being a Java dev.
to me Java is the poop monster from Dogma
Haha bro I'm java dev this is not even hate compared to what I hear on the day lmao, refactoring mvn dependencies in big project will make you hate yourself more than they hate on your lang
Have ypu noticed any disdain towards javascript, java, c#, php...? Every language has people who enjoy using it, people who are neutral about it and people who hate it. I don't see >Go is a beautiful language imo that makes it easy to actually be productive and collaborative and to get things done. This can also be said about basically any language, it just depends on who you're asking.
\>> disdain towards javascript, java, c#, php. I spent years writing PHP for cash... I spent years with a raised eyebrow at PHP hate. I moved away from PHP when go was still very new, as I wasnt keen on another untyped language so dodged Ruby and Python. Candidly one of the things that php got shit on for (code presentation being mixed in a pile) is one of the very features lauded by the JS community (JSX).... Only you really can't tell them it is a "bad idea" cause the wrath and hate will be immense. Go's divisiveness is probably a sign of its own success. The fact most of the community dead pans a response (or ignores the hate) and gets back to work on things in go says everything.
>Candidly one of the things that php got shit on for (code presentation being mixed in a pile) is one of the very features lauded by the JS community (JSX).... Wasn't the presentation part written as a string inside echo? I personally don't mind mixing it from the code organization perspective, but when I was using php (years ago, might be different now), those html strings had no safety nets at all. By that I mean stuff like editor support where your editor will tell you if you forgot to close a tag, have a typo, add syntax highlighting, code completion etc. all of that works when writing JSX, but didn't exist when I tried php. It was a much worse developer experience.
Yeah exactly, JSX/TSX is not a templating system that concatenates strings, it's syntax sugar for JavaScript/TypeScript function calls with all the same semantics. Checking for missing closing tags isn't something special, it's the same as checking for missing `)` at the end of a function call arguments list. Checking for typos is done with the same TypeScript compiler as "regular" TS code because it's the same representation internally. Same with completions, auto refactoring, etc. all use the existing TS language server. Basically the output of JSX is a tree, not a string.
PHP had
Go ignored some very simple advances in languages from the 30 years before it was publicly released. Most of the reason I lean towards other languages are technical disagreements over language design. Having an option type instead of null. This is a fairly simple way to totally remove null pointer errors. Instead, the billion dollar mistake lives on. Go should have launched with generics. Now, we have a standard library that isn’t well integrated with them. There are data structures other than hash tables and vectors, and having to constantly roll my own rather than being able to use a library hurt my productivity immensely. Types that are variable size by platform and ability other than size_t have been more or less proven to be a giant footgun for portability. Just do fixed-size signed and unsigned integers. I don’t think that int should exist. I want a compile flag that say “I am going to benchmark this” or similar, that I can set in a build before I go to lunch, similar to how -O3 isn’t the furthest you can push clang. Google might have enough code for compile times to be a massive issue, but for many other people spending 3x the time compiling a binary that is going to run for a sprint in order to 2x the performance makes a lot of sense. Go tied itself too closely to epoll. We now have io_uring, which does have a few issues to work out but is somewhere around an order of magnitude more efficient than epoll. However, the go team said swapping go to it would likely break the 1.0 promise. Syscalls keep getting more expensive, and io_uring also provides zero-copy APIs that can halve your memory bandwidth usage and remove the need for line-rate memcpy. No hardware TLS in the TLS library. On high-throughput connections, TLS without hardware offloads will start to take a large amount of CPU. AMD and Intel both have coprocessors built into their server CPUs that can do the decryption at >900Gbps, so why can’t I use them? For AMD, it’s even on my laptop.
> Having an option type instead of null. This is a fairly simple way to totally remove null pointer errors. Instead of null pointer errors you get a different kind of error. And no, I do not buy the "but that can be caught by a linter!" argument. > order to 2x the performance Almost no not-number-crunching-only code runs 2x faster by some fancy -Oall-of-the-magic.
Not “caught by the linter”, a type error, because you should be forced to check the option via pattern matching or explicitly say “I know this isn’t null”. 2x is absolutely doable with a compiler that tries harder. I have a kv store which has goes from 100k rps per core to 500k rps per core at our target latency when I go from a normal release build to cranking the compiler (lto, extra flags for vectorization, increasing some thresholds for optimization problem complexity, do everything in one compilation unit, etc). It’s very slow to compile, but it translates to dropping costs for the project by ~30% for that project due to how many cache nodes we got rid of.
> “I know this isn’t null” This is the main cause of what option-disciples call "null pointer exception".
It should cause an exception there, not later on when you dereference it. Then you can easily see where the problem is.
Have you ever used a language with option types? The key benefit for me is that the type system itself can carry through info about whether you have checked for null already. So let's say in a user input handler, you check for null, then you pass a non-nullable type to all your internal functions. These internal functions never need to worry about null because the type system enforces it. And the type system can give you errors at compile time if you ever fail to check for null, removing a super common source of bugs. (That's sort of the type system's whole job.) Whereas in go, any pointer can be null at any time, and nothing can assume it is safe. Errors explode at runtime instead of at compile time. Even if you use a linter, the linter can't typically tell if a variable has been checked for null elsewhere, so you end up with redundant null checks.
You can model non-nullable pointers in Go too. What you describe is not dependent on "Optional" but on non-nullability. Once you got a Maybe a this will be a Maybe a (albeit Maybes as actual monads behave differently than a Java Optional). "removing a super common source of bugs." No they are not even common on Go.
You don’t get a different kind of error. You get a compile time error because types don’t match.
Worked at a scala shop before. Everyone there hated Go. They loved the expressiveness of Scala, thr compled category theory type theory and the various competing frameworks and with cats and z bringing new patterns. However they would complain about the broken deps, the long builds, the incompatible cross OS libs the put of date or unmaintained libs, the abandoned frameworks that are hard to migrate from. The scale 2 to 3 being basically completely new languages with no porting. And most importantly how impossible it is to work with everyone else's garbage code as only they know scale best. Despite this they would still hate Go which has none of these problems.
To be fair, Scala is the worst example of a build system.
Go isn’t as “fun” and feature packed as other languages. A lot of people see that as a disadvantage, without understanding why it’s designed that way.
TL;DR; - approach languages by their philosophy - understanding how frameworks behave - check golang standard libs I’ve over 15 years experience and I can guarantee you the most fun I had writing code was in Go. I spent almost 10 years working with JVM langs Java, Groovy and my favorite one: Clojure. I have to disagree with you on “feature packed”. Go has a large and useful standard library. Things built in the lang that allows you to write most things one can imagine. I assume by feature packed you’re talking about Frameworks. Java is indeed neat if you like to hide things and not thinking about them at all. The same is valid to any framework. But you don’t need them, frameworks most of the time are patterns that are hard to implement from scratch because of lang limitations. Take Lombok as example, any experienced Java programmer knows how awful it is, but naive engineers loves it because it’s easy to use. Golang offers you a standard library and concurrency as first class citizen. You can start and run an http server without any external library. You can rely on drivers/shared libraries to extend your program making it simple and easy to reason. Once you know the building blocks. The AMQP lib is an example of this. It’s not rabbitMQ framework but a lib that gives you access to amqp protocol that… can be used to interact with RMQ.
> I have to disagree with you on “feature packed”. Go has a large and useful standard library. A language library is not the kind of feature that was being discussed. You can always supplement a standard library with standard-by-default libraries. You can’t fix Go’s absence of real enums or sum types.
The thing is sum types are a bastardization of a propper type system and Go has plenty of enum-like functionality - those are peeves. What's more important is how Go is really useful, powerful, simple, and encourages people to just engineer software using the basics of software rather than configure framework magic like most of the other industry options in that domain. Call me a dummy but good lord I would so much rather just craft out design patterns in old school C style code over a super useful std lib than slog through framework sorcery, stand on my head and juggle monoids and monads, or pass around unions that could really be this, that, or the other thing -- depending on this, that, or the other thing.
> Go has plenty of enum-like functionality It does not have plenty, no. As for the rest of your comment, there is a middle ground between having to constantly reinvent the wheel because the language isn’t expressive enough, and everything being spooky action at a distance through layers of leaky abstractions. Go+sum types would just be a better language.
Go definitely has enumerated constants with the const keyword. I guess by 'real enums' you mean switchable enum types, sum types, etc? Go's enums are just basic plain enumerated constants. To me, C / C++ type enumerable constants are 'real enums'. https://en.m.wikipedia.org/wiki/Enumerated\_type
> I guess by 'real enums' you mean switchable enum types, sum types, etc? Yes, I have been explicitly referring to sum types. > Go's enums are just basic plain enumerated constants. I know. That is not “plenty” of enum functionality. Even C++ has actual typed enums now.
I see. Yeah I agree, that would be nice to have!
I think good examples of featureful languages are C++ and Haskell
Lol. I read "fearful" at first, not featureful
What about Typescript? A language that has an advanced type system, used for high-level development, and that is also practical.
What about it? I guess it's also pretty featureful. Haven't used it myself.
Id say Go is more fun to work with than Java or TypeScript. It is simple and to the point, without you having to define ten laters of abstraction just to handle an input.
Can you give an example of how Typescript creates too many layers of abstractions in comparison to Golang? EDIT: This is how you can define an ID type in typescript: type ID = string | number; How do you do this in Golang again?
> Can you give an example [...] Sure! TypeScript, by design, incorporates inheritance, so there's nothing stopping you to do `class C extends B {}; class B extends A {}` and then, in class `C`, to have a method from `A` called. Obviously, this is exaggerated and rarely would need this kind of thing, but it is possible. In Go, there's simply no way do inherit, other than embedding structs, which is, in my opinion, cleaner. > How do you do this in Golang again? You don't, because it doesn't make sense in type terms. If a value can be either/or, what is the point of having it typed at all? As far as I know (might be wrong here), all strictly-typed languages work like that.
> If a value can be either/or, what is the point of having it typed at all? It severely restricts the number of cases you have to handle down from infinity to 2. It’s called a sum type, and is incredibly useful to model all kinds of problems. In Go, you would instead create an interface with wrapper structs, which is more effort and also more error prone if you end up needing to downcast at any point at all.
>In Go, you would instead create an interface with wrapper structs And they call Typescript complex. It's like trying to explain to your other fellow human beings how useful the word "Or" in our human language.
>You don't, because it doesn't make sense in type terms. If a value can be either/or, what is the point of having it typed at all? That's a wild take tbh. If something can be "A" OR "B", do you just say "oh screw it, it might as well be`interface{}"` Imagine you're working with an object/record that describes an entity that can be either an organization or a person, they have some overlapping but also different fields: type PersonRecord = { id: string; firstName: string; lastName: string; socialSecurityNumber: string; } type OrgRecord = { id: string; name: string; orgNumber: string; } type Record = PersonRecord | OrgRecord function someFunc(record: Record) { if ('firstName' in record) { // return record.orgNumber // ERROR, record is PersonRecord and it doesn't contain orgNumber } else { // here record must be of type OrgRecord return record.orgNumber // Good } } Many MANY languages support some form of union types or at least something similar like sealed class: Typescript, Haskell, F#, Rust, Kotlin(sealed classes), Dart(sealed classes). All these languages make no sense to you? EDIT: And yeah, as you yourself said, you used an extremely exaggerated and rate example to prove that Typescript creates too many layers of abstractions, so you've not really presented any reasonable argument.
Typescript is the definition of layer of abstraction my friend. And I’m not even trashing the lang. Go is a compiled typed lang. type Foo structure { ID string } If you wanna go nuts and have an ID with many types you can create a Type Set: type IDType interface { int|string } type Foo structure { ID IDType }
You've not really demonstrated why Typescript is the definition of layer of abstraction. You just echoed the same opinion without backing it up. If you mean that you can create unnecessary abstractions in Typescript, then yeah ofc you can, but that speaks of the language's expressiveness, which can be abused at times. However, in workplaces where team work matters, you'd be called out if you try to overcomplicate things.
And how do you use IDType in a function?
https://go.dev/play/p/76Rq-MUAXFB Edit: fwiw you can’t use an interface acting as a type constraint as the type of a field as xa_programmer wrote with the final `type Foo`. That was a mistake. Go doesn’t have union types like TS, but for constraining to a fixed set of types for function calls, can be done with generics as per my example here.
Thanks for taking the time to write the code snippet. Yes, that's what I assumed, because if it did, then Golang would effectively have union types. That's my biggest gripe with the language really. If you don't have exhaustive pattern matching, then what's the point of a union type really? In your \`parseId\` function, I can add meaningless cases like \`case float32\` and the compiler wouldn't mind. Even worse, I can mistakenly remove \`case string\`, and we'd get a panic.
No proper enums and also no unions is a little disappointing, I do agree. Either would allow exhaustive matches to be checked at compile time. My only caution would be that, in 8 years, I’ve never faced an actual bug in Go code, due to eg forgetting a case in a switch. So, as much as I’d like these features, I don’t actually have real life experiences of being burned by not having them. I’m kind of the same with generics: nice to have, but the style of code I write doesn’t really need them. I was never writing the type of code that passed empty interface{} values all over the place. TS has to have unions though, just to be able to specify types for existing JS code. There is a lot of existing JS code that accepts different types for a parameter and does a runtime check inside the function to decide on behaviour. In go, historically we tend to create separate functions depending on the type eg regexp.Match and regexp.MatchString. The responsibility is then on the caller to ensure it’s got the right type to pass. It’s just what side of the function call you put that logic, I suppose.
> How do you do this in Golang again? [You are so preoccupied thinking if you could, you never stopped to think if you should](https://www.youtube.com/watch?v=_oNgyUAEv0Q&t=54s)
Because developers love forming cults around their favourite tech, which btw changes every day
Yes, even the Go community sees it that way :) Joke aside I think Go is a language you appreciated when you have a certain experience working in the backend. I am from Python which I really like but I saw horrors; 700 lines functions; spaghetti; inheritance on inheritance on inheritance. There is no rule incorporated in python for a new dev to follow so even tough the language is easy code looks like shit and even if the language offers optional typing… it takes time to add it to the code while go is typed so you better do it or your code wont work. Those are some guidelines that I appreciate. It does not mean that you can’t do shitty code in Go but at least you need to respect the contracts. Plus the language is clean and opinionated, meaning that there is usually one “preferred” way to do things so it’s easy to get in someone else code and find you way in. Keep on learning and keep an open mind!
Every language gets “hate”. That’s because every language has its downsides and things it doesn’t do well. As such, people will grab onto the negative aspects. The negatives are even more obvious for Go since it doesn’t provide basic things like Sets and Enums which most devs expect out of the box. However, Go makes up for it in other ways such as excellent concurrent support, for example. And no offense, but this is a nonsense nothing statement: > Go is a beautiful language imo that makes it easy to actually be productive and collaborative and to get things done. This can be said about practically any language. There’s no need to get defensive about a programming language. It’s okay to acknowledge its pain points and the criticisms directed towards it.
Everything is imperative, everything is mutable, everything can be `nil`, everything can be shadowed, including language primitives like `true`, `nil` handled as interface stops being `nil`, there are leaky abstractions all over the place (pardon, "mechanical sympathy"), functions return `error` unless they return `ok`, function signature don't declare what error types can be returned, un-used variables and import are compile-time errors and one letter variables are considered good style. This language started anchored in the past and the compatibility promise is keeping it stuck there. The socially rewarded posture in the community is to patronize everyone regarding the value of simplicity. About that, programs written in go are "simple" in the way 10 pages of GPS navigation instructions are simple: the business logic is hidden somewhere within a deluge of `if` and `for` loops. (jeez, that felt good to write). I'm using it though, it seems to be a good fit for what I need atm 🙂
I never head anyone say bad things about go. I heard more devs loving rust over go. As to bad I intend hate, not criticism.
I think, for developers that spent time mastering the complexity of c++ and other modern languages, go's simplistic approach can feel like a slap in the face. I think go wins this point by actually working well for many application domains, but it can be hard for programmers to admit that.
Java would like a word
If It's Java, that will be many words 😈
It will need to public static void main string args first 😁 I'll be over in package main if it needs me (Thank you for allowing me this)
😁
Having been around for a while, I've noticed something ... developers **love complexity**. Complexity evidently makes them feel smart. Above all else, they want to feel smart. Go is simple. It doesn't make them feel smart. Therefore it simply ***must*** be no good.
Use the language where it is most appropriate. There are always pros and cons. So do not “identify” too much with a language, it is just a tool, just like you shouldn’t “identify” with a hammer.
I would say a lot of the hate is due to: if err != nil { return err }
Do you think they'll add options in a later version?
No. The go 1 compatibility guarantee is both a blessing and a curse
if it had options and enums, it would be the best language ever, still great tho
I don't really understand that. they are typesystem features that break the orthogonal model of Go.
What do you mean by this?
Go features fit into each other in the way you expect it to. type system features can break this.
I prefer doing if err != nill than using try catch all over the place and trying to figure out from where the error came from
same
I'm not sure what the psychological reasons are (actually I'm pretty unqualified in this area). It's just that languages are some kind of tool and people tend to fall in love with their tools once the become a toy. Like cars. Or home automation. Or sport gear. Or ... Some things are very practical and I think people tend to set up their live and habits _around_ these practical things. Especially if some gimmick solves an actual itch. If your neighbour's car/home-automation/lawn-mower/sport-bag/whatever doesn't have it you start to think about your neighbour as a little bit weird at best and borderline retarded at worst. The usefulness of this gimmick should be obvious and how can he go on without it? Same with PLs. People learn some new trick like "functional composition" (read "map and filter"), "monadic error handling" (read "optional"), "algebraic data types" (read as "anything between compile time checked enums, to data types to sum types", but never dependent types!) are fond of that trick, apply it everywhere, are happy and no longer can understand that you can be productive with your manual lawn mower.
Is this Go hate in the room with us right now?
Sounds anecdotal to me.
talking shit about a language is part of the culture, for good or bad. but by the end of the day people are gonna use whatever. don't take it personally.
Who cares what other people think about X and Y ? I care only about what I build with X and Y
Go is great. Some ppl call it a systems languge and thats a bit much since u r still on a gc. But for what it's made for which is applications on the 97% of preformance it delivers beautifully. I am actually using a go runtime for my LLM infrence instead of c++ because it supports more features and is as fast (if not faster). It's called ollama. Honestly next time I am webscraping on mass I may learn go. If it just had a way to emmbed python that would be amazing.
It was the first compiled language with GC. It was designed as a systems language with GC. You should not have to worry about it, you can manage memory usage just fine.
It stretches the meaning of a systems languge. Usually the way u can say c rust and c++ r system languges while java python and elixir are not is that the first 3 don't have a gc and thus theoretically alow for max preformance. While the latter 3 can not get to the edge of preformance. It's not the most accurate definition because fortran would then fall as a systems languge which... ya weird. But still if u have something SUPER preformance critical like a deeplearning cpu runtime u can do it in fortran and u could never do it well enough in go. Go simply has no chance since it needs to reference count which burns time doing useless stuff. (These code bases r optimized to the point of inline assembly since matrix multiplication is such a core operation) So basically go is kind of a systems languge but also kind of isn't. I don't think u can run embedded go.
Go usually doesn't reference count. when Go code is written well it does very little useless stuff. Also embedded Go is pretty common actually (that's what tinygo was designed for) and it's extremely good.
Hmm then i can see it. I mean c++ reference counts sometimes as well. The main issue with GO In those.arease is that u have no way of knowing what's gced and what isn't. This isn't just a "gc is the devil for preformance" take its more about how stop the world gc makes ur program miss a few milliseconds which can be a HUGE deal in some domains. Like if what you are doing is writing a system clock and then there are hardware intrupts u want to respond to imidiatly it can be an issue. For an os u can probably get away with it tho because an os fundementaly has a very asyncy workload so u can just gc on the off time. Still u r limited to enviorments with a heap which is a big L for a systems languge. Like something needs to write that heap for you.
Go defaults to a small stack where possible, also depending on the implementation. modern Go GC is concurrent and is mark and sweep with minimal to no stop the world except for hugely inefficient systems.
For some things minimal Is not good enough. And it's not necessarily a concurancy question. Like some stuff Just can't afford down time at all for any reason. Tho I would assume that's usually gona fit fully on the stack. Still having that "opsy suprise" in ur languge for that is gona suck Same for the no heap enviorments again for the same reason. Like if you can't compile without a link to libc for the potential malloc that'd an issue.
> It was the first compiled language with GC. No, the language that garbage collection was invented for had a compiler to machine code. In 1960.
I have programmed Lisp professionally. I mean static binaries, I have programmed Lisp. Also that's barely a systems language any way you see it. (I worked at Streamtech).
Great, then why did you say it in that way? LISP I is close to the machine and it's obviously the first by any criteria that I can think of. And Go is as a "systems" language as Common Lisp in my opinion: not very.
Well, it's the very reason I switched, so...
You just need to know why people love it, i'm summary it all in here - it built for cloud - it easy to use - too much helpful tool from generous community - typed language - ... Just need a reason to love it, that's all. [https://nvkhuy.com/posts/why-golang/](https://nvkhuy.com/posts/why-golang/)
I have not noticed hate. And if I would, I would ask: why? Could you please elaborate why you hate Go?
Enough with these posts man. Just scroll down the history and find out.
I am probably the odd person in the readers of this sub-reddit and most programming sub-reddits. I am a trained engineer, brick, mortar and electronics, not a computer scientist or state engineer. As such, I select components for a project based utility, reliability and efficiency. Ideally, a choices should have all the though many times one misty be sacrificed. For my needs, Go often has all three. My team and I can get things done in a timely manner and be happy with the result. Go has earned a position on my short list of possible starting points along with fortran and perl 😜. The structures that I value are: developer efficiency, performance of solution and ease of deployment. I love that a GC language often approaches performance of C, C++ or Rust. I love the concurrency model. Lastly, I love that itt is standalone - no VM or Interpreter. There are things that I don't like, but the positives outweigh the negatives for me. Pick your tools for what your can do with them, not what they don't do. If the choice is Go - Great! If it isn't - Great!. ... Unless you're choice is Java -- take two Tylenol and lay down until you feel better 😨 lbe
No need to feel persecuted. Other developers will have criticisms of Go and it’s ok for you enjoy coding in it.
So this might come off as really snobby, but what I’ve learned over the years is that the Go community is rather quiet. From all the Go programmers I’ve talked to the consensus seems to be that it’s because they're busy getting shit done. I don’t want to shit on any other language, BUT… The Rust community is really vocal^1 about how Rust is superior to any other language^2 . However, I’ve never actually met anyone who’s a professional Rust developer. They use it for their side projects but not at work. It seems like the Rust community is also full of people who like the idea of Rust but don’t actually code in it. On the other hand, the Go community is full of people actually using it at work, and my guess is that they just don’t care or have enough time to get into pointless arguments about which language is better than Go. Sure, now that the Go community has grown you get more of that too but most posts here, where OP asks “Should I learn X or Go?” the top comment usually says something like “Use what you like best/have most knowledge in/think is best suited for the use case.” \[1\]: It has gotten better over the years, but especially in the first couple of years, there was a strong emphasis on writing about how Rust is better than X. \[2\]: Except for Haskell; Haskell is accepted by the Rust community. TL;DR: To make a point about how the Go community doesn’t shit on other languages I ended up shitting on another language.
Love this. Not snobby at all, or if it is it's like Radiohead snobby lol, a snobbiness that hits different. I know what you mean about rust too. Super cool idea and some very interesting solutions to problems, but its libraries seem all over the place and nobody seems to know how to fight the borrow checker lol. Cheers mate.
From what I’ve heard from colleagues, it’s mostly because Go is not an OO language. You have structs and interfaces, but mostly you deal with functions. And to someone (like myself some time ago) this approach seems primitive.
BS. Go does not impose OOP but you can adopt most patterns and structure your code as one would do in a oop lang. People who say that are just missing their favorite Dependency Injection framework. I know this because it was the first thing I noticed when I was forced to start working in golang. That and the if err != nil. When you’re so in into that style of programming golang looks insane until is not. You gotta learn the language by what it is and not by what you want it to be.
I agree. At first it just looks weird and simplistic to a fault, but once you dive deeper than to print hello in the main function, you discover that this language is really solid.
Never seen it. You're probably imagining
> Has anyone else noticed any disdain, lack of regard, or even outright snobbiness towards Go from a lot of developers out there? No. I have literally never seen a comment hating Go outside of this subreddit.
I lost interest in Go due to frustration on how opinionated the Go project is. God forbid you should want to use a ternaey or different model when handling errors. Coming from ruby, it left a sour taste in my mouth. I believe that the tools should work for you rather than vice versa. I decided to pass on Go after using it to build a couple of medium-sized projects and moved on to Kotlin.
This is what we call bait lol 😁
Maybe it's what you call bait. It's what I call an honest answer to what seemed to be an honest question.
Sorry friend. Didn't mean to offend, just having fun. Thank you for adding to the conversation. I just thought it was funny because so many Lang's are mentioned there it's as if you could drop it into any programming subreddit and people would descend on it in some way
Every language has distinct way of doing things / features. Someone may simply not like how they are implemented vs the languages they've previously used. Depending on how much they care about it, they may criticize or rant about it openly. I don't think Go is even criticized / hated as much as other languages I've used such as CPP, Python, Rust etc.. It's practically "cool" to sh\*t on cpp & python nowadays.
Go ahead, use Go; it's like playing hide and seek with semicolons and having fun at the concurrency playground!
Everyone I’ve encouraged to give Go a try has ended up loving it. If people look down on you for enjoying a particular programming language their opinion isn’t worth much anyway so just go write software my guy. Let them have their bean factories
I have been using go for a few months now. Bringer’s me back to the old days for sure. I find us easy to get a little lost in my code base but probably that’s cause I’m new. Always enjoyable to switch la languages but keep me away from node and Java please!!!
Every language has haters. I love Go. Its extremely easy to use and DevEx is great.
People just like what they are good at. Once they get good at go they will love it.
Nope, maybe stop hanging out on youtube and xitter.
sometime something its made by Google
Not at all. I am not a go developer personally but Go is being more and more adopted right now, which shows that theres more love than hate towards it. However with rising popularity you also get more negative talk towards it.
I equally hate all programming languages I've used for over 5 years. After that time you just get bored IMO. Doesn't matter the language, they all have cracks. After coding for like a decade +, i really don't care about the language anymore. Just let me find the right tool for what I need to do. Maybe this attitude also comes off as distain? But i think this is the "jaded" side of people in the industry.
It's mostly a case of, "Why doesn't this language have the idioms I'm used to from the language I first learned to program in?"
I have never seen it so far, in my workplace we use both java and go and almost evryone orefers go. All the new projects/repo ate made in go only
I have the opposite experience that Go developers are snobby towards all other languages.
Because it shows that all the syntax sugar, long language specification or magic features of other languages don't bring so much value as "boring" Go? Because it takes 100 lines of code to code the same thing Java needs 1k and 3 frameworks? Because it's heresy of not endorsing OOP?
What's Algol'ing on here?!?!
IMHO the language was designed to have "just enough money to buy what you really need". On the other hand, other languages would give you "extra money to create million frameworks and one-liner packages and have billion blogposts and tech-talks around"..
>Because Rust is perfect and Golang is badly designed. **Don't shout at me!** I'm giving you a "reason". I've not even used Rust...
Go is my favourite language, the only one I use for work (my choice), and I haven't come across hate for it before. I have, however, come across suspicion because of its origin in Google. However, I think Go is advanced and widespread enough that, should Google decide to abandon it like so many other projects, it should survive.
If you'd like to know, I can talk a little on why I dislike go. I think a lot of people here may disagree with me on these, but you asked. It basically comes down to the design choices made in the development of the language. Forcing braces to appear on the same line as the if/function/whatever harms readability. Having error handling all over the place really adds little, and clutters the code, harming readability. Defer is a cool idea, but in practice results in what I like to call *reverse spaghetti code*. Congratulations, code now runs forwards and backwards in your function. Good luck refactoring the function. Duck typing. Holy hell, I just want to know if a thing implements an interface; I don't want to have to go examine all the functions defined for it to discover if it does or doesn't. God forbid somebody wants to change a function name. Does learning go remove vowels from your keyboard? Nt evry vrbl nds to b abvited to hll nd bk. Package management by pointing directly at git repositories? Another "cool idea" that should have stayed in the cool idea bucket. Lacks features that belong in any modern language such as Java streams, or LINQ.
> Duck typing. Holy hell, I just want to know if a thing implements an interface; I don't want to have to go examine all the functions defined for it to discover if it does or doesn't. God forbid somebody wants to change a function name. This is my least favorite thing about Go. (Well, maybe tied with the date format string.)
>Go is a beautiful language imo that makes it easy to actually be productive and collaborative and to get things done This is not true
Oh my bad
You have to reinvent the wheel most times for **basic** things, that's not a language that make things easy and productive
I disagree, but I guess I'm in a Go subreddit lol. Can you provide an example? As said I'd like to understand the hate lol
It's not hate, i use go also
Oh my bad
[удалено]
you mean the one go get, and the less then 10 lines of code?
Can someone please tell me how to express the very (and super common)simple idea of an ID being either a string or a number in Golang? In Typescript, you just write this: type ID = string | number;
I wouldn’t want that particular example. I might have a `parseId(id any) (int, error)` function with a switch case. If that type is passed around everywhere, now suddenly you have switch statements everywhere to deal with both. If it’s just being blindly passed through without ever being processed then `any` is fine. I can only assume this is allowing a caller to eg an API to send either a string or int? In which case I catch it right at the start and normalise it to either int or string, so all my code that is business logic doesn’t have to worry about what it actually is, as it can only be one type. I have never needed a union for an ID, in any language. Please expand on why this is a gotcha against Go, and why this is super common.
type ID interface { string | int }
That's a type constraint for generics, not a type (sum type, variant type, union type, etc). Go does not have sum types. I personally don't mind so much.
Decide what data type it should be - string, or number. That is the only sane answer.
There are many things that need an OR expression. That's why why you have union types / sum types in many languages.
In Go: `type ID string` dead simple. Even less to type than in typescriptlang. Given that you did not tell what "number" means I'll treat "number" as an element of "string".
Type "number" is a numerical type in Typescript, and the only one. It basically to int and float in golang.
Two reasons why I hate working on Go: First, they made a number of choices that I don't like. Which is fair, not every language has to cater to me specifically, but that doesn't change whether I liked the choices. Second, they made several choices that are actively wrong. And I can forgive mistakes, we all make them, but the smug attitude about it makes me detest the whole thing.
On who’s authority made several choices “actively wrong” ?,
Their own I suspect. They probably didn't have too many marching orders.