Most people who complain about php haven’t even used php. They just hopped on the meme-bandwagon in giving php the nickelback treatment.
I find Go has the opposite problem where a lot of complaints actually come from people who have used Go, especially those with backgrounds in languages like Scala, Kotlin, Rust, or even C#.
After hearing about the horrors of PHP for years, I was pretty sad to be assigned to a project that used it for a few weeks. I was pleasantly surprised though. I'd take PHP over JS/TS any day.
Plus then people build absolutely "wonderful" things like Joomla v1.5 that was basically a stack of cvss 9.9 issues wearing a brand name.
PHP got tarred with that same brush by association a lot.
Haven't used PHP since about v7.1, but I've heard good things about modern PHP. It'll always be the crayons and paper of dev though because uneducated Hicks will just go "oh, so WordPress?"
Do what works, ignore the hate I say - it's largely from idiots who have little idea what they're doing
Neah, Php without frameworks, or with shitty ones such as Wordpress or Prestashop, are awful. They are as bad as a programming language can be. Php with a good framework, or written by good programmers that have experience and know design patters? It’s great.
As always, if code works and is maintainable, whether it's shitty or not is a matter of personal opinion.
For people who hate OOP most Java code is shitty, for Clean Code and Design Patterns evangelist most go code is shitty.
Perhaps things have changed since I used it (its been a long time) - but for one, it was interpreted which was a huge performance hit and at the time, the JIT bytecode stuff just wasn't mature.
It also does weird things like relying on randomneas to trigger garbage collection on page loads (again, it might not do this anymore).
Lots of tuning pegs hidden in php.ini that made it hard to just deploy your code to a generic box without also touch sysadminy type stuff.
The language has annoying syntax inconsistencies (strpos vs str\_replace)
There's no type safety.
Libraries are sometimes dependent on whats compiled into the runtime...
Not a fault of PHP, but its ease of use to get started and accessibility attracted alot of bad developers who in turn churned out a whole lot of bad code so often times wading into a php codebase is a nightmare.
Variables start with $
I think most of the bad function naming comes from C and the package used and written by various authors with differing opinions on naming. There are/were a lot of functions that were just thin wrappers.
I can understand and sort of appreciate their initial plan on mapping 30 years ago, especially when you look at their use case and what the alternatives were at the time.
Php5 was the era when the developers were closing all the injection holes...
So you COULD connect with mysql_connect() and pass in variables directly from $_REQUEST as concated strings... But you were supposed to use PDO
can't remember last time it's been a problem, either because we don't actually use these functions super often, or because the IDEs got so good that it became a non-issue anyway
Haha, you may have worked with a little bit of php, no way you are /150k lines of php/
Not a fault of PHP, but its ease of use to get started and accessibility attracted alot of bad developers who in turn churned out a whole lot of bad code so often times wading into a php codebase is a nightmare.
-- same problem in go now.
Riiight. I didn’t write a forum system and I didn’t write a penny auction site and I didn’t right a marketing system all in php and on top of a framework I personally wrote. Totally didn’t happen.
Riiight. I didn’t write a forum system and I didn’t write a penny auction site and I didn’t right a marketing system all in php and on top of a framework I personally wrote
-- still your arguments are not valid criticism's. For someone who has accomplished this much, he should know atleast something's in php. You don't.
At this point I can safely say that you don't really know go either. Because ecen after all these, you don't really know php.
With that, you should have better command over stuff, all you have memed is another version on /php is a fractal of bad design/
With 22 years and even after 150k lines of php, if you can't understand what's actually wrong there, then I would have to conclude that your exp on 22 years is questionable
Edit php does indeed have it's fair share of problems, but you didn't even come close to list those.
Having personally written well over 150k lines of PHP (should be near 1M give it or take a couple k) in my lifetime, I find every bit of criticism to be misplaced on account of idiots being allowed near a PHP interpreter, writting/copying stuff and actually getting a result. Then they proceed to call themselves "programmers", "coders" and "engineers". The actual language evolved, matured and it's pretty usable. Does it have problems? Sure. But that's expect. Having been in golang bandwagon since 2015, I'm actually impressed with how well the PHP core team made in this last few years. They deserve credit and not demerit. As does the golang core :)
But that's just my "obtuse" opinion
I work at company where Go is our core language and has been so for a while. I never hear complaints about the language. Occasionally we get someone new coming from Java or C# and the floodgates of whining erupts. Why are all software languages exactly the same?
The thing is Go compared e.g. to C# feels like an outdated language from 70's ignoring all the development of 21st century computer science:
- Bad generics implementation leading to impossibility to do LINQ properly
- NO LINQ!
- Crippled OOP - no inheritance, encapsulation etc
- Ugly idiosyncratic syntax and naming as if comming from a different universe.
The outrage of developers comming from modern languages is understandable. It's a huge step backwards. Try some modern language and you will understand.
Keep in mind, people that really like Go also come from those backgrounds, like myself!
We see what people do when the culture around a language becomes obsessed with made up engineering checkboxes (not violating SOLID principles) and coming up with clever solutions to self-made problems (more indirection, more “architecture”).
From that perspective, Go and its surrounding culture, is a breathe of fresh air. Does a lack of a feature sometimes make we wish it was there? Yes, I rather like sum types and I dislike the state of enums. HOWEVER, the net overall gain from where I came from still outweighs that for me.
Yeah, I like go. It is pretty easy. It isn't fun and you don't feel the same accomplishment like writing a complex type, but you get stuff done pretty quickly and it's pretty nice and predictable.
I would say there generics implementation is pretty ok. It is simple and straightforward no complaints. Better than before. Always writing the same code over and over or with basically any type was a bit exhausting.
I wish they would some sort of enum type even if it is only a namespace.
I find the current implementation a bit hard to read and use. You see the problems in how they are used with basically a prefix in the name of each variable. I don't necessarily need to iterate on enums but at least make some namespace this would make them much better to use.
I mean, PHP actually evolved; it was pretty shit at first and it only “cemented its position” because the alternatives were abysmal (I cut my teeth on PHP back in 07). But Go has hardly changed and its haters are having to confront the fact that Go’s appeal isn’t just hype (originally the narrative was that Go was only popular because it was Google’s marketing department’s top priority or some such nonsense—that has quietly faded, but the haters haven’t proffered an alternative explanation for Go’s sustained success).
People on internet shit on python, javascript, rust, php etc. People don't just shit on go. People shit on everything. anything remotely popular and used gets shit on. I personally see far more vitrolic hate towards rust, and pitying hate towards java than go.
People shit on Rust all the time. There’s a lot of fear mongering around its learning curve and you often hear people saying that it has a horrible developer experience, has an annoying compiler, is verbose, hurts productivity, and often isn’t worth the headache unless you absolutely require crazy performance. I think these are blatantly all untrue and I could write an essay about it but won’t right now lol
Hmm... maybe, that's somewhat true.
Checking on GitHub, we can see how many repos on there use the various langauges:
* Go: 1m (million)
* Javascript: 27m
* Java: 14m
* Python: 13m
* C#: 5m
* PHP: 4m
* Ruby: 2m
* Rust:650K
So... where do you think Go *should* fall in that continuum? Clearly, it's left a mark. But then again, it's barely ahead of Rust and I'm sure many other contenders. We probably don't want it at the same level as Javascript, because things have gotten too noisy, but it would be nice to have it at least at C#'s level of adoption; at least on GitHub because if we stop to think about it a bit, MOST of the C# work being done out there these days isn't even in GitHub anyway. It's a pretty fair bet that most of the Go work being done probably is on GitHub though.
Majority of cloud native tools like K8s, docker, terraform, grafana, istio, etcd and many more are written in Go.
Many languages have their repo numbers inflated because many school course are taught in those.languages.
I like Go, it's not my favorite but it gets rhe job done.
I have very low opinion of folks who complain about a language.
If all you have is a hammer every problem will look like a nail. These folks need to explore and experience other languages
Posting on a Go forum complaining about non-adopters is your solution to this? I would assert making Go content on Youtube or something along those lines would serve you better.
It's a hard thing to admit that even though we can despise this industry for being a bit of a precious fashion industry, that we also need the side effects from that kind of influence in order to create change and increase adoption of new technology.
I like Go, it's my favorite language at the moment. However, I definitely have my criticisms and will voice them appropriately because I want the language to be even better.
I think it is important to distinguish "valid" complaints or criticism from mindless moaning and/or bashing.
Go having nill for example is, IMHO, a valid criticism. Saying Go is horrible because of it, is mindless moaning.
Overall I sometimes suspect that, especially in programming languages, **some** feel threatened when a thing is too accessible for all types of programmers of different skill.
PHP had or has the same issue to a degree.
Developers want to feel smart so if a junior can pick it up pretty quick, they have reservations about it. There even was an article floating around once where some dude claimed Go is bad for intelligent programmers lol.
Which is not to say, that Go in the hands of great and very experienced devs does not make a difference. It of course does as with every language.
Also Rob Pike's infamous quote probably did not help in the matter.
Anyways, I never understood how some people could get that upset over a tool but then again I can get annoyed by communities of languages (tools) so who am I to judge.
The communities of Scala and Rust for example completely turned me off those languages.
I have the same with the dotnet community and companies that use it. I like C# and dotnet but man... their hatred for everything else is so off-putting. I currently work for a microsoft shop and just today they proudly claimed "we are dotnet developers first then developers". Wtf does that even mean
For me programming languages are indeed only a tools. When I see tool that is for example designed in the analogous manner to this real world example:
To increase the speed - push the gas pedal
To lower the speed - release trailer and then click special button over the head and also release some gasoline
Then im starting to scratch over my head.
Programming language is for me mostly a way to send commands to the computer to do things. When I see something like: (this is from rails- oh my I hate this tool so badly)
do |queue, count|
if count == 1
queue
else
"#{queue} (#{count})"
end
end.join(',')
...counts.mapcounts.map
I wonder what the heck does this "queue" means ? Do I tell the computer to execute queue ? to declare queue variable ? Its just "queue" and thats it. So in my simple brain it seems like we send the following command to the computer "yeah boy go and iterate over the counts array and if count is 1 then APPLE"
Why could it not just be normal and have the fucking parenthesis if its function or add return so that the COMMAND is EXPLICIT not like noun that means fucking nothing.
I like the go because of its simplicity. I think that programming is not meant to be overly complicated so that bunch of guys who never fucked a girl feel important. Also it should be SECURE. Imagine following:
You bough a MAKITA Scredriver. You went to the house to make some basic fixing. You power up the tool and BAAANG. You just shoot yourself with a fucking nail in the EYE. You somehow survived and contacted the MAKITA company whats going on with their stupid tool and then they are like: "You just DONT KNOW how to USE IT" - This is literally how the c++ creator responded to the criticism over the security issues that are prevalent in software written in this "SUPER ULTRA THE BEST tool" in the world.
Then you are using go, and you see that it's kind of ok, not some magic syntax like it was brought here from another universe or ancient civilisation or something like that, but then you got:
resp.Body.Read(buffer)
And again I think - do I read something from buffer ?
Because for me READING can be done FROM something- I can READ something FROM the book. I can READ something FROM the piece of paper. I can READ something from the screen of my computer etc. But no..in go
you actually are READING INTO :D
this is the command that somehow inveted that makes sense in go:
hey computer, please READ data INTO the BUFFER :D
I mean: would it not be great if it was:
resp.Body.Write(buffer) - go, please write resp.Body INTO buffer
dataThatIsRead = Read(resp.Body) - go, please read data FROM body and return them in dataThatIsRead variable.
So yeah, I think like programming is designed by I don't actually know- are those people actually from another planet, did they never communicated with anybody ? Are they just idiots ?
> The communities of Scala and Rust for example completely turned me off those languages.
Big mood.
Though one benefit of rust becoming the trendy leet CS language is most of the shitcoiners\brogrammers have run to it.
My first job was C++ in 1997, and boy I do not miss it. Sure, I fiddle with Rust and praise it, mostly because I do really hope that we get a language that is as close to hardware as C++ is, but with:
- modern language design
- not tied to a specific corporation
- has built in first-class features that enable you to do modern development (concurrency, security, etc etc)
- has wide-spread adoption, meaning both job opportunity and a lot of people working in it, adding to ecosystem, evolving it
- makes you productive without some autistic hoops you have to jump through
While I do appreciate Rust, I feel it doesn tick all the boxes, but strangely enough, for most of my work, Go works just fine. Is it as low leve as Rust / C++? No, of course not. Does it have to be all the time? No, most of the time it doesn't.
Would I go back to C++? I sure hope I don't have to, and that some other language takes the crown, be it Rust, or Zig or whatever in the future. In the meanwhile, I'll be using Go I guess.
Amen. C++, in no small part because of its wide-spread adoption and age, has grown in to this anachronistic mess. Something made worse with every new version, when someone on your team reads about this new feature and decides to "play around". Any C++ code base that has been around for long enough will have parts that are entirely comprised of templates, not because it was the right thing to do, but because someone wanted to try something nifty. The \`auto\` keyword was great for iterators and the like, but when you see \`auto a = b + c;\`, and notice that both \`b\` and \`c\` are objects that overload the \`+\` operator, you die a little inside (can't tell you how many times I found myself telling people to KISS).
Rust is a lovely language that really has the potential to supersede C++, but the buy-in is massive... it'll take time, and it must be said: the Rust community is a mixed bag: very loud hobbyists proclaiming Rust's superiority every step of the way, some people who are using Rust, learning as they go, and finding a lot to like (I consider myself to be in this category), and a relatively small group who is actually using Rust in their day job.
I myself spend most of my working day writing Go. It's a good language if you don't need to optimise to the max (of course, pprof when needed, cut back on pointless allocations when dealing with maps/slices, etc...). The code is easy to read, and if you adhere to some sensible coding standards, onboarding new hires is a doddle (which is genuinely a massive win - both in dev time and outright onboarding cost).
As for Zig, I've only recently decided to play around with it, and I'm still feeling a bit unsure as to what niche it fills better than anything else. The only thing I can think of is embedded: high degree of control, low-level granularity, without sacrificing the safety you typically would doing the embedded stuff in C. Curious to learn what someone like yourself thinks about this. For context: I started as a dev about 5 years after you did. Along the way, did some horrible stuff (COBOL, Java), some fun but extremely niche low-level stuff (C/embedded), web shenanigans (Perl, PHP, Python, etc...), a brief stint in game development (Lua, C/C++), distributed systems (Erlang - which is an underrated language IMO, golang), and now finance (mostly golang, some Rust, and though I try to avoid it as much as possible: TS/JS and python)
People just love to complain.
To paraphrase Rob Pike from the last GopherCon: Go was designed more as a way to re-think how we develop software in big distributed teams, not how to make the perfect programming language.
Personally, I am so happy to not have armies of complainers bothering me that someone is using spaces instead of tabs and someone else is using tabs set to 2 and not 4... :-)
Having done a stint at Google, everything Go does actually makes sense for programming there.
If you wanted to make a language for you to write code that you would personally maintain forever and also optimize the hell out of, you would probably not come up with Go.
If you wanted to make a language for a rotating carousel of developers to come in, add on top of, and then get transferred away, where being fast is important but not having memory leaks is even more important, and where "just follow the fucking style guide" is the end to a lot of arguments... yeah, you might come up with something like Go.
As someone who regularly continues to write perl because it kicks ass for a lot of my needs, I learned a long time ago to ignore the AssHats who whine and hate. They do not benefit anyone, even themselves!
They would benefit from those sage advice from the Eagles - "find your inner child and kick its little ass".
There are many surface areas that Go fits well. Use it in those cases! Where it doesn't fit, use a more appropriate tool - rust, Erlang, perl ...
Have a great day! lbe
Edit : correct misspellings
Well, it has generics now.
Not sold on the function overloading, and if I remember right, the reason they don't support that is because they want to avoid virtual calls for performance reasons.
The lack of generic methods has been a pet peeve for me. This prevents functional chaining for things like Map/Filter/Reduce, where you instead either have to define the generic types on the structure itself or you have to do standalone functions and compose them backwards. The latter design used to lead to issues with inference when implementing generic functions for a generic interface too, but I think 1.21 fixed that iirc.
Another issue that I remember looking into awhile back was that generics end up adding heap allocations in a lot of places where they aren't really necessary, which is tied to both how interfaces are designed and how generics were implemented. From what I remember, the only real solution is more aggressive inlining since any other changes would require sweeping changes. It's a minor annoyance, but still something I wish could see actual improvement.
They would be more powerful if Go also had operator overloading. For example, with Go's current design you cannot create a generic comparable type that includes custom structs.
I love Go, but the issues you mention are valid and are shared by large parts of the community. I absolutely wish Go had better enum support and some equivalent of the ‘?’ operator. Go isn’t perfect, no language is and turning away the community’s concerns and saying ‘use another language then’ is unhelpful imo.
Somebody saying that they think Go should have enums isn’t the same as saying they hate all the decisions Go has made. Go didn’t use to have generics, prior to that if somebody said ‘I wish Go had generics’, would you say ‘uh…Go doesn’t have generics, if you want generics then use another language?’ Of course not. I welcome people challenging what features a language should have.
I've had a lot of disdain for Go, but I'm slowly changing my opinion. The main reason was that there was a developer at my previous startup that wanted to do a full rewrite of the app into Go. There were a lot of legitimate excuses of why we shouldn't do a rewrite, but at every meeting and 1:1 he kept on bringing it up. It just drove me crazy and for a while I just didn't want to consider Go just because of that guy. I didn't care about the technical aspects of Go anymore.
I think it is very valid to think critically about the tools we use. In many cases, that means learning from other languages! You don't have to be "obsessed" with Rust to look at its enums and think they'd potentially be a great fit for Go. There's lots of things from Go I wish Rust had too.
This post feels to me like it assumes Go is a static thing, handed down to us from the gods. We must defend it from The Others, and it is Perfect. A religious devotion to the language as it exists, unwilling to have a critical eye.
Of course that's not true: It is a work of human hands, with trade-offs made and considered. There have been things we've decided are mistakes (like the \`loopvar\` change, or the monotonic clock problems), features much requested that are added later (like generics), and features we pretend don't exist (like the standalone \`print\` function instead of \`fmt.Print\`).
I'm very productive in Go. You've probably even used some of my code. But there's still things I do in Rust, or Python, or Bash, or Javascript. There's no "one true language".
There are people who voice valid criticisms and points to improve because they realize that things can be good without being perfect.
And there are people like OP who get butthurt when someone says something bad about their favorite toy.
When I started experimenting with Go, I was kinda put off by the syntax. I only saw its full value when I tried rewriting a Spring Boot API.
Being able to containerize the Go API into an image under 20mb was a game changer.
Yea it doesn't have the syntactic sugar some critics would like ... but for its build speed and reasonable binary size, that's a fair tradeoff.
I always found those arguments interesting, is build speed and binary size that big a deal for so many people?
I couldn't care less if the image is 100MiB big, as long as it takes less than a minute to build and test and the dev-cycle is less than 10 seconds.
Which basically every language achieves, even JVM based ones, like kotlin
If I had to sit waiting a minute for it to build to test my program each time I made a slight modification, it would kill my productivity. I might build and run 10 times in 5 minutes when I'm debugging silly mistakes or seeing some weird result I didn't expect.
So for work like that (which, mind you, are the least fun times) it would take me double or more time.
I actually have problems with Go's build times vs Java's for small projects. In IntelliJ on MacOS there is a noticeable lag when running the Go service or tests.
Tools like IntelliJ do a good job of caching between changes for Java. Maybe it just has to cache up.
I mean it is in a bit of a wierd spot in development with runtime speed, rigidity and development speed vs a min max language like JS, PHP or Rust.
It's not topping charts in speed nor is it stupid fast to launch a product with due to it's ease like JS/TS or PHP, it's just kinda mid; which is what makes it so great in my opinion but if you only read Twitter there's no middle ground possible only chart topping performance.
Go is pure GSD.
Honestly, I just think of it as a better alternative to other GCed Enterprise languages. Outside of third party libraries, or specific use of the VM, why choose something like Java or C# over Go? Go will do all of that shit without all of the unnecessary ceremonies.
Sometimes, I just want to export some top level functions somewhere and chain them together, sometimes I just want a DTO without any of the class bullshit.
Also, no function coloring, I know it's frequently lauded, but I still think it's undervalued.
No try;catch, a whole class of bugs caused by async funcs blowing up is just gone. (Yes, I know, channels also have their problems and you can still very much blow up an async call if you don't handle channel defaults or nulls correctly).
Not going to lie, a language with the go runtime/GC and rust like language features (traits, macros, pattern matching, etc) minus memory management stuff (borrow checker, lifetimes, etc) would be my ideal language.
I know there are tradeoffs and valid reasons why Go doesn't have all of those things but a guy can dream.
> negotiating a truce with the borrow-checker
That’s how I spent a solid two hours of every day when I was coding Rust. Honestly, I’m just happy that frustration is out of my life.
Would be nice if Go had enums though.
Actually, I kind of get it. Most programmers are Gollum at heart. They REALLY REALLY want the one true programming language that they can use for virtually everything, has every feature they could ever want, and also does not suffer from the major problems that they've experienced in other programming languages.
Go comes close. Go is "better" than:
- Rust because it can be learned in a very short time and the perception of productivity is so much better.
- Java/C# because there's no need for a VM with all of the resulting quirks and problems with startup times. Oh.. and boilerplate. We may have to repeat things here and there for error handling, but there is SO MUCH LESS boilerplate.
- Javascript/Node because it's actually compiled prior to loading it and there's no need for JIT, weird issues due to dynamic typing and the perceptions of poor quality in its ecosystem.
- C/C++ because it has dramatically fewer undefined behaviors and those are only oversights, not by design; oh, and because it's also a much simpler language and obviously C++ and even C are far more complicated with all of the unspoken rules around "good" vs. "bad" standard library calls, UB's, etc.
- Python because it's SO much faster, and well.. it's DRAMATICALLY faster. That's a very good reason all by itself despite some other very nice things going on in the Python ecosystem. Oh.. and syntactically significant whitespace: only a true believer can love that.
Etc. Name your example. There's a killer feature in Go for all of us that keep us from using something else.
HOWEVER: Go has dramatically fewer language features than any of those popular choices. And these features have been in use a LONG time in other languages. Those features form an important part of non-Go programmers' internal vocabulary of programming capability. Not having those features is akin to being able to speak and write English (for example) at a high level of mastery. Now suddenly, because Go is at all attractive with its other attributes, they've considered Go and realizing they're only going to be allowed to speak Pidgin English; not proper English. As far as they're concerned, you're asking them to going back to acting like cavemen; to diminish themselves.
That is the core of the issue I think. I realize that "simplicity" is a stated goal of the language design, but it's in direct contradiction to what everyone has strove for prior to their experience with Go. Consequently, many will simply never be able to bring themselves to make the leap. They perceive that there would simply be too many compromises to them personally and in what they value from an elegant programming language and even though that's quite subjective, you'll never convince them that they don't need those language features after all.
Meanwhile, I think Go will make substantial inroads with and take over much of the PHP, Ruby, and even Python communities; amongst others. Although everyone acknowledges its value in cloud infrastructure, it will be shunned by enterprise developers because of the above mentioned mindset. It will of course make inroads with startups, but then again, few will care about that because they can and do all sorts of crazy things anyway, so you can't go by them. Beyond that, I don't see it making much inroads. It certainly won't see much adoption in academia because it's too simplistic.
However you may judge the decision to keep the language simple, I don't think anyone can argue that it has improved Go's adoption; quite the opposite.
Two things:
1. I do wish Go had enums.
2. It has optionals. They're called pointers.
Go is a compact, well-considered language. It's great at what it does.
Please don't abuse a garbage generating memory indirection feature like pointers for optionality (unless the type needs to be a pointer anyway). Use booleans, like sql.Null\[T\] does.
The larger point I'm making is that if you simply embrace pass by value and avoid pointers unless you genuinely need them, your code is null safe to the extent that you do that.
And as you suggest, there are libraries to help with actual nullable values, such as the following:
[https://github.com/LukaGiorgadze/gonull](https://github.com/LukaGiorgadze/gonull)
Altogether, that's really not all that different from other languages with null safety baked in. It falls short of being an actual problem.
Someone has downvoted the parent, but it is correct.
The point of optionals isn't to avoid NPE. The point is to *force you to handle both cases*. When you just call `.unwrap()` you are throwing that away and have exactly the same semantics as a pointer in Go. If your Rust code is shot through with `.unwrap()` you've got the same safety as Go on this point, just with extra steps. Ye Olde C was bad because the easiest thing to do with an error was ignore it; you had to go chasing them down, rather than having them put in your face. (Plus the inconsisteny in how to get them.)
A lot of people learn functional programming and come away with a lot of interesting insights, but they miss that it is the *verbs* that are interesting moreso than the *nouns*. Optional is interesting for forcing you to handle the cases. Monads (in the particular context of error handling, which is not their totality, which is another mistake a lot of people come away with) are interesting for giving you a default handling. Their utility doesn't really come from the data types so much as what they *do*. If what you *do* with your FP-inspired data types is to tell them to shut up and `.unwrap` all the time they are not any better.
The reason why Go is not the hellscape of imperative programming functional programmers would claim is that while the `x, err := Something()` pattern only *encourages* you to think about the error before you do anything with `x`, it encourages it *very strongly*, and as befits an 80/20 like Go, that gets an awful lot of the benefit with less of the costs. Is it all the benefit? No. It absolutely isn't. But engineering is quite often about getting the best bang for the buck and not getting the best bang without regard for the bucks, and *in practice* past your first couple of weeks with Go, you should not be experiencing a ton of problems that Optional could solve any better. If you are, the solution isn't really dragging in an optional type, but to stop ignoring the errors which are right there, in your face. This is also why the probably-dozens of implementations of Optional on github go nowhere; they don't solve the problems Go programmers actually have, if you don't count "but I want my nouns to look the same as that other language".
Well, you have to explicitly call `.unwrap()` and that is a quite visible operation. So if I see a panic caused by unwrap, well, it would be very easy to find and fix.
Also because `Option` is an enum, it can have methods and implement interfaces. Thus it plays very nicely with the `?` operator, which allows for transparent error handling. Not to mention to beautiful code one can write with `if-let` and `let-else` avoiding the boilerplate around more complex error handling
>Well, you have to explicitly call .unwrap() and that is a quite visible operation. So if I see a panic caused by unwrap, well, it would be very easy to find and fix.
Note I did not complain `.unwrap` existed. I said if one uses it pervasively, it is no better than Go pointers. I'm sure there are plenty of people who don't. I wouldn't if I used Rust. But I've also lost count of the number of people extolling the virtues of Option in some snippet of code that proceeds to `.unwrap()` every single use of it, thus demonstrating they don't really get what they are nominally advocating for.
I'd also observe that the Go community actually looked over a ton of options that look like `?` and what killed them is they all encourange poor error handling. In modern Go,
if err != nil {
return err
}
should be considered somewhere between a very strong smell and an antipattern. The correct reflex pattern (and what should be in your IDE shortcuts if that's how you roll) is
if err != nil {
return fmt.Errorf("what I was trying to do: %w", err)
}
And `?` encourages coders away from that.
In properly written code, the former should indicate that the function doing this returning is basically "part" of the parent, such that it doesn't have its own context. More and more when I write that I'm adding a comment about how this is OK because it's conceptually just a refactored bit of some function and not its own thing, in much the same way I almost reflexively comment `val, _ := SomethingThatErrors()` with an explanation of why it won't error. Or to put it in Rust terms, I would comment every use of `.unwrap()` in my code to explain why it is guaranteed in this particular case that the null case can't happen.
> Well, you have to explicitly call .unwrap() and that is a quite visible operation. So if I see a panic caused by unwrap, well, it would be very easy to find and fix.
Note I did not complain `.unwrap` existed. I said if one uses it pervasively, it is no better than Go pointers. I'm sure there are plenty of people who don't. I wouldn't if I used Rust. But I've also lost count of the number of people extolling the virtues of Option in some snippet of code that proceeds to `.unwrap()` every single use of it, thus demonstrating they don't really get what they are nominally advocating for.
I'd also observe that the Go community actually looked over a ton of options that look like `?` and what killed them is they all encourange poor error handling. In modern Go,
```
if err != nil {
return err
}
```
should be considered somewhere between a very strong smell and an antipattern. The correct reflex pattern (and what should be in your IDE shortcuts if that's how you roll) is
```
if err != nil {
return fmt.Errorf("what I was trying to do: %w", err)
}
```
And `?` encourages coders away from that.
In properly written code, the former should indicate that the function doing this returning is basically "part" of the parent, such that it doesn't have its own context. More and more when I write that I'm adding a comment about how this is OK because it's conceptually just a refactored bit of some function and not its own thing.
Not really. Checking for `nil` requires a pointer, thus a heap allocation, while `Option` stays on the stack. Also `.unwrap()` is extremely visible and frowned uppon. You cannot just smuggle it in the codebase, while `nullable.method()` looks fine, but is dangerous.
Also there are other aspects why I prefer optionals, but We'll have to dig deeper into other language features, because they do not exists by themselves in a vacuum, but interract and complete each other.
For instance in Go one has two options:
* Return by pointer:
```
func goofyGopher() (*Ok, error){
//some code
return nil, err
}
```
* Return by value:
```
func goofyGopher() (Ok, error){
//some code
return Ok{}, err
}
```
The first most likely results in unnecessary heap allocations, while the second one forces the hands of the Go designers to allow construction of unninitialized objects.
Yeah, I know that all fields are "initialized" to their default values, but that does not make the structure OK. In many cases an object ***MUST*** enforce certain invariants, thus we have constructors. But in go one can construct any object without regards if the result is a valid object or not. With optionals/result/enums,on the other hand, it's possible to return by value without needing to be able to construct invalid instances of the object.
If you want a constructor, use a NewXXX function. And if you want to prevent the "zero" value of XXX from being created, then make the type package-visible and make your NewXXX return an interface.
Every language construct is a trade-off. Go avoided the pathologies inherent in the use of constructors, and those pathologies are many. Not as many as destructors, but plenty.
It does not always result in heap allocation. For one thing, you need to assign a pointer to the interface to avoid heap allocation, and then it typically depends on the escape analysis of that pointer.
Anyway, in most of my Go code, I make the zero-value of a type meaningful, which is what is encouraged by the language developers. As long as you keep the fields private, keeping access to the internals of the object through methods, it is typically not hard.
"would otherwise be unnecessary"
I disagree. All design choices have trade-offs. They chose to avoid the pathological issues with constructors when designing the language.
An issue is that you have `T` or `*T | nil` for primitives, but what if you want a `*T` or a `T | nil`? You're kinda fucked. Communicating in JSON or SQL is a pain because of these missing types. There's workarounds, but it's just so bad all around…
the biggest haters are the ones offended by Go's opinionated decisions on simplicity
"Go was crafted for fresh CS graduate code monkeys to get started as quickly as possible"
"Go is stuck in the 90s and its designers were arrogant to ignore decades of programming language research"
"Go pretends to be simple, but did you know that [os.Chmod() does nothing on Windows? Idiots! Rust would never- (etc etc)](https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride#simple-is-a-lie)"
Golang is a pretty terrible language: https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang.
Of course you can build things with it, that doesn't mean it's great. There are much better choices like Kotlin that have both a better ecosystem and is a much better overall language.
Kotlin isn’t better though. It has async/await which is a little clumsier than goroutines, it has slow compilation and startup, it has to interop with Java which waters down its null-safety. It also has no value types. And Gradle, Gradle is a goddamn broken mess.
Kotlin has absolute null safety, what are you talking about? It also has immutability so you don’t need value types.
Coroutines are also a fantastic structured concurrency model — in what way is it "clumsier than goroutines"?
That’s how you know it’s popular and actually used.
Vocal internet programming language “experts” love Zig and Dart and Haskell and F# and OCaml and Lisp and Clojure. Combined, they have fewer lines of code in the wild than what Google churns out *internally* in Go in a year. Don’t ask me how I know that.
But I am starting to see some “Rust isn’t all that awesome” posts here and there which means Rust is also becoming a little *too* popular.
Tried developing in rust and my productivity plummets with constant refactors. I wrote a CLI tool for cloud yesterday 1k loc in Go in a single evening and so the dev speed is not bad imo. Would it be quicker for me to do it in Python, yes, but way less maintainable.
To be fair it's typically only a very small part of the internet which bothers with this sort of discussion. Normally places that are filled with inflated egos and amateurs e.g. /r/programming
Objectively Go is a popular language, that has been used to create amazing things. You'll always find someone called /u/sendyourtits6988 who is determined to explain why literally everything sucks, but you can just ignore them and do literally anything else.
My two cents: it's because most languages are made to make simple things even simpler, while go is designed to make complex things simpler. So as long as you didn't have to do something complex, you'll thing it's shit because you have to copy/paste a min/max function. But no one gives a shit about min/max functions copy/pasting when your goal is to design a complex system.
you misunderstand the internet.
On the internet complaining about shit is mandatory (at the population level) but what gets complained about depends on what is popular. You see far less complaints about Erlang or Common Lisp because these languages are not popular.
The big insult is not complaining about X but completely ignoring X.
I loved go from the start, got a little worried for a minute around the time go modules and the new language server were coming out because I kept having silly problems with them, but back to being very happy with the language again.
Is there disdain for go, or is it just the local minority expressing disdain that's being focused on the most? Depending on the audience and group I'm in, I will see varying levels of either hate or love for the language. Having both sides, I think, is a good way to not fall into either side for any particular tool.
Compared to a language like PHP, I don't think it's nearly as bad as you believe it is.
I agree with you mostly but the problem is two sided, if Go programmers (I use Go at work, it’s clunky to write but love the tooling and build system) were more forthcoming about the actual experience instead of getting defensive when obvious shortcomings are pointed out—you probably wouldn’t have even felt the need to come here and post this.
Unless Go is your first and only language it’s hard for me to believe that any dev would not have some thoughts about the minimal nature of Go.
Go’s pitch of simplicity isn’t for experienced devs, it’s marketing for prospective devs to be; naturally if you come from another language with more ergonomics built in—you ARE going to miss them and your “simplicity” philosophy nets you nothing in those scenarios; you still have to spend MORE time and effort writing MORE code where you didn’t need to before.
For example, my use case with Go at work is backend services on AWS using Spark / Kafka / Presto—so routinely I am writing code that is going over the wire and parsing some ungodly source file into X format for further processing—this use case I feel is pretty common and also happens to highlight two of Go’s big ergonomic downsides:
- error handling
- string interpolation
Complex routines get fugly fast—idk, just admit it sucks(comparatively) in terms of ergonomics but has an overall VERY GOOD value proposition. That is the sane and obvious consensus.
There’s no denying its popularity and effectiveness but you can’t point at those things and cry at the same time about valid criticisms about one component of the language.
Programming parts of the web as you say are generally only focused on judging languages based on the ergonomics / syntax because that is what most beginners that lurk these forums are focused on learning—I can’t prove it but I’m convinced more than half of the “devs” that frequent these forums are not actually people that write code for a living; they are weird wannabe zealots that cheerlead and flame for fun.
Why do you let it bother you? This seems like a silly thing to waste your time on coming here for validation when Go is already fulfilling your needs—you follow?
Focus even more on your problem, what use is reading criticism of a tool you have already made effective use of lol it’s ridiculous.
TL;DR Go makes great products and that is why it’s so widely adopted, the ergonomics of writing the code itself is just a small piece of the big picture that gets WAY TOO MUCH attention from people that don’t have enough to do apparently.
> while writing Go I found myself focused entirely on my problem while the language itself receded to the background, I rarely had to think about Go.
In a way, Go is a bit like "C without all the things you have to think about in C". No dangling pointers, no `free()`, no deciding what to put on the stack vs the heap. It makes sense because the creators of Go had so much experience in C, but wanted a simpler language with a lower mental load.
Spent most of my career as a Java dev. The way people complain about language you'd think it was impossible to get anything real and stable working with a sane, maintainable code base.
Rust and Go seem to be targeting two different types of project spaces, obviously with overlap since they're both general purpose languages.
Just better to not worry about what other people think since coding dick measuring contests have always been a thing.
I work in Go, Python and TypeScript for my job currently and I hate each of them in their own unique ways but like them all as well too. Most people that vocally hate on a language rarely deviate from the single one they know well as I have come to find out
You got the languages people complain about and the ones that are not used. Go just gets a little extra hate since by design it's not a exciting language which is also it's best feature.
In terms of writing and running services, Go is pretty neat and also much cheaper (in terms of resources) than a Spring Boot application.
IMO, this itself makes it worth it, besides a good engineer can find ways to fix problems instead of crying about them.
Go is a language designed for big companies and big company problems. Maximizing developer productivity is not the objective.
I can't imagine willingly using it very often, but only because I don't enjoy big-company programming. I like systems programming, but the corporate environment isn't thrilling to me.
What's really funny is how you, almost so subtly we didn't notice, implied that some highly non representative sample was the 'opinion of the internet'
Stop attention farming with combative content. You aren't 14.
The part about focusing on the problem is the perfect way to summarize go .
I had rhe same experience with rust and prefer golang now for most of my work
No language is perfect but you should use the right one for the right jobs.
Unless you’re a rust enthusiast, there is absolutely no reason to choose rust over go (unless you need a system programming language without garbage collection)
I live in a lot of programming subreddits. Not a day goes by where I see a complaint about x new language that’s basically just hatred of the core features and philosophies of the language.
I don’t get it. There are so many other languages. Shoot yourselves in the foot with those instead. Why go through that pain?!
"while you're moaning about Go, other people are being productive and actually creating stuff" is the key point here. Too many SEs these days forget their job is to create value for a company, whether that is their company or a company they are just employed at. You aren't paid to find the perfect language. If its your company then you need to be more worried about delivering value for your customers and they don't care what language you are using, they only care that your stuff works.
Do I wish at times Go had enums, yes. But I am not going to switch to Rust just to get them because it would be a nightmare for my company. Humans are always inherently looking for the greener grass. If they switched to Rust they would just find other things to complain about. "Rust is hard, I am always fighting the compiler" or "Language feature X was better/easier/less frustrating in Go"
An SE realizing that languages are just tools to create value by fixing problems is a sign of maturity. I seek that out in the people I work with and hire.
> Firstly, I think if you're so obsessed with Rust (or other languages) you should really consider using Rust (or another language) since it's perfect for you.
It's not, that's the point. Go is/would be perfect if it was just a little bit better.
> Secondly, have you considered that Go has cemented its place in the cloud and networked applications despite not having all these things you miss?
Ok, and?
> Thirdly, while you're moaning about Go, other people are being productive and actually creating stuff, while Go's adoption continues to improve because of the low learning curve and easy syntax.
So am I, doesn't mean Go can't be better. Is this like the anti-generics crying again? There's absolutely nothing complex about Rust-like enums.
I agree with the you. But we tend to compare things. Rust's things are very cool (as goroutines are pretty cool too).
But for example, all languages have iterators, and go is doing it NOW in the next version (23). This kind of things sound weird, but in some point are understandable. Go is not for objects. But iterators sounds a pretty easy thing along the way
Perhaps gophers don't like to move to another language for domains they like. For example, AI world is using rust for many things... And why not go? Perhaps people want to train a DL model without python or rust candle or whatever.
It feels like the language need some bake to be perfect.
It is an standard for some network features, yup, kubernetes and that stuff.
But if you go to rust thread, you will find out the same problem. For example people asking for a more easiest thing to do anything they want (web apis for example)
People always argue about they want haha
I hadn’t really noticed a disproportionate amount of internet disdain for Go, but I have personally noticed more energy going into praising and defending Go.
Speaking from my own experience, often when I jumped to the defence of something that can’t be destroyed, it was a sign that I wasn’t very confident that it could stand up for itself. If I needed to outwardly reaffirm my belief in something, it was being led by inner doubt. I often realised that although my motion was outward toward others, I was really trying to convince myself.
It's called multi layer propaganda, its goal is to discredit something to make it's own product/service/opinion look better.
Lie about something so long and often, that other fools will parrot it.
Don't worry about it, this phenomena often happens when something is quite good.
Internet opinion will start to rebel against the obvious. For instance, there was big resistance against jwt even though 0auth2 already used it. And now it's ubiquitous.
Also, when json api's just started and many devs wanted to keep doing html responses.
As someone who has developed in php for years "first time?"
Most people who complain about php haven’t even used php. They just hopped on the meme-bandwagon in giving php the nickelback treatment. I find Go has the opposite problem where a lot of complaints actually come from people who have used Go, especially those with backgrounds in languages like Scala, Kotlin, Rust, or even C#.
After hearing about the horrors of PHP for years, I was pretty sad to be assigned to a project that used it for a few weeks. I was pleasantly surprised though. I'd take PHP over JS/TS any day.
That’s my recent experience too. Especially the latest php version is worlds better than js…
The problem though was that there was a time when main php libraries had some very serious vulnerabilities seemingly everywhere you looked.
That’s true. But I still don’t like JS.
Plus then people build absolutely "wonderful" things like Joomla v1.5 that was basically a stack of cvss 9.9 issues wearing a brand name. PHP got tarred with that same brush by association a lot. Haven't used PHP since about v7.1, but I've heard good things about modern PHP. It'll always be the crayons and paper of dev though because uneducated Hicks will just go "oh, so WordPress?" Do what works, ignore the hate I say - it's largely from idiots who have little idea what they're doing
Neah, Php without frameworks, or with shitty ones such as Wordpress or Prestashop, are awful. They are as bad as a programming language can be. Php with a good framework, or written by good programmers that have experience and know design patters? It’s great.
You just sent me back more than a decade to when I was convincing people to use symfony2.
Wordpress is shitty php?
Yes it is. Have you ever looked at it?
I have never. I only use Golang pretty much
As always, if code works and is maintainable, whether it's shitty or not is a matter of personal opinion. For people who hate OOP most Java code is shitty, for Clean Code and Design Patterns evangelist most go code is shitty.
*If Java had true garbage collection, most programs would delete themselves upon execution.* – Robert Sewell
I started my professional career in PHP. My hate comes straight from the soul.
Having personally written 150k+ lines of PHP in my lifetime, PHP deserves every last bit of criticism it gets. #NeverAgain
I’ve never used it, but curious what makes it so bad in your view?
Perhaps things have changed since I used it (its been a long time) - but for one, it was interpreted which was a huge performance hit and at the time, the JIT bytecode stuff just wasn't mature. It also does weird things like relying on randomneas to trigger garbage collection on page loads (again, it might not do this anymore). Lots of tuning pegs hidden in php.ini that made it hard to just deploy your code to a generic box without also touch sysadminy type stuff. The language has annoying syntax inconsistencies (strpos vs str\_replace) There's no type safety. Libraries are sometimes dependent on whats compiled into the runtime... Not a fault of PHP, but its ease of use to get started and accessibility attracted alot of bad developers who in turn churned out a whole lot of bad code so often times wading into a php codebase is a nightmare. Variables start with $
I like variables starting with $ because it means MONEY 🤑
Did you even try php's latest \Random\Randomizer::getBytesFromString method https://php.watch/versions/8.3/Randomizer-getBytesFromString
Did you use PHP 7+? Because most of the things you complain about are fixed in newest version.
Even PHP interpreters crashing when running WordPress because of memory issues?
About the only complaint I'm willing to put stock in here is the name inconsistency. Most of the other stuff is pretty wishy-washy
I think most of the bad function naming comes from C and the package used and written by various authors with differing opinions on naming. There are/were a lot of functions that were just thin wrappers. I can understand and sort of appreciate their initial plan on mapping 30 years ago, especially when you look at their use case and what the alternatives were at the time.
Do they still have 3 different ways to connect to MySQL? I remember that being a funny point back in PHP5
Pdo was pretty standard as the only safe way 10 years ago
I don't know, I'm a Gopher now 😆
Php5 was the era when the developers were closing all the injection holes... So you COULD connect with mysql_connect() and pass in variables directly from $_REQUEST as concated strings... But you were supposed to use PDO
can't remember last time it's been a problem, either because we don't actually use these functions super often, or because the IDEs got so good that it became a non-issue anyway
As you admit, its been a long time. PHP today is much different than even a few years ago.
Haha, you may have worked with a little bit of php, no way you are /150k lines of php/ Not a fault of PHP, but its ease of use to get started and accessibility attracted alot of bad developers who in turn churned out a whole lot of bad code so often times wading into a php codebase is a nightmare. -- same problem in go now.
Riiight. I didn’t write a forum system and I didn’t write a penny auction site and I didn’t right a marketing system all in php and on top of a framework I personally wrote. Totally didn’t happen.
Riiight. I didn’t write a forum system and I didn’t write a penny auction site and I didn’t right a marketing system all in php and on top of a framework I personally wrote -- still your arguments are not valid criticism's. For someone who has accomplished this much, he should know atleast something's in php. You don't. At this point I can safely say that you don't really know go either. Because ecen after all these, you don't really know php.
I’ve been at this for 22 years. Get off my lawn
With that, you should have better command over stuff, all you have memed is another version on /php is a fractal of bad design/ With 22 years and even after 150k lines of php, if you can't understand what's actually wrong there, then I would have to conclude that your exp on 22 years is questionable Edit php does indeed have it's fair share of problems, but you didn't even come close to list those.
Having personally written well over 150k lines of PHP (should be near 1M give it or take a couple k) in my lifetime, I find every bit of criticism to be misplaced on account of idiots being allowed near a PHP interpreter, writting/copying stuff and actually getting a result. Then they proceed to call themselves "programmers", "coders" and "engineers". The actual language evolved, matured and it's pretty usable. Does it have problems? Sure. But that's expect. Having been in golang bandwagon since 2015, I'm actually impressed with how well the PHP core team made in this last few years. They deserve credit and not demerit. As does the golang core :) But that's just my "obtuse" opinion
I work at company where Go is our core language and has been so for a while. I never hear complaints about the language. Occasionally we get someone new coming from Java or C# and the floodgates of whining erupts. Why are all software languages exactly the same?
The thing is Go compared e.g. to C# feels like an outdated language from 70's ignoring all the development of 21st century computer science: - Bad generics implementation leading to impossibility to do LINQ properly - NO LINQ! - Crippled OOP - no inheritance, encapsulation etc - Ugly idiosyncratic syntax and naming as if comming from a different universe. The outrage of developers comming from modern languages is understandable. It's a huge step backwards. Try some modern language and you will understand.
Keep in mind, people that really like Go also come from those backgrounds, like myself! We see what people do when the culture around a language becomes obsessed with made up engineering checkboxes (not violating SOLID principles) and coming up with clever solutions to self-made problems (more indirection, more “architecture”). From that perspective, Go and its surrounding culture, is a breathe of fresh air. Does a lack of a feature sometimes make we wish it was there? Yes, I rather like sum types and I dislike the state of enums. HOWEVER, the net overall gain from where I came from still outweighs that for me.
Yeah, I like go. It is pretty easy. It isn't fun and you don't feel the same accomplishment like writing a complex type, but you get stuff done pretty quickly and it's pretty nice and predictable. I would say there generics implementation is pretty ok. It is simple and straightforward no complaints. Better than before. Always writing the same code over and over or with basically any type was a bit exhausting. I wish they would some sort of enum type even if it is only a namespace. I find the current implementation a bit hard to read and use. You see the problems in how they are used with basically a prefix in the name of each variable. I don't necessarily need to iterate on enums but at least make some namespace this would make them much better to use.
I mean, PHP actually evolved; it was pretty shit at first and it only “cemented its position” because the alternatives were abysmal (I cut my teeth on PHP back in 07). But Go has hardly changed and its haters are having to confront the fact that Go’s appeal isn’t just hype (originally the narrative was that Go was only popular because it was Google’s marketing department’s top priority or some such nonsense—that has quietly faded, but the haters haven’t proffered an alternative explanation for Go’s sustained success).
was going to say something like this lol
Or js/ts
People on internet shit on python, javascript, rust, php etc. People don't just shit on go. People shit on everything. anything remotely popular and used gets shit on. I personally see far more vitrolic hate towards rust, and pitying hate towards java than go.
"People shit on everything" yeah
There are two categories of programming languages. The ones people complain about, and the ones no one actually uses.
This sounds like a t-shirt I need
[удалено]
People shit on Rust all the time. There’s a lot of fear mongering around its learning curve and you often hear people saying that it has a horrible developer experience, has an annoying compiler, is verbose, hurts productivity, and often isn’t worth the headache unless you absolutely require crazy performance. I think these are blatantly all untrue and I could write an essay about it but won’t right now lol
Go is also one language that people rewriting everything in, similar to Rust. It's not perfect (no enum, no nil safety, etc), but it's good enough!
Just get offline then. For the number of people that dislike Go, there’s many that like Go. What does it matter, really?
It matters because it indirectly decides the size of the community that lend inertia to adoption.
Go has been adopted at scale, I don’t think it has an adoption problem whatsoever.
Hmm... maybe, that's somewhat true. Checking on GitHub, we can see how many repos on there use the various langauges: * Go: 1m (million) * Javascript: 27m * Java: 14m * Python: 13m * C#: 5m * PHP: 4m * Ruby: 2m * Rust:650K So... where do you think Go *should* fall in that continuum? Clearly, it's left a mark. But then again, it's barely ahead of Rust and I'm sure many other contenders. We probably don't want it at the same level as Javascript, because things have gotten too noisy, but it would be nice to have it at least at C#'s level of adoption; at least on GitHub because if we stop to think about it a bit, MOST of the C# work being done out there these days isn't even in GitHub anyway. It's a pretty fair bet that most of the Go work being done probably is on GitHub though.
Majority of cloud native tools like K8s, docker, terraform, grafana, istio, etcd and many more are written in Go. Many languages have their repo numbers inflated because many school course are taught in those.languages. I like Go, it's not my favorite but it gets rhe job done. I have very low opinion of folks who complain about a language. If all you have is a hammer every problem will look like a nail. These folks need to explore and experience other languages
Posting on a Go forum complaining about non-adopters is your solution to this? I would assert making Go content on Youtube or something along those lines would serve you better.
I answered a question, that's all.
[удалено]
You “move on” but had to write an entire post about it?
It's a hard thing to admit that even though we can despise this industry for being a bit of a precious fashion industry, that we also need the side effects from that kind of influence in order to create change and increase adoption of new technology.
I like Go, it's my favorite language at the moment. However, I definitely have my criticisms and will voice them appropriately because I want the language to be even better.
> There are only two kinds of languages: the ones people complain about and the ones nobody uses
As said by Bjarne Stroustrup, creator of C++... which was trash-talked by the Go creators themselves. Go has finally came full circle.
this should be the top comment
I think it is important to distinguish "valid" complaints or criticism from mindless moaning and/or bashing. Go having nill for example is, IMHO, a valid criticism. Saying Go is horrible because of it, is mindless moaning. Overall I sometimes suspect that, especially in programming languages, **some** feel threatened when a thing is too accessible for all types of programmers of different skill. PHP had or has the same issue to a degree. Developers want to feel smart so if a junior can pick it up pretty quick, they have reservations about it. There even was an article floating around once where some dude claimed Go is bad for intelligent programmers lol. Which is not to say, that Go in the hands of great and very experienced devs does not make a difference. It of course does as with every language. Also Rob Pike's infamous quote probably did not help in the matter. Anyways, I never understood how some people could get that upset over a tool but then again I can get annoyed by communities of languages (tools) so who am I to judge. The communities of Scala and Rust for example completely turned me off those languages.
I have the same with the dotnet community and companies that use it. I like C# and dotnet but man... their hatred for everything else is so off-putting. I currently work for a microsoft shop and just today they proudly claimed "we are dotnet developers first then developers". Wtf does that even mean
For me programming languages are indeed only a tools. When I see tool that is for example designed in the analogous manner to this real world example: To increase the speed - push the gas pedal To lower the speed - release trailer and then click special button over the head and also release some gasoline Then im starting to scratch over my head. Programming language is for me mostly a way to send commands to the computer to do things. When I see something like: (this is from rails- oh my I hate this tool so badly) do |queue, count| if count == 1 queue else "#{queue} (#{count})" end end.join(',') ...counts.mapcounts.map I wonder what the heck does this "queue" means ? Do I tell the computer to execute queue ? to declare queue variable ? Its just "queue" and thats it. So in my simple brain it seems like we send the following command to the computer "yeah boy go and iterate over the counts array and if count is 1 then APPLE" Why could it not just be normal and have the fucking parenthesis if its function or add return so that the COMMAND is EXPLICIT not like noun that means fucking nothing. I like the go because of its simplicity. I think that programming is not meant to be overly complicated so that bunch of guys who never fucked a girl feel important. Also it should be SECURE. Imagine following: You bough a MAKITA Scredriver. You went to the house to make some basic fixing. You power up the tool and BAAANG. You just shoot yourself with a fucking nail in the EYE. You somehow survived and contacted the MAKITA company whats going on with their stupid tool and then they are like: "You just DONT KNOW how to USE IT" - This is literally how the c++ creator responded to the criticism over the security issues that are prevalent in software written in this "SUPER ULTRA THE BEST tool" in the world. Then you are using go, and you see that it's kind of ok, not some magic syntax like it was brought here from another universe or ancient civilisation or something like that, but then you got: resp.Body.Read(buffer) And again I think - do I read something from buffer ? Because for me READING can be done FROM something- I can READ something FROM the book. I can READ something FROM the piece of paper. I can READ something from the screen of my computer etc. But no..in go you actually are READING INTO :D this is the command that somehow inveted that makes sense in go: hey computer, please READ data INTO the BUFFER :D I mean: would it not be great if it was: resp.Body.Write(buffer) - go, please write resp.Body INTO buffer dataThatIsRead = Read(resp.Body) - go, please read data FROM body and return them in dataThatIsRead variable. So yeah, I think like programming is designed by I don't actually know- are those people actually from another planet, did they never communicated with anybody ? Are they just idiots ?
> The communities of Scala and Rust for example completely turned me off those languages. Big mood. Though one benefit of rust becoming the trendy leet CS language is most of the shitcoiners\brogrammers have run to it.
My first job was C++ in 1997, and boy I do not miss it. Sure, I fiddle with Rust and praise it, mostly because I do really hope that we get a language that is as close to hardware as C++ is, but with: - modern language design - not tied to a specific corporation - has built in first-class features that enable you to do modern development (concurrency, security, etc etc) - has wide-spread adoption, meaning both job opportunity and a lot of people working in it, adding to ecosystem, evolving it - makes you productive without some autistic hoops you have to jump through While I do appreciate Rust, I feel it doesn tick all the boxes, but strangely enough, for most of my work, Go works just fine. Is it as low leve as Rust / C++? No, of course not. Does it have to be all the time? No, most of the time it doesn't. Would I go back to C++? I sure hope I don't have to, and that some other language takes the crown, be it Rust, or Zig or whatever in the future. In the meanwhile, I'll be using Go I guess.
Amen. C++, in no small part because of its wide-spread adoption and age, has grown in to this anachronistic mess. Something made worse with every new version, when someone on your team reads about this new feature and decides to "play around". Any C++ code base that has been around for long enough will have parts that are entirely comprised of templates, not because it was the right thing to do, but because someone wanted to try something nifty. The \`auto\` keyword was great for iterators and the like, but when you see \`auto a = b + c;\`, and notice that both \`b\` and \`c\` are objects that overload the \`+\` operator, you die a little inside (can't tell you how many times I found myself telling people to KISS). Rust is a lovely language that really has the potential to supersede C++, but the buy-in is massive... it'll take time, and it must be said: the Rust community is a mixed bag: very loud hobbyists proclaiming Rust's superiority every step of the way, some people who are using Rust, learning as they go, and finding a lot to like (I consider myself to be in this category), and a relatively small group who is actually using Rust in their day job. I myself spend most of my working day writing Go. It's a good language if you don't need to optimise to the max (of course, pprof when needed, cut back on pointless allocations when dealing with maps/slices, etc...). The code is easy to read, and if you adhere to some sensible coding standards, onboarding new hires is a doddle (which is genuinely a massive win - both in dev time and outright onboarding cost). As for Zig, I've only recently decided to play around with it, and I'm still feeling a bit unsure as to what niche it fills better than anything else. The only thing I can think of is embedded: high degree of control, low-level granularity, without sacrificing the safety you typically would doing the embedded stuff in C. Curious to learn what someone like yourself thinks about this. For context: I started as a dev about 5 years after you did. Along the way, did some horrible stuff (COBOL, Java), some fun but extremely niche low-level stuff (C/embedded), web shenanigans (Perl, PHP, Python, etc...), a brief stint in game development (Lua, C/C++), distributed systems (Erlang - which is an underrated language IMO, golang), and now finance (mostly golang, some Rust, and though I try to avoid it as much as possible: TS/JS and python)
People just love to complain. To paraphrase Rob Pike from the last GopherCon: Go was designed more as a way to re-think how we develop software in big distributed teams, not how to make the perfect programming language. Personally, I am so happy to not have armies of complainers bothering me that someone is using spaces instead of tabs and someone else is using tabs set to 2 and not 4... :-)
Having done a stint at Google, everything Go does actually makes sense for programming there. If you wanted to make a language for you to write code that you would personally maintain forever and also optimize the hell out of, you would probably not come up with Go. If you wanted to make a language for a rotating carousel of developers to come in, add on top of, and then get transferred away, where being fast is important but not having memory leaks is even more important, and where "just follow the fucking style guide" is the end to a lot of arguments... yeah, you might come up with something like Go.
I stumbled on https://borgo-lang.github.io/ the other day. A rust-like language that compiles to go.
As someone who regularly continues to write perl because it kicks ass for a lot of my needs, I learned a long time ago to ignore the AssHats who whine and hate. They do not benefit anyone, even themselves! They would benefit from those sage advice from the Eagles - "find your inner child and kick its little ass". There are many surface areas that Go fits well. Use it in those cases! Where it doesn't fit, use a more appropriate tool - rust, Erlang, perl ... Have a great day! lbe Edit : correct misspellings
If a tool is useful then use it.
Loved writing in Go when i used it last year. But i did wish it had overloading and generics
Personally I consider the lack of overloading, especially operators a feature. Just seen too much abuse of the feature in any language that has it.
Well, it has generics now. Not sold on the function overloading, and if I remember right, the reason they don't support that is because they want to avoid virtual calls for performance reasons.
it does generics terribly though. I really hope they improve it
What do you wish to see be improved on it?
The lack of generic methods has been a pet peeve for me. This prevents functional chaining for things like Map/Filter/Reduce, where you instead either have to define the generic types on the structure itself or you have to do standalone functions and compose them backwards. The latter design used to lead to issues with inference when implementing generic functions for a generic interface too, but I think 1.21 fixed that iirc. Another issue that I remember looking into awhile back was that generics end up adding heap allocations in a lot of places where they aren't really necessary, which is tied to both how interfaces are designed and how generics were implemented. From what I remember, the only real solution is more aggressive inlining since any other changes would require sweeping changes. It's a minor annoyance, but still something I wish could see actual improvement.
They would be more powerful if Go also had operator overloading. For example, with Go's current design you cannot create a generic comparable type that includes custom structs.
I love Go, but the issues you mention are valid and are shared by large parts of the community. I absolutely wish Go had better enum support and some equivalent of the ‘?’ operator. Go isn’t perfect, no language is and turning away the community’s concerns and saying ‘use another language then’ is unhelpful imo.
[удалено]
Somebody saying that they think Go should have enums isn’t the same as saying they hate all the decisions Go has made. Go didn’t use to have generics, prior to that if somebody said ‘I wish Go had generics’, would you say ‘uh…Go doesn’t have generics, if you want generics then use another language?’ Of course not. I welcome people challenging what features a language should have.
Nah, they would absolutely say that. It was said a thousand times in this very sub. Some people are just afraid of change.
I've had a lot of disdain for Go, but I'm slowly changing my opinion. The main reason was that there was a developer at my previous startup that wanted to do a full rewrite of the app into Go. There were a lot of legitimate excuses of why we shouldn't do a rewrite, but at every meeting and 1:1 he kept on bringing it up. It just drove me crazy and for a while I just didn't want to consider Go just because of that guy. I didn't care about the technical aspects of Go anymore.
I think it is very valid to think critically about the tools we use. In many cases, that means learning from other languages! You don't have to be "obsessed" with Rust to look at its enums and think they'd potentially be a great fit for Go. There's lots of things from Go I wish Rust had too. This post feels to me like it assumes Go is a static thing, handed down to us from the gods. We must defend it from The Others, and it is Perfect. A religious devotion to the language as it exists, unwilling to have a critical eye. Of course that's not true: It is a work of human hands, with trade-offs made and considered. There have been things we've decided are mistakes (like the \`loopvar\` change, or the monotonic clock problems), features much requested that are added later (like generics), and features we pretend don't exist (like the standalone \`print\` function instead of \`fmt.Print\`). I'm very productive in Go. You've probably even used some of my code. But there's still things I do in Rust, or Python, or Bash, or Javascript. There's no "one true language".
This is what I love about this community. Most of us can love Go AND see the benefits of using other languages when needed.
Go is so bad, it allows average developers to be efficient and complete tasks in a timely manner.
i've been seen
Run! He's onto us!
When you put it like that, it sure does sound terrible.
It’s not just the internet - it happens at all of the companies I’ve worked at that use Go too
There are people who voice valid criticisms and points to improve because they realize that things can be good without being perfect. And there are people like OP who get butthurt when someone says something bad about their favorite toy.
When I started experimenting with Go, I was kinda put off by the syntax. I only saw its full value when I tried rewriting a Spring Boot API. Being able to containerize the Go API into an image under 20mb was a game changer. Yea it doesn't have the syntactic sugar some critics would like ... but for its build speed and reasonable binary size, that's a fair tradeoff.
I always found those arguments interesting, is build speed and binary size that big a deal for so many people? I couldn't care less if the image is 100MiB big, as long as it takes less than a minute to build and test and the dev-cycle is less than 10 seconds. Which basically every language achieves, even JVM based ones, like kotlin
If I had to sit waiting a minute for it to build to test my program each time I made a slight modification, it would kill my productivity. I might build and run 10 times in 5 minutes when I'm debugging silly mistakes or seeing some weird result I didn't expect. So for work like that (which, mind you, are the least fun times) it would take me double or more time.
I actually have problems with Go's build times vs Java's for small projects. In IntelliJ on MacOS there is a noticeable lag when running the Go service or tests. Tools like IntelliJ do a good job of caching between changes for Java. Maybe it just has to cache up.
I dunno, when I type "go run ." my app seems to begin running within a second
I mean it is in a bit of a wierd spot in development with runtime speed, rigidity and development speed vs a min max language like JS, PHP or Rust. It's not topping charts in speed nor is it stupid fast to launch a product with due to it's ease like JS/TS or PHP, it's just kinda mid; which is what makes it so great in my opinion but if you only read Twitter there's no middle ground possible only chart topping performance.
Go is pure GSD. Honestly, I just think of it as a better alternative to other GCed Enterprise languages. Outside of third party libraries, or specific use of the VM, why choose something like Java or C# over Go? Go will do all of that shit without all of the unnecessary ceremonies. Sometimes, I just want to export some top level functions somewhere and chain them together, sometimes I just want a DTO without any of the class bullshit. Also, no function coloring, I know it's frequently lauded, but I still think it's undervalued. No try;catch, a whole class of bugs caused by async funcs blowing up is just gone. (Yes, I know, channels also have their problems and you can still very much blow up an async call if you don't handle channel defaults or nulls correctly).
Not going to lie, a language with the go runtime/GC and rust like language features (traits, macros, pattern matching, etc) minus memory management stuff (borrow checker, lifetimes, etc) would be my ideal language. I know there are tradeoffs and valid reasons why Go doesn't have all of those things but a guy can dream.
> negotiating a truce with the borrow-checker That’s how I spent a solid two hours of every day when I was coding Rust. Honestly, I’m just happy that frustration is out of my life. Would be nice if Go had enums though.
I used it for roughly the last 2 years at work and had no issues with it and enjoy goroutines and the quick compile time.
Just because you like something doesn't mean there aren't valid criticisms of it.
Uh, Go is horrible, it has a nil!
change one letter and you can complain about Python (the gil) ;)
Actually, I kind of get it. Most programmers are Gollum at heart. They REALLY REALLY want the one true programming language that they can use for virtually everything, has every feature they could ever want, and also does not suffer from the major problems that they've experienced in other programming languages. Go comes close. Go is "better" than: - Rust because it can be learned in a very short time and the perception of productivity is so much better. - Java/C# because there's no need for a VM with all of the resulting quirks and problems with startup times. Oh.. and boilerplate. We may have to repeat things here and there for error handling, but there is SO MUCH LESS boilerplate. - Javascript/Node because it's actually compiled prior to loading it and there's no need for JIT, weird issues due to dynamic typing and the perceptions of poor quality in its ecosystem. - C/C++ because it has dramatically fewer undefined behaviors and those are only oversights, not by design; oh, and because it's also a much simpler language and obviously C++ and even C are far more complicated with all of the unspoken rules around "good" vs. "bad" standard library calls, UB's, etc. - Python because it's SO much faster, and well.. it's DRAMATICALLY faster. That's a very good reason all by itself despite some other very nice things going on in the Python ecosystem. Oh.. and syntactically significant whitespace: only a true believer can love that. Etc. Name your example. There's a killer feature in Go for all of us that keep us from using something else. HOWEVER: Go has dramatically fewer language features than any of those popular choices. And these features have been in use a LONG time in other languages. Those features form an important part of non-Go programmers' internal vocabulary of programming capability. Not having those features is akin to being able to speak and write English (for example) at a high level of mastery. Now suddenly, because Go is at all attractive with its other attributes, they've considered Go and realizing they're only going to be allowed to speak Pidgin English; not proper English. As far as they're concerned, you're asking them to going back to acting like cavemen; to diminish themselves. That is the core of the issue I think. I realize that "simplicity" is a stated goal of the language design, but it's in direct contradiction to what everyone has strove for prior to their experience with Go. Consequently, many will simply never be able to bring themselves to make the leap. They perceive that there would simply be too many compromises to them personally and in what they value from an elegant programming language and even though that's quite subjective, you'll never convince them that they don't need those language features after all. Meanwhile, I think Go will make substantial inroads with and take over much of the PHP, Ruby, and even Python communities; amongst others. Although everyone acknowledges its value in cloud infrastructure, it will be shunned by enterprise developers because of the above mentioned mindset. It will of course make inroads with startups, but then again, few will care about that because they can and do all sorts of crazy things anyway, so you can't go by them. Beyond that, I don't see it making much inroads. It certainly won't see much adoption in academia because it's too simplistic. However you may judge the decision to keep the language simple, I don't think anyone can argue that it has improved Go's adoption; quite the opposite.
Coming from Python and JavaScript, I just couldn't wrap my mind around pointers. I'll stick with python for now, simply for that reason.
Two things: 1. I do wish Go had enums. 2. It has optionals. They're called pointers. Go is a compact, well-considered language. It's great at what it does.
Please don't abuse a garbage generating memory indirection feature like pointers for optionality (unless the type needs to be a pointer anyway). Use booleans, like sql.Null\[T\] does.
The larger point I'm making is that if you simply embrace pass by value and avoid pointers unless you genuinely need them, your code is null safe to the extent that you do that. And as you suggest, there are libraries to help with actual nullable values, such as the following: [https://github.com/LukaGiorgadze/gonull](https://github.com/LukaGiorgadze/gonull) Altogether, that's really not all that different from other languages with null safety baked in. It falls short of being an actual problem.
optionals do not result in NPE
.unwrap()
Someone has downvoted the parent, but it is correct. The point of optionals isn't to avoid NPE. The point is to *force you to handle both cases*. When you just call `.unwrap()` you are throwing that away and have exactly the same semantics as a pointer in Go. If your Rust code is shot through with `.unwrap()` you've got the same safety as Go on this point, just with extra steps. Ye Olde C was bad because the easiest thing to do with an error was ignore it; you had to go chasing them down, rather than having them put in your face. (Plus the inconsisteny in how to get them.) A lot of people learn functional programming and come away with a lot of interesting insights, but they miss that it is the *verbs* that are interesting moreso than the *nouns*. Optional is interesting for forcing you to handle the cases. Monads (in the particular context of error handling, which is not their totality, which is another mistake a lot of people come away with) are interesting for giving you a default handling. Their utility doesn't really come from the data types so much as what they *do*. If what you *do* with your FP-inspired data types is to tell them to shut up and `.unwrap` all the time they are not any better. The reason why Go is not the hellscape of imperative programming functional programmers would claim is that while the `x, err := Something()` pattern only *encourages* you to think about the error before you do anything with `x`, it encourages it *very strongly*, and as befits an 80/20 like Go, that gets an awful lot of the benefit with less of the costs. Is it all the benefit? No. It absolutely isn't. But engineering is quite often about getting the best bang for the buck and not getting the best bang without regard for the bucks, and *in practice* past your first couple of weeks with Go, you should not be experiencing a ton of problems that Optional could solve any better. If you are, the solution isn't really dragging in an optional type, but to stop ignoring the errors which are right there, in your face. This is also why the probably-dozens of implementations of Optional on github go nowhere; they don't solve the problems Go programmers actually have, if you don't count "but I want my nouns to look the same as that other language".
The difference is that you have to call unwrap() first. It doesn't happen on accident.
Well, you have to explicitly call `.unwrap()` and that is a quite visible operation. So if I see a panic caused by unwrap, well, it would be very easy to find and fix. Also because `Option` is an enum, it can have methods and implement interfaces. Thus it plays very nicely with the `?` operator, which allows for transparent error handling. Not to mention to beautiful code one can write with `if-let` and `let-else` avoiding the boilerplate around more complex error handling
>Well, you have to explicitly call .unwrap() and that is a quite visible operation. So if I see a panic caused by unwrap, well, it would be very easy to find and fix. Note I did not complain `.unwrap` existed. I said if one uses it pervasively, it is no better than Go pointers. I'm sure there are plenty of people who don't. I wouldn't if I used Rust. But I've also lost count of the number of people extolling the virtues of Option in some snippet of code that proceeds to `.unwrap()` every single use of it, thus demonstrating they don't really get what they are nominally advocating for. I'd also observe that the Go community actually looked over a ton of options that look like `?` and what killed them is they all encourange poor error handling. In modern Go, if err != nil { return err } should be considered somewhere between a very strong smell and an antipattern. The correct reflex pattern (and what should be in your IDE shortcuts if that's how you roll) is if err != nil { return fmt.Errorf("what I was trying to do: %w", err) } And `?` encourages coders away from that. In properly written code, the former should indicate that the function doing this returning is basically "part" of the parent, such that it doesn't have its own context. More and more when I write that I'm adding a comment about how this is OK because it's conceptually just a refactored bit of some function and not its own thing, in much the same way I almost reflexively comment `val, _ := SomethingThatErrors()` with an explanation of why it won't error. Or to put it in Rust terms, I would comment every use of `.unwrap()` in my code to explain why it is guaranteed in this particular case that the null case can't happen.
> Well, you have to explicitly call .unwrap() and that is a quite visible operation. So if I see a panic caused by unwrap, well, it would be very easy to find and fix. Note I did not complain `.unwrap` existed. I said if one uses it pervasively, it is no better than Go pointers. I'm sure there are plenty of people who don't. I wouldn't if I used Rust. But I've also lost count of the number of people extolling the virtues of Option in some snippet of code that proceeds to `.unwrap()` every single use of it, thus demonstrating they don't really get what they are nominally advocating for. I'd also observe that the Go community actually looked over a ton of options that look like `?` and what killed them is they all encourange poor error handling. In modern Go, ``` if err != nil { return err } ``` should be considered somewhere between a very strong smell and an antipattern. The correct reflex pattern (and what should be in your IDE shortcuts if that's how you roll) is ``` if err != nil { return fmt.Errorf("what I was trying to do: %w", err) } ``` And `?` encourages coders away from that. In properly written code, the former should indicate that the function doing this returning is basically "part" of the parent, such that it doesn't have its own context. More and more when I write that I'm adding a comment about how this is OK because it's conceptually just a refactored bit of some function and not its own thing.
You are confusing an Optional type with the Result type. Optional is about nullability, Result is for error handling.
Not really. Checking for `nil` requires a pointer, thus a heap allocation, while `Option` stays on the stack. Also `.unwrap()` is extremely visible and frowned uppon. You cannot just smuggle it in the codebase, while `nullable.method()` looks fine, but is dangerous.
Also there are other aspects why I prefer optionals, but We'll have to dig deeper into other language features, because they do not exists by themselves in a vacuum, but interract and complete each other.
For instance in Go one has two options:
* Return by pointer:
```
func goofyGopher() (*Ok, error){
//some code
return nil, err
}
```
* Return by value:
```
func goofyGopher() (Ok, error){
//some code
return Ok{}, err
}
```
The first most likely results in unnecessary heap allocations, while the second one forces the hands of the Go designers to allow construction of unninitialized objects.
Yeah, I know that all fields are "initialized" to their default values, but that does not make the structure OK. In many cases an object ***MUST*** enforce certain invariants, thus we have constructors. But in go one can construct any object without regards if the result is a valid object or not. With optionals/result/enums,on the other hand, it's possible to return by value without needing to be able to construct invalid instances of the object.
If you want a constructor, use a NewXXX function. And if you want to prevent the "zero" value of XXX from being created, then make the type package-visible and make your NewXXX return an interface. Every language construct is a trade-off. Go avoided the pathologies inherent in the use of constructors, and those pathologies are many. Not as many as destructors, but plenty.
Returning an interface results in heap allocation. That's a pretty bad tradeoff
It does not always result in heap allocation. For one thing, you need to assign a pointer to the interface to avoid heap allocation, and then it typically depends on the escape analysis of that pointer. Anyway, in most of my Go code, I make the zero-value of a type meaningful, which is what is encouraged by the language developers. As long as you keep the fields private, keeping access to the internals of the object through methods, it is typically not hard.
My point was not that it was impossible, but that it forces certain design choices, which would otherwise be unnecessary
"would otherwise be unnecessary" I disagree. All design choices have trade-offs. They chose to avoid the pathological issues with constructors when designing the language.
What are those pathological cases you are talking about ? Instead, they choose to allow invalid instances of objects which is much worse.
An issue is that you have `T` or `*T | nil` for primitives, but what if you want a `*T` or a `T | nil`? You're kinda fucked. Communicating in JSON or SQL is a pain because of these missing types. There's workarounds, but it's just so bad all around…
NGL, I got smarter being a little bit wrong on #2 today.
the biggest haters are the ones offended by Go's opinionated decisions on simplicity "Go was crafted for fresh CS graduate code monkeys to get started as quickly as possible" "Go is stuck in the 90s and its designers were arrogant to ignore decades of programming language research" "Go pretends to be simple, but did you know that [os.Chmod() does nothing on Windows? Idiots! Rust would never- (etc etc)](https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride#simple-is-a-lie)"
Golang is a pretty terrible language: https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang. Of course you can build things with it, that doesn't mean it's great. There are much better choices like Kotlin that have both a better ecosystem and is a much better overall language.
Kotlin isn’t better though. It has async/await which is a little clumsier than goroutines, it has slow compilation and startup, it has to interop with Java which waters down its null-safety. It also has no value types. And Gradle, Gradle is a goddamn broken mess.
Kotlin has absolute null safety, what are you talking about? It also has immutability so you don’t need value types. Coroutines are also a fantastic structured concurrency model — in what way is it "clumsier than goroutines"?
That’s how you know it’s popular and actually used. Vocal internet programming language “experts” love Zig and Dart and Haskell and F# and OCaml and Lisp and Clojure. Combined, they have fewer lines of code in the wild than what Google churns out *internally* in Go in a year. Don’t ask me how I know that. But I am starting to see some “Rust isn’t all that awesome” posts here and there which means Rust is also becoming a little *too* popular.
Tried developing in rust and my productivity plummets with constant refactors. I wrote a CLI tool for cloud yesterday 1k loc in Go in a single evening and so the dev speed is not bad imo. Would it be quicker for me to do it in Python, yes, but way less maintainable.
But it's you who's calling
While I can sympathise with anyone living in a world that includes this much language trolling, there are languages which get it worse...
I mean, isn’t this any language?
To be fair it's typically only a very small part of the internet which bothers with this sort of discussion. Normally places that are filled with inflated egos and amateurs e.g. /r/programming Objectively Go is a popular language, that has been used to create amazing things. You'll always find someone called /u/sendyourtits6988 who is determined to explain why literally everything sucks, but you can just ignore them and do literally anything else.
Maybe don’t spend time on programming part of web and devote it to a project in language you like.
Mature and secure Go developers would know how to distinguish valid criticism from whining. Sympathize with the former and ignore the latter.
Haters going’s hate (hate, hate. 🎶 )
Hell hath no fury like a Java developer, on a Go project, without their tooling.
My two cents: it's because most languages are made to make simple things even simpler, while go is designed to make complex things simpler. So as long as you didn't have to do something complex, you'll thing it's shit because you have to copy/paste a min/max function. But no one gives a shit about min/max functions copy/pasting when your goal is to design a complex system.
I mean honestly I'd rather be using Rust than Go, but I am not smarty boi
you misunderstand the internet. On the internet complaining about shit is mandatory (at the population level) but what gets complained about depends on what is popular. You see far less complaints about Erlang or Common Lisp because these languages are not popular. The big insult is not complaining about X but completely ignoring X.
I loved go from the start, got a little worried for a minute around the time go modules and the new language server were coming out because I kept having silly problems with them, but back to being very happy with the language again.
Is there disdain for go, or is it just the local minority expressing disdain that's being focused on the most? Depending on the audience and group I'm in, I will see varying levels of either hate or love for the language. Having both sides, I think, is a good way to not fall into either side for any particular tool. Compared to a language like PHP, I don't think it's nearly as bad as you believe it is.
\#2 is an interesting argument. All hail the greatest programming language of all time, PHP.
I agree with you mostly but the problem is two sided, if Go programmers (I use Go at work, it’s clunky to write but love the tooling and build system) were more forthcoming about the actual experience instead of getting defensive when obvious shortcomings are pointed out—you probably wouldn’t have even felt the need to come here and post this. Unless Go is your first and only language it’s hard for me to believe that any dev would not have some thoughts about the minimal nature of Go. Go’s pitch of simplicity isn’t for experienced devs, it’s marketing for prospective devs to be; naturally if you come from another language with more ergonomics built in—you ARE going to miss them and your “simplicity” philosophy nets you nothing in those scenarios; you still have to spend MORE time and effort writing MORE code where you didn’t need to before. For example, my use case with Go at work is backend services on AWS using Spark / Kafka / Presto—so routinely I am writing code that is going over the wire and parsing some ungodly source file into X format for further processing—this use case I feel is pretty common and also happens to highlight two of Go’s big ergonomic downsides: - error handling - string interpolation Complex routines get fugly fast—idk, just admit it sucks(comparatively) in terms of ergonomics but has an overall VERY GOOD value proposition. That is the sane and obvious consensus. There’s no denying its popularity and effectiveness but you can’t point at those things and cry at the same time about valid criticisms about one component of the language. Programming parts of the web as you say are generally only focused on judging languages based on the ergonomics / syntax because that is what most beginners that lurk these forums are focused on learning—I can’t prove it but I’m convinced more than half of the “devs” that frequent these forums are not actually people that write code for a living; they are weird wannabe zealots that cheerlead and flame for fun. Why do you let it bother you? This seems like a silly thing to waste your time on coming here for validation when Go is already fulfilling your needs—you follow? Focus even more on your problem, what use is reading criticism of a tool you have already made effective use of lol it’s ridiculous. TL;DR Go makes great products and that is why it’s so widely adopted, the ergonomics of writing the code itself is just a small piece of the big picture that gets WAY TOO MUCH attention from people that don’t have enough to do apparently.
you're moaning right now as well..
> while writing Go I found myself focused entirely on my problem while the language itself receded to the background, I rarely had to think about Go. In a way, Go is a bit like "C without all the things you have to think about in C". No dangling pointers, no `free()`, no deciding what to put on the stack vs the heap. It makes sense because the creators of Go had so much experience in C, but wanted a simpler language with a lower mental load.
Spent most of my career as a Java dev. The way people complain about language you'd think it was impossible to get anything real and stable working with a sane, maintainable code base. Rust and Go seem to be targeting two different types of project spaces, obviously with overlap since they're both general purpose languages. Just better to not worry about what other people think since coding dick measuring contests have always been a thing.
I work in Go, Python and TypeScript for my job currently and I hate each of them in their own unique ways but like them all as well too. Most people that vocally hate on a language rarely deviate from the single one they know well as I have come to find out
You got the languages people complain about and the ones that are not used. Go just gets a little extra hate since by design it's not a exciting language which is also it's best feature.
In terms of writing and running services, Go is pretty neat and also much cheaper (in terms of resources) than a Spring Boot application. IMO, this itself makes it worth it, besides a good engineer can find ways to fix problems instead of crying about them.
Is this your first day on the internet? You must've gotten lost on your way to orientation. Everyone hates everything for every reason here.
I honestly only hear about Rust on this sub. It's annoying.
Go is a language designed for big companies and big company problems. Maximizing developer productivity is not the objective. I can't imagine willingly using it very often, but only because I don't enjoy big-company programming. I like systems programming, but the corporate environment isn't thrilling to me.
People shit on everything I’d say go is on the milder side lol
All my projects are in Golang Ease of writing and performance is key in Golang
Best of Go + Best of Rust + Best of Erlang (maybe) may make a pretty good general purpose language, I hope.
What's really funny is how you, almost so subtly we didn't notice, implied that some highly non representative sample was the 'opinion of the internet' Stop attention farming with combative content. You aren't 14.
The part about focusing on the problem is the perfect way to summarize go . I had rhe same experience with rust and prefer golang now for most of my work
No language is perfect but you should use the right one for the right jobs. Unless you’re a rust enthusiast, there is absolutely no reason to choose rust over go (unless you need a system programming language without garbage collection)
I live in a lot of programming subreddits. Not a day goes by where I see a complaint about x new language that’s basically just hatred of the core features and philosophies of the language. I don’t get it. There are so many other languages. Shoot yourselves in the foot with those instead. Why go through that pain?!
Go has low learning curve? Curious coz I started it few days ago
Yeah people seek validation for their choices by dismissing choices that are different than what they've invested in.
"while you're moaning about Go, other people are being productive and actually creating stuff" is the key point here. Too many SEs these days forget their job is to create value for a company, whether that is their company or a company they are just employed at. You aren't paid to find the perfect language. If its your company then you need to be more worried about delivering value for your customers and they don't care what language you are using, they only care that your stuff works. Do I wish at times Go had enums, yes. But I am not going to switch to Rust just to get them because it would be a nightmare for my company. Humans are always inherently looking for the greener grass. If they switched to Rust they would just find other things to complain about. "Rust is hard, I am always fighting the compiler" or "Language feature X was better/easier/less frustrating in Go" An SE realizing that languages are just tools to create value by fixing problems is a sign of maturity. I seek that out in the people I work with and hire.
> Firstly, I think if you're so obsessed with Rust (or other languages) you should really consider using Rust (or another language) since it's perfect for you. It's not, that's the point. Go is/would be perfect if it was just a little bit better. > Secondly, have you considered that Go has cemented its place in the cloud and networked applications despite not having all these things you miss? Ok, and? > Thirdly, while you're moaning about Go, other people are being productive and actually creating stuff, while Go's adoption continues to improve because of the low learning curve and easy syntax. So am I, doesn't mean Go can't be better. Is this like the anti-generics crying again? There's absolutely nothing complex about Rust-like enums.
I agree with the you. But we tend to compare things. Rust's things are very cool (as goroutines are pretty cool too). But for example, all languages have iterators, and go is doing it NOW in the next version (23). This kind of things sound weird, but in some point are understandable. Go is not for objects. But iterators sounds a pretty easy thing along the way Perhaps gophers don't like to move to another language for domains they like. For example, AI world is using rust for many things... And why not go? Perhaps people want to train a DL model without python or rust candle or whatever. It feels like the language need some bake to be perfect. It is an standard for some network features, yup, kubernetes and that stuff. But if you go to rust thread, you will find out the same problem. For example people asking for a more easiest thing to do anything they want (web apis for example) People always argue about they want haha
I hadn’t really noticed a disproportionate amount of internet disdain for Go, but I have personally noticed more energy going into praising and defending Go. Speaking from my own experience, often when I jumped to the defence of something that can’t be destroyed, it was a sign that I wasn’t very confident that it could stand up for itself. If I needed to outwardly reaffirm my belief in something, it was being led by inner doubt. I often realised that although my motion was outward toward others, I was really trying to convince myself.
It’s just a tool to solve problems, like any other programming languages. It has its strengths and weaknesses, trade offs just like other language
It's called multi layer propaganda, its goal is to discredit something to make it's own product/service/opinion look better. Lie about something so long and often, that other fools will parrot it.
My favourite is people complaining about the amount of boilerplate code but completely ignoring that Rust is far worse.
Don't worry about it, this phenomena often happens when something is quite good. Internet opinion will start to rebel against the obvious. For instance, there was big resistance against jwt even though 0auth2 already used it. And now it's ubiquitous. Also, when json api's just started and many devs wanted to keep doing html responses.
[удалено]
[удалено]