Going to the Google's walled garden with Go
-
Lies we tell ourselves to keep using Golang
In the two years since I've posted I want off Mr Golang's Wild Ride , it's made the rounds time and time again, on Reddit, on Lobste.rs, on HackerNews, and elsewhere. And every...
(and the forerunner,
I want off Mr. Golang's Wild Ride
My honeymoon with the Go language is extremely over. This article is going to have a different tone from what I've been posting the past year - it's a proper rant. And I alw...
)
The bit about go being really bitch to both call from other languages and call other languages including C libraries from surprised me a bit.
-
@Bulb decent. I suspect many languages' users eventually emit one of these.
-
… I've read a bit more … of the article through which I got to the above anyway, and apparently the reason go does not use the standard C runtime and standard C calling convention that basically every other language uses is that they are doing some funky stuff with stacks to minimize overhead of
thdreads (called “goroutines”).
-
I’ll give it a read
Go not letting you do operator overloading, harkening back to the Java days where a == b isn't the same as a.equals(b)
No. That is a point in every language’s favour. Overloading an operator just makes a new maintainer’s life a misery.
-
@DogsB except languages where + is both addition and concatenation, that can fuck off especially if types are fluid and the meaning implicitly changes because of one or other side of the equation.
-
@DogsB For maintainability it does not matter a iota whether you are overloading an operator
==or a methodequals. Both are equally bad if overloaded in an unexpected way. What's left is the cases where operators are more readable, so allowing operator overloading is a net win.It only got bad name because C++ and C# standard libraries abused operators for things that isn't appropriate. Which again isn't any different from using stupid method names.
Of course in the specific case of Go there is the other problem of comparing pointers or comparing the objects they point to, which ends up being kinda confusing in all languages that expose those two options.
-
@Arantor In statically typed languages it's not a problem as you are generally aware what the operands are. Nor really in dynamically typed languages that have enough restraint no to try to guess what string + number should be and just raise an error. It's only when mixed-type addition silently does something weird when problems begin.
-
@Bulb ah so basically just JavaScript then?
-
@Bulb said in Going to the Google's walled garden with Go:
of thdreads (called “goroutines”).
Ahaha, like
coroutineexcept with agand it's a thread.
-
@Arantor said in Going to the Google's walled garden with Go:
@Bulb ah so basically just JavaScript then?
Yup. And Java
-
From the "wild ride" article:
there's no equivalent to the "executable bit" for files on Windows.
This isn't true. Detailed ACLs on files in NTFS can, indeed, specify an "is executable" permission. It's a bit odd when
cpfrom Cygwin ends up creating a copy ofnotepad.exethat isn't executable because its ACLs don't have the "is executable" permission.It's a bit weird ending up with a file called
notepad.exethat cannot be executed.But in general, in the two articles, I had the definite impression that the author was channelling eev.ee's attitude when he wrote a Fractal of Bad Design.
-
@Arantor said in Going to the Google's walled garden with Go:
@Bulb ah so basically just JavaScript then?
1995 - Brendan Eich reads up on every mistake ever made in designing a programming language, invents a few more, and creates LiveScript. Later, in an effort to cash in on the popularity of Java the language is renamed JavaScript. Later still, in an effort to cash in on the popularity of skin diseases the language is renamed ECMAScript.
-- James Iry, A Brief, Incomplete, and Mostly Wrong History of Programming Languages
-
@Bulb said in Going to the Google's walled garden with Go:
@DogsB For maintainability it does not matter a iota whether you are overloading an operator
==or a methodequals. Both are equally bad if overloaded in an unexpected way. What's left is the cases where operators are more readable, so allowing operator overloading is a net win.It only got bad name because C++ and C# standard libraries abused operators for things that isn't appropriate. Which again isn't any different from using stupid method names.
Of course in the specific case of Go there is the other problem of comparing pointers or comparing the objects they point to, which ends up being kinda confusing in all languages that expose those two options.
Every feature has gotten a bad name from people misusing them but allowing a developer to overload operators has always struck me as skullduggery waiting to happen. You see readable, I think : “great, another developer whose decided he’s a language writer” and wish I could up the day rate. I should just need to know how the language works. Not the snowflake variation of it here.
I’m not saying languages should stop using it. Concatenation would be harder but putting it in the hands of everyday devs is just fodder for the front page and me upping my day rate.
@Arantor fajitas. I had something to say but spell check gave me that and I thought it would be more interesting.
-
The cutting edge startups here use golang and pay like crazy. I would learn it if it means getting that job but everytime I've tried it for something even remotely non-trivial, it gave me a weird nauseous feeling.
-
@stillwater said in Going to the Google's walled garden with Go:
The cutting edge startups here use golang and pay like crazy. I would learn it if it means getting that job but everytime I've tried it for something even remotely non-trivial, it gave me a weird nauseous feeling.
I'm a bit curious why that old piece of shit has suddenly become hipster cum to be gargled.
-
@Carnage When has it ever not been hipster cum?
EDIT: I just checked - startups in the payments industry, new discount brokers, weirdass saas services, real time systems are all using Go except one place which was using Scala.
-
@DogsB said in Going to the Google's walled garden with Go:
I’ll give it a read
Go not letting you do operator overloading, harkening back to the Java days where a == b isn't the same as a.equals(b)
No. That is a point in every language’s favour. Overloading an operator just makes a new maintainer’s life a misery.
Operators are just functions with a special name. Having to write
a.equals(b)is stupid when the language has an equality operator.And I rather have overloading than running into truncation bugs because I wrote
absinstead offabsorfabslor ten other cryptic variations.
-
@stillwater said in Going to the Google's walled garden with Go:
@Carnage When has it ever not been hipster cum?
EDIT: I just checked - startups in the payments industry, new discount brokers, weirdass saas services, real time systems are all using Go except one place which was using Scala.
golang seems to be getting more popular and for some reason being hot shit in startups, while being generally shit. But I guess the hipsterati figured out it's the JS of compiled languages so
-
@Carnage said in Going to the Google's walled garden with Go:
golang seems to be getting more popular
Why though? Can someone ELI5 why it might be technically considered superior? I've been searching for an answer to this very question for about two years now and I've never gotten a straight answer!
-
@stillwater said in Going to the Google's walled garden with Go:
@Carnage said in Going to the Google's walled garden with Go:
golang seems to be getting more popular
Why though? Can someone ELI5 why it might be technically considered superior? I've been searching for an answer to this very question for about two years now and I've never gotten a straight answer!
Not me, that was why I posted the previous question about why it's suddenly become hipster cum gargle.
It was born technically shit, so there is nothing about it to consider technically superior.
It's quick to pick up, and the compiler is "forgiving" and will happily crank through utter shit, much like JS. And much like JS, all the responsibility of correctness is lumped over on the programmer.
Strangely enough, languages that lump over responsibility on programmers tend to attract the worst programmers instead.
-
@stillwater said in Going to the Google's walled garden with Go:
Why though? Can someone ELI5 why it might be technically considered superior?
Popularity of any given technology has nothing to do with technical superiority. It's all fashion, religion, ignorance and herd mentality.
-
@MrL said in Going to the Google's walled garden with Go:
@stillwater said in Going to the Google's walled garden with Go:
Why though? Can someone ELI5 why it might be technically considered superior?
Popularity of any given technology has nothing to do with technical superiority. It's all fashion, religion, ignorance and herd mentality.
It's Google branded (goroutines
). That's enough to make the hipsters flock to it and make me avoid it like the plague.
-
@stillwater said in Going to the Google's walled garden with Go:
Why though?
So a couple years down it can all be rewritten in the new hot hipster gargle, guaranteeing employment, conferences and accolades to all who can do sit through it with a straight face. The industry isn't there to solve anyone's problems. It is there only for itself.
-
On that note, Where is @ben_lubar? He was the resident Go advocate IIRC
-
@stillwater long story but short version is that he had a very profound disagreement with some people here, banned them and was ousted as admin.
-
@stillwater said in Going to the Google's walled garden with Go:
On that note, Where is @ben_lubar? He was the resident Go advocate IIRC
The Lubaring happened.
Wait, no... I think that was when he restored a backup and inadvertently deleted two weeks of forum history. Don't remember what the Ben, Interrupted event was called. Suffice to say, this is not the place to discuss it.
-
@Applied-Mediocrity my experience has been it will be rewritten in Java and then I'll have to maintain half a decade later.
-
@DogsB You misspelled Rust
-
@DogsB said in Going to the Google's walled garden with Go:
@Applied-Mediocrity my experience has been it will be rewritten in Java and then I'll have to maintain half a decade later.
That's been mentioned in the other thread, @carnage calling it the new COBOL. But what really is the alternative? I don't know a better option than Java that has a similar record of being long-term stable / maintained. Other than C/C++, of course, which aren't a better option for business apps either.
-
@topspin said in Going to the Google's walled garden with Go:
@DogsB said in Going to the Google's walled garden with Go:
@Applied-Mediocrity my experience has been it will be rewritten in Java and then I'll have to maintain half a decade later.
That's been mentioned in the other thread, @carnage calling it the new COBOL. But what really is the alternative? I don't know a better option than Java that has a similar record of being long-term stable / maintained. Other than C/C++, of course, which aren't a better option for business apps either.
If I were to make a guesstimate, Rust could possibly take over in a decade or two when it's grown a large flora of stable frameworks. But at the moment?
MS seems hell bent on ruining the .Net flora, otherwise that one is a pretty good alternative in MS world.Java seems to hit a sweet spot of being simple enough for low skill monkeys to bash functioning programs together, while performing well enough for most use cases, and having a mammoth library of... Libraries... to do pretty much everything well enough. And the tool chain is mature and well defined to a pretty much unrivaled level. It's also all fairly stable.
-
@Carnage said in Going to the Google's walled garden with Go:
MS seems hell bent on ruining the .Net flora
What's happening in the .NET world? Last I worked with it mid 2021 it was the only stack where I could go in, get stuff done, no headaches (If you don't count dealing with Azure SDKs). They fucked it up too?
-
@topspin said in Going to the Google's walled garden with Go:
@DogsB said in Going to the Google's walled garden with Go:
I’ll give it a read
Go not letting you do operator overloading, harkening back to the Java days where a == b isn't the same as a.equals(b)
No. That is a point in every language’s favour. Overloading an operator just makes a new maintainer’s life a misery.
Operators are just functions with a special name. Having to write
a.equals(b)is stupid when the language has an equality operator.This has my vote.
And I rather have overloading than running into truncation bugs because I wrote
absinstead offabsorfabslor ten other cryptic variations.That's a different kind of overloading, though. Perhaps. (Given that operator overloads map to functions, perhaps not.)
-
@stillwater said in Going to the Google's walled garden with Go:
@Carnage said in Going to the Google's walled garden with Go:
MS seems hell bent on ruining the .Net flora
What's happening in the .NET world? Last I worked with it mid 2021 it was the only stack where I could go in, get stuff done, no headaches (If you don't count dealing with Azure SDKs). They fucked it up too?
.NET Core vs .NET Framework
-
@Carnage They ruined it because they collectively moved on from .NET Framework to .NET Core?
-
Don’t discount the amount of stuff written in PHP…
-
This post is deleted!
-
@Bulb
FWIW, These are very well written articles. None of that shit you see on Medium. Why is the internet getting more and more full of crap these days?
-
@stillwater because everything’s a side hustle now. It’s all about making money for someone (including Medium).
-
@DogsB said in Going to the Google's walled garden with Go:
@Bulb said in Going to the Google's walled garden with Go:
@DogsB For maintainability it does not matter a iota whether you are overloading an operator
==or a methodequals. Both are equally bad if overloaded in an unexpected way. What's left is the cases where operators are more readable, so allowing operator overloading is a net win.It only got bad name because C++ and C# standard libraries abused operators for things that isn't appropriate. Which again isn't any different from using stupid method names.
Of course in the specific case of Go there is the other problem of comparing pointers or comparing the objects they point to, which ends up being kinda confusing in all languages that expose those two options.
Every feature has gotten a bad name from people misusing them but allowing a developer to overload operators has always struck me as skullduggery waiting to happen. You see readable, I think : “great, another developer whose decided he’s a language writer” and wish I could up the day rate. I should just need to know how the language works. Not the snowflake variation of it here.
So say you can't overload operator
<. So now objects that are supposed to be sortable have to define a specific method, say.less(), instead. And now some smartass programmer comes and defines a.less()method that does something different than comparing the objects. How is that different from them defining<to so something else?Unless you don't want to allow user-defined objects to never be sortable, but that severely limits the abstractions that can be built in the language, and that severely hurts ability to build larger programs in it.
I’m not saying languages should stop using it. Concatenation would be harder but putting it in the hands of everyday devs is just fodder for the front page and me upping my day rate.
I don't like when languages allow their standard library features that are not available for other libraries too. It just feels inconsistent and arbitrary to me.
The reason I passed on go back when it was starting was that it does this with hashes. Hashes are fairly complex constructs that can't be considered primitives but, instead of being constructed from actually primitive constructs (which require generics) in the standard library, they are built in. Because the language didn't want to have generics, but this one use for them was considered too important.
That, and the fact there are dynamic reference-type arrays, but no fixed-size value-type ones. For language that has value-type structs that is not consistent either.
@stillwater said in Going to the Google's walled garden with Go:
The cutting edge startups here use golang and pay like crazy. I would learn it if it means getting that job but everytime I've tried it for something even remotely non-trivial, it gave me a weird nauseous feeling.
They prototype in Go, because it has good whipuputitude, and then have to pay like crazy to get the people needed to put it to production, because it lacks the manipulexity.
That's basically just different words for what the article says.
-
@stillwater said in Going to the Google's walled garden with Go:
@Bulb
FWIW, These are very well written articles. None of that shit you see on Medium. Why is the internet getting more and more full of crap these days?We’re not willing to pay for anything and the pay-walled content that is good is not indexed on google.
-
@Steve_The_Cynic said in Going to the Google's walled garden with Go:
@topspin said in Going to the Google's walled garden with Go:
@DogsB said in Going to the Google's walled garden with Go:
I’ll give it a read
Go not letting you do operator overloading, harkening back to the Java days where a == b isn't the same as a.equals(b)
No. That is a point in every language’s favour. Overloading an operator just makes a new maintainer’s life a misery.
Operators are just functions with a special name. Having to write
a.equals(b)is stupid when the language has an equality operator.This has my vote.
But then either:
- The primitive types also have that method so generic containers can use it (either using dynamic or static polymorphism (generics)).
- Any generic container has to have separate implementation for primitive types, and those probably can't be covered by generics or interfaces.
- There are no generic containers.
In the first case, why is the operator even there? And in the other two, you are significantly restricting ability to build abstraction.
-
@stillwater said in Going to the Google's walled garden with Go:
@Carnage They ruined it because they collectively moved on from .NET Framework to .NET Core?
.NET Core went a bit hipster, though they did stop breaking everything every major release for now. And it does run on Linux and in containers, so Microsoft can sell Azure-hosted Docker container subscriptions.
It's not really compatible with .NET Framework though, so at my job we're starting a project of porting things to .NET 6 (new name for Core).
-
@Bulb said in Going to the Google's walled garden with Go:
@DogsB said in Going to the Google's walled garden with Go:
@Bulb said in Going to the Google's walled garden with Go:
@DogsB For maintainability it does not matter a iota whether you are overloading an operator
==or a methodequals. Both are equally bad if overloaded in an unexpected way. What's left is the cases where operators are more readable, so allowing operator overloading is a net win.It only got bad name because C++ and C# standard libraries abused operators for things that isn't appropriate. Which again isn't any different from using stupid method names.
Of course in the specific case of Go there is the other problem of comparing pointers or comparing the objects they point to, which ends up being kinda confusing in all languages that expose those two options.
Every feature has gotten a bad name from people misusing them but allowing a developer to overload operators has always struck me as skullduggery waiting to happen. You see readable, I think : “great, another developer whose decided he’s a language writer” and wish I could up the day rate. I should just need to know how the language works. Not the snowflake variation of it here.
So say you can't overload operator
<. So now objects that are supposed to be sortable have to define a specific method, say.less(), instead. And now some smartass programmer comes and defines a.less()method that does something different than comparing the objects. How is that different from them defining<to so something else?You mean how it works now in most sensible languages and the fun that brings. You're basically allowing people to take the letter A and pronounce it like q but it now works like e.
Everyone brings up these simple examples and not what you see on the front page. Overloading == to use .equals everyone gets on board with. Then some bright spark thinks: in this context the comparison needs an int two calls deep to be in this range too. I'll just hack it into the == and document it tomorrow. Never does. Then someone has a bright idea and does the same thing with a different range in five other places.
Bare in mind we don't trust most developers with pointers or manually cleaning up after themselves with memory. You're taking a fundamental part of the language and understanding code and allowing them to fuck with it.
-
@DogsB still, you haven’t pointed out how “does absolutely retarded thing in overloaded operator” is any different from “does absolutely retarded thing in overloaded method”. Except that typing
.equals,.less,.addgets really annoying.
-
@MrL said in Going to the Google's walled garden with Go:
@stillwater said in Going to the Google's walled garden with Go:
Why though? Can someone ELI5 why it might be technically considered superior?
Popularity of any given technology has nothing to do with technical superiority. It's all fashion, religion, ignorance and herd mentality.
Except for the FORTH user.
-
@DogsB said in Going to the Google's walled garden with Go:
Overloading == to use .equals everyone gets on board with. Then some bright spark thinks:
"I wish I could f with this more but they locked it down annoyingly hard in a library. Stupid Gribnit!"
-
@Gribnit last part, anyways.
-
@topspin there's FORTRAN too, and a lot of people claim to have a LISP.
-
@DogsB said in Going to the Google's walled garden with Go:
Everyone brings up these simple examples and not what you see on the front page. Overloading == to use .equals everyone gets on board with. Then some bright spark thinks: in this context the comparison needs an int two calls deep to be in this range too. I'll just hack it into the == and document it tomorrow. Never does. Then someone has a bright idea and does the same thing with a different range in five other places.
How is that different to them mutilating the
.equals()or.cmp()method the same way?The problem occurs when someone overloads
==so that it is not opposite of!=, so that<and>can both be true for some pair of arguments, that+=isn't the same as combination of+and=(I am looking at you, C#) etc.The proper solution isn't to not support operator overloading, the proper solution is to only allow overloading the related ones together. Or at least delegate them to each other by default, so when you overload
+, then+=gets defined consistently asx = x + y, and if you define<, then==,!=,<=and>=get defined correspondingly again.There are languages that do this right.
-
@Arantor said in Going to the Google's walled garden with Go:
Don’t discount the amount of stuff written in PHP…
You expect it to sell at market price somehow
