Go is Google's language, not ours
utcc.utoronto.ca
utcc.utoronto.ca
For a community-driven project from the size of a database some serious sponsors would be needed. Good examples are Rust, Linux, and PostgreSQL. I wonder why so many companies are happily paying Oracle (and the likes) tons of money instead of sponsoring an open source project like PostgreSQL.
Yes, the borrow checker is a PITA vs. Go, but there are compensations.
[1]: https://github.com/Manishearth/rust-gc [2]: https://github.com/withoutboats/shifgrethor
Sure you could argue that a company may have different incentives than a BDFL, but in this context, it's not clear that Go would've been more likely to accept the change you're proposing if they weren't being led by Google.
Edit: And to answer the question, no, there’s no philosophical differences. And there’s nothing wrong with that. Python never called itself a community’s language (there are instances core devs said in no ambiguous terms that it is Guido’s project). The problem only arises if a project gives an impression that it is owned by the community when it actually isn’t.
Rob Pike already stated publicly that he is against the proposed idea for Go 2.0.
"Rob Pike - Go 2 Draft Specifications" - https://www.youtube.com/watch?v=RIvL2ONhFBI
About using them as generics, how do you enforce constraints? Unconstrained generics won't lead you far (or better, will lead you far into JS's Wat territory).
> About using them as generics, how do you enforce constraints?
I'm really thinking about the case for numerical algorithms where the exact same code works for different types (say float32 and float64 in Go). It sucks to copy and paste hundreds of lines of code and it sucks to have a separate code generator write your file for you (essentially an external macro processor). Imagine something like the C preprocessor for Go, but without the well known flaws of the C preprocessor:
#define IMPLEMENT_FOOBAR(NAME, TYPE) \
void NAME(TYPE* ptr, long len) { \
hundred lines of implementation here \
}
IMPLEMENT_FOOBAR(foobar32, float32)
IMPLEMENT_FOOBAR(foobar64, float64)
As for constraints, you can pass function names as arguments too. For instance:
IMPLEMENT_SORT(sort_baz, baz, bazcompare)
For their first implementation of BIDS, initially provided with Borland C++ 2.0 for MS-DOS.
Finding out the release date is left as exercise for the reader.
Rob Pike is not a member of the Go team anymore, and he has not been for several years.
No, he moved to work full-time on Upspin: https://github.com/upspin/upspin
https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
> The phrase originated in 1995 with reference to Guido van Rossum, creator of the Python programming language.
[1] https://www.rust-lang.org/governance/teams/core [2] https://www.rust-lang.org/governance
Postgres (do we really still need the "QL" reminder?) has demonstrated staying power, and repays invested time in spades. Linux, obvs. Rust, it's still too early to be sure about. Learning it will be at least educational, maybe formative, and at worst it won't be taken away.
As an aside: The community needs an abstraction for WebAssembly's File System that has something like fcntl/flock functionality. As it stand's the Node interface for emscripten targets isn't good enough. Would love to see a bit more collaboration on this regard for sync and async interfaces for FS I/O that supports file/record locking in a more abstract runtime. Though this has been a pretty big shortcoming with Node since early on imho.
I have a hard time calling this a "community" project when the community is paid by corporations. Don't get me wrong, I'm not really complaining, as a project the size of a commercially viable operating system kernel is hardly a project that could be viable without corporate backing IMHO.
Actually, even ignoring PHP, I'm vaguely convinced it's generally better for a language to be backed by a company. I personally feel more secure knowing that there are people whose full-time job is to take care of the language, and I trust community backlash to deal with any errant decisions. I can't imagine Google (or Microsoft, or Apple, or Facebook) making or blocking a change in a way that kills an entire programming language while they sit idly by ignoring the community response.
Either a foundation is needed, which sets a vision and sticks to it, or a company, or a BDFL. But with none of them, you get each language faction pulling in its own direction, bits of each added/retained, and no coherence.
PHP has been developed very well the past few years as community project, there is an open RFC process with a codified voting process in place. Sure there have been some drama within the community, but that has not affected either the language nor the implementation.
What makes PHP a great fit for a community driven project is that PHP is a pragmatic language in its core. If the general goal of a project is to design a perfect & consistent language then a community driven process is maybe not the best approach.
It was a huge uproar in the community, but MS didn't care enough & this goes against TS idea that the community can stop a major company doing this sort of thing. It can happen & it will happen again.
However that does not mean that you shouldn't invest resources in a corporate language, it just a false argument to think it can't die.
Edit: changed disappear to die
"VB.NET is a new incompatible language, everyone invested in VB needed to retrain skills & rewrite existing software."
The VB6 runtime is indeed updated to run, but really how much update does it need beyond sticking the DLLs around? The VB4 and VB5 runtimes run perfectly fine on Win10 and those had no updates for it. It all relies on Win10's overall backwards compatibility.
VB6 isn't just the language, if anything the language is a minor part of it. VB6 is the entire tool, including the language, IDE and library. You cannot separate these, they are written for each other. This is also what pretty much all VB6 alternatives get wrong as they try to reuse elements designed for something else. You cannot do that and get something like VB6 beyond at a superficial level (and this is exactly what Microsoft did with VB.NET).
It is kinda similar to not understanding how something like a jury rigged Vim with a GDB, file list manager and ctags parser differs from a real IDE even after having used the latter. Usually i'd say "you need to experience the real thing" but if you do not get it after you do, then i'm at a loss of words.
I'm sad to see this opinion every time somebody mentions PHP. PHP may have its flaws. But how can anyone deny the instrumental role PHP has played in building the web as we know it today?
The open web, open source, open standards, agile were supposed to be the free market answer to all the flaws of the big old corporations. And for a large part they have succeeded in creating the new and better world we enjoy today. But it looks like we're experiencing some regression. The new big corporations of the web are becoming more like the big corporations of the past. Corporate structures, HR departments, Shareholder meetings, Management layers, system thinking are again replacing the success of uncertain organic growth models that involve chaos, diversity, agility, attitude and pragmatism. To see media outlets advertising social media handles as opposed to their web addresses. Purists are on the rise. Perhaps because everyone is seeking those comfortable high paying jobs at the big corporations?
PHP has fought and won its battles. Outfoxing many big corporate opponents along the way. It should get the respect it deserves. And if you ever find yourself at the front-lines of a new battle. PHP might still very well be your most effective weapon of choice. A worthy consideration at least.
Golang is one of the most pragmatic languages there is.
I know a guy who works with laravel, and we’ve teased him so much about PHP over the years, because PHP. The truth is, that his backend is actually more suited for the modern world than what we currently run. .Net core is getting to where it’s competitive, but it’s still a bitch to build something like a mixed asp mvc and Vue components app, which is truly effective/productive alternative to MVVM clients or jquery/Ajax for smaller projects.
It has some historical baggage that some people can't get over. Nothing, no programming language will be perfect. If I had to start all over, I'd probably use something else but it works great for what I'm doing. (web dev with Laravel)
I'd say "thriving community-based open source projects" are rare in the sense that most open source projects don't thrive (especially if you count every open-licensed repository on github), but there are tons of examples.
I think the balance is hard, you will need lots of resources from Documentation, VM expertise, Library, etc.
Of these, Javascript (w3), Python (Python Foundation), CSS (w3), C++ (ISO), Ruby (community), C (ISO), Shell (Posix), R (community), Perl (community), and Haskell (community) are not bound to a single company.
[1] https://redmonk.com/sogrady/2019/03/20/language-rankings-1-1...
Top 20?
This at least makes it easy to work out if incentives are aligned. Do I want to program in such a language? Yes? Then Google is probably not going to completely screw it up, even when they make decisions I disagree with. Do I like to wax rhapsodic about parser combinators? Not ever going to be a good fit.
Well does PostgreSQL offer anything like Oracle's CDC?
Edit: Nevermind, I just read up on using a WAL replication slave with triggers.
Because that are plenty of nice enterprise features that PostgreSQL still doesn't cover.
For my use case it’s a no brainer because only PostgreSQL have a decent GIS extension, last time I checked Oracle was lagging well behind.
- The IDE experience with PL/SQL, including graphical debugging of stored procedures
- Compiling PL/SQL to native code for better performance
- Running bare metal without an underlying OS
- Oracle RAC
- The fine tuning options on their JDBC and .NET drivers
- A proper C++ driver API
Enterprise software tends to have lots of features that the majority of folks will never encounter in their career. The enterprise market space is composed of around a thousand potential customers world wide, all of whom are large enough to have sophisticated and complex internal computing environments. They have varying norms, requirements, workloads, regulatory environments, industry standards and so on and so forth.
Each has a lot of money and rejecting the requirements of one company often means you are effectively rejecting several, or perhaps even an entire sector. So you add something to cover them and before long, your software has the union set of features required solely by enormous companies.
From a non-enterprise view a particular feature may seem like absurd overkill. But someone, somewhere, needs it and there is a long and often impressive story of how it was achieved.
-Nobody gets fired for buying Oracle. -It's easy .. explaining an investment in open source .. good luck
I can think of environments where you'd get fired. Oracle these days screams "legacy", and especially if you're working on low-latency projects like trading systems it would be a huge, expensive mistake.
Nah, even when Oracle was more dominant than they are today, that wasn't entirely true:
https://www.cnet.com/news/california-cancels-oracle-contract...
https://seekingalpha.com/article/4229086-oracle-growth-dead
If Oracle revenue is no longer growing, maybe new development leans more towards Postgres and other open source offerings?
Even not growing, they are indeed paying Oracle.
Corporate world is ruled by liability. When you are working on a multi-million dollar project and the database breaks, you want to be able to put as much responsibility on the 3-rd party as much as possible.
Open Source projects come with no guarantee. If someone hacks into a system because of a flaw in the Open Source project you are screwed. If it's a software delivered by Oracle, then Oracle is responsible and needs to pay your million dollar fine.
Of course I'm simplifying, because there's probably still a lot of legal process behind it depending on the country, but it's essentially that.
Has it ever happened though? Genuinely curious.
This is not really true. AFAIK there is no commercial software that has a license clause making the manufacturer liable if you loose your data due to faults in their product.
We lost a couple of TB due to bad OS/firmware in a NAS. The manufacturer did everything they knew trying to fix it, but in the end failed and we lost the data.
Once we lost a crucial virtual machine and backups due to human error. It was not the manufacturer of the virtualization solution that helped us get it back, because they did not have such tools and did not provide such services. Hackers who were reverse engineering the software and publishing their reversed code on the net helped us get the VM image back.
After these two and some other situations I am even stronger proponent for open source, because with open source you have the option to try help yourself if the manufacturer won't or can't help you. I am not just proponent, in fact if I was to be involved in decision making, it would be open-source solution throughout. Of course with support. If possible I'd pay for support services to the original developers.
1. All the work is done in public, with a license that gives zero protection to the original authors.
2. The project leder (myself) only does OSS work and has no other roles in the sponsoring company.
3. The roadmap is decided by the community (myself with feedbacks from the community), not a company or some product manager or alike.
4. There are multiple people from multiple companies contributing regularly code to Redis: Redis Labs, Alibaba, AWS, ...
5. The main web site is handled by the community.
In the case of Redis this was possible because of the minimality of the project, otherwise I agree that's a huge challenge. But still IMHO Redis deserves to be listed in such "purely community" OSS projects.
I like that there is a tight cohesive group in control over Go and that they are largely the original designers. I might be more interested in alternative government structures and Google having too much control only if those original authors all stepped down.
They are actually trying to pick the implementation that solves real world issues, not just trying to tick [x] Generics in the Go spec sheet.
It's ok to have this opinion, I just disagree with it. I do agree that it's important to think it through, I do not agree that the language should be brought to 1.0 without it.
...what in the world makes you thing that? I love parametric polymorphism, but nothing stops you from writing the most complex computer programs you can imagine without it.
Sure, you can do that with punch cards as well, but there is a reason we've collectively moved beyond them.
Go literally special-cases generic builtins because they couldn't be arsed to properly implement it but knew nobody would accept completely untyped core collections.
You seem to be conflating type-parameterized collections with generics. You can use generics to implement type-parameterized collections, but it doesn't really make sense to think of type-parameterized collections as a form of generics unless you can actually abstract over the type parameters (which you can't in Go).
Go does have generic collections, and generic functions operating on these collections.
> You cannot e.g. write a generic Go function to reverse an array.
You can if you're part of the core team and implement them as builtins. Go doesn't have userland generics, because users of Go are peons who can't be trusted with sharp implements.
> which you can't in Go
Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths.
>Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths.
This can't really be the right explanation given that generics are now being added to the language. In any case, this kind of mean-spirited speculation about people's motives is borderline trolling, IMO. The Go team have publicly stated their reasons for not (initially) putting generics in the language. Unless you have some inside info suggesting that they're lying, I'd refrain from saying this kind of thing.
Go absolutely has this feature. Just not for you as a user of the language.
> It has some built-in operators that can operate on multiple types.
Go has multiple builtin functions which abstract over type parameters e.g. close() can operate on any chan, append() or copy() can operate on any slice. They are not operators (symbolic or keyword).
> Most languages have this. The arithmetic operators in C, for example, can take operands of many different types. This is not "generics".
It's overloading, +(int, int) and +(double, double) are separate functions under the same symbol. It's an orthogonal feature, so much so that there are plenty of languages which do have userland generics and don't have overloading.
> This can't really be the right explanation given that generics are now being added to the language.
The core team has been saying they're considering the feature / issue pretty much since the language was first released. You'll have to excuse me if I don't hold my breath.
That seems like a roundabout way of saying that it doesn't have the feature.
>It's overloading
You could just as well regard Go's close, append, copy etc. as overloaded.
> The core team has been saying they're considering the feature / issue pretty much since the language was first released. You'll have to excuse me if I don't hold my breath.
They've come out with a specific generics proposal. I'm not sure why you would think that they're not serious about implementing it.
It looks like you are in golang core team's minds. You appear to be able to judge intent. Impressive quality you have here.
Not at all, Rob Pike stated it fairly explicitly if in somewhat milder terms:
> The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
Pike himself is a user.
Edit: we've had to ask you half a dozen times in the past not to post aggressively and uncivilly on HN. Would you please fix this? Reviewing the site guidelines should make it clear what we're looking for instead.
Whether this is the right decision for this specific issue is a different story. But the fact that they aren't checking boxes for the sake of it is evidence of this style WAI.
It is not unthinkable that there could exist other programmatic tools that would be able to solve the same real world issues.
Personally, I am very happy with what Go offers today, I would rather keep a small and simple language, which allows me to concentrate on doing work, rather than trying to keep up with features added to the language. I am not even sure, I want generics to be added to the language, until they come up with a really great concept which maintains the simplicity of the language.
Or phrased it in another way: with all the years of experience on generics, they still got them wrong when implementing generics for Java, e.g. with the type erasure.
"In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."
https://go.googlesource.com/proposal/+/master/design/go2draf...
Now when Go 2 gets generics it will be used for all kinds of applications and frameworks, which is fine but isn't really filling a void. I expect the ergonomics (e.g. wicked fast compiles to single binary) to be better than current app dev langs. I stopped using Go and look foward to trying it again. Even then I don't think it will be one of my favorites and likely used for smaller work. Long-term I want Pony to succeed. Medium term I'll take Kotlin, Elixir, or Dart.
This is the best argument for move from C++ to Rust instead. No "move constructors" whatsoever, move semantics are the default and are always performed via a trivial memcpy. There are explicit .clone() operations, like in some other languages, or the move construct can implicitly copy when the type is a POD-equivalent that makes this possible (identified by the Copy "trait"). Very simple, and nothing like the whole C++ move mess.
Move constructors are one of the worst parts of C++ and being able to write movable, intrusive data structures is absolutely not worth the cost. If you do need one, Rust shows that it's better to sacrifice movability than introduce move constructors.
This is not uncommon -- there are some things you can do in C++ that you simply cannot do in Rust (either safely, or at all). Usually there's another, better way to achieve the same overall goals.
Move constructors fix a narrow problem, which is, when you have something like a vector append, how do you copy over all the previous elements as a "shallow" copy rather than a deep one?
In C with realloc(), it's just assumed that memcpy works for that. With C++03 and earlier copying the elements could very well end up duplicating everything on the heap for no reason, then discarding the old copy.
How does rust do this? What I am reading from googling is that every assignment is a move?
Since Rust always enforces that a move is a memcpy, a vector reallocation is just a realloc() like in C.
Also, Pin is stable but async/await is not, so you’re backwards there :)
Here's an example I put together demonstrating this: https://play.rust-lang.org/?version=stable&mode=debug&editio...
That'll clear it up for you. It's a very good book. rvalue references are a bit muddy but move semantics should be clear.
Do you have Stroustrup's blue book?
I belive this means that using this mechanism similarly to try/except in Python is not possible (I write 20 lines in go so this is quite a wild guess)
Go team said many times that generics are technical issue, not a political one. (see [1] by rsc (Russ Cox from Go team))
There are also stories like experience report of Cloudflare outage due to the lack of monotonic clock support in Go that led to introducing one. [2]
The way how Go team handles potentially tectonic changes in language is also exemplary – very well communicated ideas, means to provide feedback, and clear explanation of how process works. [3]
Plus, many people in Go community do not want generics in Go (at least, in a way they're implemented in other languages). Their opinion also matters.
[1] https://news.ycombinator.com/item?id=9622417
[2] https://blog.golang.org/toward-go2
[3] https://go.googlesource.com/proposal/+/master/design/go2draf...
Sometimes, of course, this does not work out for the best.
So we have
a) Google having problems with lack of monotonic clock in Go
b) Go team reluctant to break API and break promise of compatibility without really serious reason
c) community feedback in form of well written experience report, explaining how serious the issue is for the community
d) immediate reaction and efforts to find a solution (without breaking API)
Even though team was dismissive of the idea, feedback from the community made them to change their minds.
That's not learning from established work.
Second, since early days of Go, they said that acknowledge their Google monorepo bias, and can't implement package manager that works for everybody without understanding what people outside of Google need. They consciously gave time for community to grow and mature and get enough feedback before implementing proper solution, while actively studying package management solutions from other languages.
I definitely can't call it "refusing to learn from established work". Of course, they could've just copy existing suboptimal solutions without properly giving it a thought – that's what most of the languages do, after all – but that's where Go choses another path.
The author's primary complaint is the way Go modules were handled, namely that one member of the Go core team overrode the entire community.
Yet uses it as an opening line to build the whole argument on.
> PS: I like Go and have for a fair while now, and I'm basically okay with how the language has been evolving and how the Go core team has managed it. I certainly think it's a good idea to take things like generics slowly. But at the same time, how things developed around Go modules has left a bad taste in my mouth and I now can't imagine becoming a Go contributor myself, even for small trivial changes (to put it one way, I have no interest in knowing that I'm always going to be a second class citizen). I'll file bug reports, but that's it. The whole situation leaves me with ambiguous feelings, so I usually ignore it completely.
Everything felt like it was there on purpose. It always seemed like there was a "proper" way to achieve something. Being told to use this opinionated formatter was like removing a 40kg bag after a bush walk. You never have to worry about if you're writing Go "the right way", because it's extensively documented what that way is.
Generics is an awesome feature, writing C# is my day job so sometimes I miss it, but I have full faith in the designers when they say it will be in the language in a "Go appropriate way". The last thing I personally want to see is Go being handed over to the community to be designed by committee.
You don't look through a window in your house into the backyard, and plant a tree in the backyard by fiddling with the window. It's the same with arrays and slices in Go.
If you want to insert an item into a slice, insert it into the array (by copying to a new array and adding your new element to it while copying), then creating a new slice which includes your addition.
edit: (adding for clarity) In a lot of programming languages, whether they use slices or not, arrays are of a fixed size and must be copied to a new array if you want to add elements. Some languages have some syntax that makes it feel like you are modifying an array in-place, while doing the copy to a new array behind the scenes.
edit-edit: for an implementation example of the above, see Java's ArrayList class: http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/...
It's that or some magic with larger-than-needed arrays that automatically grow by a bunch extra every time they hit their boundary to make appends faster, while blowing up memory use and making append performance unpredictable.
Lots of (especially) scripting language hide this behind automagic and you see tons of append-in-a-loop where it's not really necessary, as a result.
[EDIT] had insert two places I intended append. Me need coffee.
names = append(names, "Bob")
However, as time went on, I noticed a few trends. Firstly, forcing me to think more revealed that what I had thought was automatic was more automagic - Go forces you to take responsibility for what your code does to a far greater extent than other more convenient languages, albeit not to the extent that C/Rust does. Secondly, I noticed that code written in Go tends to do what I expect it to pretty much all the time (with the occasional except of async stuff). Sitting down and writing a program in Go often results in something that actually works the first time it runs, and has far fewer runtime surprises.
As painful as it is to do numerical computation in Go sometimes, I have a very high level of confidence that I can look at a program, deduce with some accuracy its runtime memory usage & footprint, multithread it easily, and reason (successfully) about possible runtime failure modes and behaviour. This is something I find difficult if not borderline impossible to do in Python, especially utilising the standard '10 layers deep' stack of numerical computing libraries.
What company do you work for by the way if you can say?
It can be that your learn a language better, became more comfortable with the way it must be used: say, stopped writing code in Elixir the way your used to write in Python.
But the other thing is that it's in our human nature that we tend to look for something positive in bad situations we exposed to for a long.
Say like, PHP was a fractal of shit, but when you use it for a long you will notice that it will make you more aware of what functions to use and how not to fall into some undocumented craphole, be more responsible, and do not take it for granted that some function would work flawlessly. The obvious benefit from the shitty situation.
EDIT: Grammar
Making computers do things is fun (usually)! The programming language is (almost) immaterial - depending on the task at hand of course.
Despite myself, I've even found myself enjoying JS in the few times I had no choice to avoid it. shudder
(I still hate it occasionally, but there's a lot more joy these days.)
The initial turning point was probably around the first release of jQuery...
I did not write this. My fingers did not type it. Nothing to see here. Move along. I'm a hedge.
Well, the basic parts are not that great. Plus, it has almost nothing of Scheme (nothing more than e.g. Python has of Lisp), that's just an old wives tale. It just has closures and that's it. Scheme is a Lisp, whereas Javascript isn't [1]. Not sure what Brendan had in mind when he was inspired by Scheme, but the end product is nothing like it.
Coercion rules are crazily bad. No integer type is stupid. Prototypal inheritance nobody much cared for (where nobody = very few). An empty array is not falsy. And several other stupid decisions besides.
The only reason it wasn't that bad, is that it wasn't big enough to be bad. It was just a handful of features plus a tiny (and bad) standard library (some math, some string stuff, etc). Everything else people had to build on top (and usually the did it badly).
[1] https://journal.stuffwithstuff.com/2013/07/18/javascript-isn...
Or, you can avoid the minefield entirely.
-- unknown
Isn't that also a classic example of "boiling the frog" or Stockholm Syndrome?
There is a point about diversity to be made here. Different design models will each have their strengths and weaknesses, and the design spaces each opens up are not going to be fully explored if one model prevails. So I'm glad there's a language like golang with a coherent centrally-planned vision behind it in existence. It's also good to see more community-driven models get to do their thing. We'll see over time how each develops and what problems they best solve. It does seem to me to be a 'let 100 flowers bloom' type situation.
A bit of a bland centrist view perhaps, but with systems as complex as programming languages and their associated libraries, ecosystems and pragmatics, it's really hard to know what works. Best to experiment.
Strings in C++?
This is how I feel about prettier.
> The last thing I personally want to see is Go being handed over to the community to be designed by committee.
I feel this way about many projects. You can’t beat good stewardship/vision, and sometimes it’s corpotate.
I personally don't see Go and Elixir's primary domains as being equal, or one a superset of the other. So there's some argument to be made about the region where they overlap, but for something inherently based around fault-tolerance and distribution, seems to me that code written to run on the BEAM will be smaller and clearer and therefore more maintainable.
But in any case, Elixir allows a lot more clever code. In my experience working on legacy software, clever code in a dynamic language is error prone and hard to refactor and maintain. Static typing can help, though, I've found this especially true in functional languages where you have a super smart developer do something clever that's hard to understand 5 years later.
Maybe Go does have good primitives or libraries for that, and I'm just ignorant of that. :)
I'm thankful for exactly that. Go is developed by Bell Labs people, the same people who bought us C, Unix and Plan 9 (Ken, Pike, RSC, et al). They took the time to think through all their decisions, the impacts of said decisions, along with keeping things as simple as possible. Basically, doing things right the first time and not bolting on features willy-nilly simply because the community wants them.
Reminds me of Joe Armstrong's quote: '''I remember thinking “how simple, no qualms of conscience, no soul-searching, no asking "Is this the right thing to do” …''' source: http://harmful.cat-v.org/software/OO_programming/why_oo_suck...
Exactly and it comes in line with other research languages, namely Newsqueak and Limbo, both relying on channels for concurrency. I hope their other work will also find their way into every day usage though.
The earlier languages that Rob Pike et al were involved with, Limbo and Newsqueak, were also heavily influenced by Wirth.
[1] https://talks.golang.org/2015/gophercon-goevolution.slide#15.
I rarely have to think much about how to write the code itself, just about the actual problem that I'm solving. Once I know where I'm going, there's really only one way to write the code for it. Reviewing and using a co-workers code is also a breath of fresh air.
I think languages fall on a spectrum with regards to both typing and expressiveness, and it's not good to be on either end (e.g. PHP vs Scala or C vs C++) the designers of Go were very disciplined in walking that line and struck a great balance. I'd hate to see that undone by turning it over to a committee which results in a million compromises that turn a language into a Swiss army knife of features. It needs that strong guiding hand and the discipline to say no most of the time. Go has become my favorite language, I just wish I get to use it more in my work.
Bingo. This is also what the designers of Smalltalk, Ruby, and Python were trying to achieve. This is the opposite of C++, where I find that I'm thinking about the how all the time. (And at least 25% of the "agile" process time is spent on this activity in explicit reviews.)
This probably scares people whose livelihood depends on managing complexity in other languages. If anyone can get up to speed quick, anyone can potentially make the program that eliminates the need for that complexity.
I don't know that Google had this in mind while developing Golang, but they stand to benefit from commoditizing development. This is fine for someone like me who has zero interest in it as a career but does use a lot of scripts and plugins for creative work. Right now it's $10+ every time I want to do something with music/video/art where free or included stuff doesn't work or doesn't exist. If every DAW, video editing suite, and art/graphic design program had a scripting language as easy to use as Golang, I would never need to pay for add-ons.
The markets would still exist, but they wouldn't be as lucrative. Pricing would go from value to commodity.
I think the gofmt approach is becoming an unofficial standard. In the JS world 'prettier' has taken off and I think most languages now have a community anointed formatter (and new languages are likely to have an official one).
Why is that?
I thought your comment made a lot of sense.
Personally, I like go a lot for writing services and console applications.
Types, it has int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64 and also float32 and float64.
If you use anything besides int, int64 or float64 you will just have a lot of fun casting.
math.max() and math.min() only work on float64, you can easily use it with different types, and actually it is discouraged to use it with integers. So you need to roll your own if you want to work with integers. But ok, it is math so when you do math apparently you should work on floats because that's what scientists do, but then why it doesn't work with float32? You actually have to cast like
result := float32(math.max(float64(left), float64(right))
If you want to convert a string to an integer, you have nice strconv.ParseInt() where you can specify among other things a bitSize, great, but the resulting type is still int64, you will need to cast it. What about other types, using them is a nightmare, if they were not supposed to be used why not just have int and float type?
If you try to implement a data structure that stores objects, you either have to duplicate the code, use interface {} (looks like that's most common, but then you no longer get help from a type checker) or use generator (this seems best to me, but it is just automation of the first approach).
I don't understand why Go is getting so much good opinions, it is not an enjoyable language to program. The supposed killer feature which were go routines and channels are kind of meh and nothing that you couldn't replicate in other languages. Seems like people like its simplicity, does that mean the other languages are overwhelming?
I feel Go's 'opinionated' language design insults my intelligence.
Generics and zero-cost abstraction can and are concepts that are often abused instead of used when it makes sense. I hope thay Go will never support generics because I sincerly believe it might mean the end of the language
Also, I have no expertise in your field so forgive me if this is a stupid question but wouldn't generics be easier to check over since they allow there to be only one implementation of something for all types versus in Go, a bunch of different implementations of the same thing that you have to check and might have subtle errors?
As soon as Go adopts generics the community will turn on a dime and pretend they always loved generics (and perhaps even invented them.) That's how these sort of things typically play out. See also, copy/paste on iphones. When only android had it, copy/paste was a misfeature for idiots. When iOS implemented it, copy/paste became the best thing since sliced bread.
It's just you can't implement your own hashmap in Go, and make it compile time type safe.
Then it doesn't support generics. That is the entire point of the feature.
no, Go doesnt' support generics.
Perhaps there are other ways, but in C you have parametric polymorphism functionality through macros. That's why min() and max() are not functions but macros and they work with any type that can be compared, not just float64.
that's a really puzzling statement to me, maybe aside from C, C++, and Java, (and maybe rust) Go is certainly on the "more verbose" side.
My interpretation is that Google employs a tight-knit group of people that work on Go and collectively are the BDFLs of the language. This isn't that much different from most large OSS projects, although it does seem likely that this core team weights the opinions of those that they interact with daily (ie, other Google employees) over people they barely know.
What will, on a long enough timeline, come up in board meetings, especially as Google fails to meet Wall Street analyst's expectations, and as the ad-tech space evolves, is how much of Google-the-corporation's money to continue plowing into broader community things, like Golang at all.
Hopefully, by the time that happens, the community will be strong enough to persist, and I use Golang professionally, so I have personal investment for that to be true, but the possible eventuality that it'll end up being in the situation Java is currently in, makes me nervous.
They could have just asked.
In fact I can answer this for you, since I was the relevant director (IE Go directly reported to me)
It was driven by the core team, and more particularly, the leads and what they want to be trying to do.
I have provided precisely 0% of the vision there.
Further, the org/etc they belong to has changed (a very small number of times) over the past 10+ years depending on the Go team goals, not depending on Google's goals.
(IE when their goals have changed, or the org goals changed, Google has put them in a place that aligns with their goals, not tried to align them to the goals of the org they belong to)
Google makes it free to use, so it will be easier to recruit people that already know it. Many companies do that as well, the difference is that still generally no one uses their languages. This one is different, because well it's Google. The Go itself isn't really that great language, but there's a lot of hype behind it. I wonder when it will die out, but I guess it will be a while.
For reference, Go was meant as an alternative to Java and C++, to develop distributed systems. Given the direction that Java went, acquisition by Oracle and $10B lawsuit against Google, it is a well worth having an alternative.
- If someone new joined Google, would they immediately get added to the core team, with no history of contributions?
- If someone had a long history of contributions, but wasn't hired by Google, could they join the core team?
Those two questions are pretty determinate on whether this is a community project or a Google project.
- Maybe?
A better question is, "Can you successfully act like you worked at Bell Labs in the 70s and 80s?"
Bell Labs invented Not Invented Here syndrome. You can know this to be true because there is no way this group of people could have the syndrome so bad any other way. The other side of the coin is that they are very, very good. You can know that because they do a lot of interesting, novel work without obviously (or obviously without) having looked at any other research in that field.
Take for example, Chris's comment, "(The most clear and obvious illustration of this is what happened with Go modules, where one member of Google's Go core team discarded the entire system the outside Go community had been working on in favour of a relatively radically different model. See eg for one version of this history.)"
The second link there is to https://peter.bourgon.org/blog/2018/07/27/a-response-about-d... From that: "[RSC and the dep-pies] discussed dep at the GopherCon contributor summit. Matt Farina says that [Russ Cox] said [he] could do better if [he] went off on [his] own and built something. ... The clear impression was that Russ wasn’t going to engage with the committee, the research [the committee] had prepared for him, or the prototype product of that research, dep — at least, not yet. The clear impression was that Russ had his own hypothesis about what a solution would look like, and that he was interested in validating those hypotheses, by himself. ... Russ decided to implement his ideas on his own, and make a proposal without us, and without telling us that’s what he was doing until it was essentially done."
This is what I'm talking about. If your ideas suitably mesh with their philosophy, they may be adopted. If they do not, the Bell Labs team will ignore them completely. And if they think the problem is a problem (and they don't, in many, many cases), they are quite capable of doing an end-run around you and producing a solution which satisfies their perception of the problem.
Go may or may not be Google's language. Go is the Go-lang team's language and you will go where they want you to go, to adapt MS's old slogan. To an extent, it's similar to Perl; one's success as a Perl programmer depends entirely on your ability to hold your mouth right and successfully simulate Larry Wall. Perl is not a DWIM language, it's a do-what-Larry-would-mean-if-he-wrote-what-you-wrote language.
[^1] I myself do not endorse the technical ideas in that post. "[Something] does not support using multiple major versions of a program in a single build. This alone is a complete showstopper." is true. The fact that most tools don't do it---and have to live with the resulting pain---simply means that it's hard, not that it's not necessary.
[^2] A previous discussion of Go modules here: https://news.ycombinator.com/item?id=17534923
It needs close parenting. Java has been ruined by the push to include everyone's pet feature.
Isn't that C#? Java is very slow at adding new features, Java has only things that were proved to work in other languages.
Those surely are not the proof that Java adds "everybody's favorite feature". I think the parent means the newest Oracle projects (Valhalla, modules, value types, streams, and so on).
I do appreciate, though, that when Microsoft decided to do generics for C#, they did so decisively. These days, when C# gets a new feature, it seems like it's the complete opposite of decisively delivered.
class A {};
class A<T> : A {};
There are performance implications to type erasure, to be sure, but when our computers are mostly all future machines from beyond the moon, I'm more interested in minimizing the impedance between my brain and a solved problem.
http://gafter.blogspot.com/2006/12/super-type-tokens.html
At its root, the real problem here isn't "reification good" vs "reification bad", per se. Haskell has an excellent implementation of generics, and erases types far more aggressively than Java does. C# also has a very good implementation of generics, this time based on reification.
The problem is more that Java's particular mix of design decisions resulted in a language that operates at cross purposes with itself. Once upon a time, back in the beginning, Java was a reflective language. Being reflective requires type information to be available at run time, though. When Java decided to use type erasure in its implementation of generics, they created a really bad set of interactions: They kneecapped reflection, so now you can no longer call Java truly reflective; it's only partially reflective. You can no longer effectively and accurately reflect on what have come to be some of the most-used classes in the language. And, at the same time, they forever sealed a rather important corner of the type hierarchy off from generics. They also delayed a bunch of type checking until run time - after types have been erased - so that certain things can just never be made to cleanly type check. Meaning you also can't say Java is any more than partially generic.
Oracle is moving to a faster cycle of development. There are some of us who strongly feel that some of their decisions are based less on what's best for the language and more on catering to the popular-and-loud crowd. I'll never forgive the addition of `var` to the language.
I'm inexperienced with Java and didn't know this existed until I saw your post. It seems like a nice shorthand to me. Can you explain why you don't like it?
And there you have the answer to why Java hasn't evolved that much, or when it did, why it needed to care deeply about backwards compatibility at the source level. It's because Java developers want it that way.
The irony is that people are now abusing "aspects" and "dependency injection" via frameworks like Spring that bring everything but the kitchen sink, but then the language becomes effectively dynamic, as via those annotations all static type safety goes out the window.
Therefore I find it interesting when Java developers complain about Var, because the ecosystem has in my opinion bigger problems. Compared with annotations Var isn't a problem because Var is statically checked, so here we have a clear case of missing the forest from the trees.
You're right, there are loads of conservative Java developers. It's one of the the things that makes me love using the language.
> The irony is that people are now abusing "aspects" and "dependency injection" via frameworks like Spring that bring everything but the kitchen sink, but then the language becomes effectively dynamic, as via those annotations all static type safety goes out the window.
> Misconceptions mostly.
But drop the strawman argument and borderline ad hominem. It'll do you better.
Consider these contrived lines of code:
```
String first = someMethodCall();
var second = someMethodCall();
```
The first provides more useful information at a glance. I don't see any value in the "nice shorthand." Typing out "SomeStupidClassName" has never once been a material bottleneck in my 15+ years of programming, but now we have this new option that caters to the lazy, and in doing so makes life harder. Now I have to either ban it, embrace it, or come up with some ruleset around when you can and can't use it. Why? Someone can't be bothered to type a few extra characters.
It reminds of my grandfather, a former professional ball player, but one who played back in the days where there weren't these multi-million dollar celebrity ballplayers pissing and moaning in the press about just how hard their life is. He used to call those types "high-priced cry-babies," and I really feel a tinge of that in dealing with folks who just wholly embrace `var` and give folks like me shit for having criticisms of it. Perhaps that's just my old blue-collar showing but your convenience in writing a handful of characters simple will never enter into my considerations.
I love using Java, I love the addition of things like streams, the Optional type, etc. My sibling comment is a little right, and very wrong. Lots of Java developers have a certain conservatism about them, I'm mostly certainly one. But there are large reasons to hate it.
> [D]rop the strawman argument and borderline ad hominem. It'll do you better.
There are a few rather glaring spots that I've noticed.
First, when you're refactoring, you've now got to edit every spot where a variable of that type is created. At the very least, when you're just renaming a class, your IDE can help you, but you still create a lot of diff noise. At worst, when you're splitting up a class or otherwise shifting responsibilities, you may end up with a whole lot of yak to shave. This is not just an annoyance; it's a latent code quality problem, because it creates a disincentive to clean things up.
Second, I've seen it become an impediment to writing clean code in the first place. I have encountered situations where it's clear that the author wrote
someMethodCall(
withOutputOfSomeOtherMethod(
thatTransformsTheOutputOfYetAnotherThing(
basedOnThisInput)));
I've even seen it result in situations where data gets copied or otherwise processed excessively, because the explicit type annotation resulted in an upcast that shed some useful feature that a subsequent developer shimmed back in because they trusted the explicit type annotation and not a function's actual return type.
So yeah, I decry your assertion that this feature is about being lazy. This feature is, at least for me, about code quality.
If a language encourages bad patterns by making good patterns overly verbose, the language should address that.
OurConfabulatorWithADashOfSpice confab = new OurConfabulatorWithADashOfSpice();
var confab = new OurConfabulatorWithADashOfSpice();I really respect the slowness of the go maintainers in adding new stuff. I also suggest that we all ponder our tooling some; Writing java with emacs or vi is a materially different experience than using eclipse or idea and var style type-inference seems almost silly with those tools which do it for you.
It's not so much the extra typing that's the problem, it's the extra reading. All the stuttering is visual noise.
But they still somehow keep finding ways to make them not work so well when implemented in Java.
C# may move faster, but its design team is also much more methodical about ensuring that new features have good ergonomics. In Java, I tend to feel surrounded by hacks that were hastily slapped on in an effort to keep up with C# and, increasingly, Kotlin.
I appreciate that by moving faster they get more stuff into more hands faster, but they definitely have a lot of hackish solutions with poor ergnomics outside of the narrow scope they were originally intended for.
If you will: the language features have a clear purpose but a general implementation; and outside of the narrow purpose the designs usually feel pretty poor.
E.g.:
- LINQ/expression trees don't support most of the C# language, and new language features are usually without equivalent expression tree. This isn't a full lisp or F# style quotation, but a pretty narrow window that's not easy to use outside of linq-to-sql style usages.
- LINQ trees are again intrinsically inefficient, since the expression trees compile not to a statically shared expression, but to a bunch of constructors (i.e. looping over even a medium sized expression is bound to be slow); and they're not equatable, so it takes a lot of effort for a consumer to detect this case leading to overly complex (and hard to reproduce correctly) hacks inside stuff like EF.
- LINQ is restricted, but the restrictions are fixed, not customizable. That makes it a poor fit for DSLs, including stuff like Entity Framework, because there are usually lots of expressions your DSL can't support, but there's no way of communicating that to the user. Also, if you use expressions as DSL, you need to follow C# semantics, which isn't trivial; witness gotchas in ORMs surround dealing with null and equality.
- lambdas are either delegates or expressions; not both, and this isn't resolved via the normal type system, but by special compiler rules, making it hard to do both, and leading to type inference issues such as that var f = (int a) => a + 1; cannot compile.
- Roslyn: very poorly documented, and ironically very dynamically typed to the point that many casts or type-switches are necessary but finding out what types there are and what they do is generally a matter of trial and error since the docs aren't great. Ergonomics are poor in other ways too; e.g. dotnet is xplat, but the build-api is not - i.e. it's clearly not dogfooded. Also: totally not integrated with expression trees, which is at least mildly surprising.
- string interpolations are unfortunately quite restrictive (compare with e.g. javascript, where this was implememented much better), and intrinsically and unnecessarily inefficient (at least 2 extra heap allocations, and usually lots of boxing, and the parsing the compiler necessarily must do is not exposed in any kind of object tree, but instead reserialized to string.Format compatible syntax necessitating re-parsing at run-time). Also, like expression trees, this was really hacked into the language, so, e.g. you can't participate in other normal C# features like overload resolution the way you might expect, extension methods plain don't work, culture-sensitivity can be a gotcha: basically this works for immediately evaluated expression, but is tricky elsewhere.
- razor (not strictly C#) is hugely complex, and has a very impractical underlying model. Compared with e.g. JSX which is trivial is (ab)use creatively, and which uses mostly language-native constructs for control flow, razor makes it impossible to use even basic features like methods to extract bits of common code; lots of basic programming features are reimplemented differently. Instead of passing a lambda or whatever, you have to deal with vaguely equivalent yet needlessly different stuff like partials + tag helpers.
- optional parameters are kind of a mess (no way to enforce named args, no way to cleanly wrap optionals, restriction on compile-time constant, interaction with overloads can be suprising); tuples are too (names are dealt with differently than everything else in the language, no syntax for empty or 1-elem tuples, no way to interpret arg lists as tuples or vice-versa, no checks on nasty naming errors like swapping order); equality is a mess (how many kinds are there again?), lots of apis are disposable but should not be disposed but for others it's critical, no good way to compose disposables, huge ever expanding api without practical deprecation path is a pitfall for newbs, no partial type inference for generics, no unification of all the various func-and-action variations means billions of pointless overloads (and sometimes per-API ways around it); tuples and anonymous objects are sort of redundant, but not entirely; no good way of implementing equality/hashcode/comparability and yet easy way to detect misused non-equatable types.
I mean, I respect their choices here, and there's a tradeoff with lots of benefit too: they're really quite fast-moving, and I want those new features ;-). But it's not without costs; they definitely aren't "much more methodical" or anything like that.
I look at the feature list in the latest iteration of the language, and my thought is, "Y'know, you really should stop when you're done."
Java is not trying to "keep up." It is intentionally slow-moving and conservative (this design goal was set by James Gosling when Java was first created), and only adds features once they have been proven in other languages for a while.
On the other hand, what I consider a major mistake from Java side was ignoring value types and AOT compilation since it's inception.
Had Sun blessed such features since the beginning, and many use cases for C and C++ wouldn't be necessary.
As to baking variance into the runtime, I think this is just a bad idea, which is so far used only in C++ and .NET, two languages/runtimes with notoriously bad interop (it's not just Scala; Python and Clojure have a similarly bad time on the CLR, as would any language not specifically built for .NET's variance model). It is simply impossible to share a lot of library code and data across languages with different variance models once a particular one is baked into the platform. This is too high a price for a minor convenience.
Specialization for value types (which are invariant), is another matter, and, indeed, it is planned for Java. Perhaps some opt-in reification for variant types has its place, but not across the board. I am not aware of other platforms that followed in .NET's misplaced footsteps in that regard. Those that are known for good interop -- Java, JS and LLVM, don't have reified generics.
What's worse is that it's a mistake that cannot be unmade or resolved at the frontend language level. Even Java's big mistakes (like finalizers, how serialization is implemented, nullability and native monitors) are much more easily fixed.
There's a reason java had built-in value types from day 1, because it made sense even back then.
Frankly, I think both java and C# kind of got this wrong. There was an overreaction against the C/C++ of the day, and whereas the GC turned out brilliant, the idea that it's not even necessary to express the notion of references/pointers/values etc. was too much; and the idea of a single type system root (object) is similarly dubious, and then particularly the idea that that root type isn't the empty type. Object has semantics, and that was a mistake, because it contributes to the bloat. I'm totally happy with ignoring those features 99.9% of the time, but having them completely unavailable makes those 0.1% cases extremely expensive. (I mean, I think those things are slightly changing, but it's slow going).
AOT compilation not so much, given the NGEN constraints.
However they got it both wrong, considering CLU, Modula-3, Delphi and Eiffel are considered influencial languages on their design.
That was necessary for performance back then. User-defined value types weren't, and Java has done well without them.
> Object has semantics, and that was a mistake, because it contributes to the bloat.
I think most of the RAM bloat is due to the GC trading off extra RAM for speed rather than object headers, and I'm not sure trading off complexity for headers was right 25 years ago (JS is doing fine on the client without value types). What changed was the performance characteristics.
As to object semantics, it may be a fixable mistake. The goal is to get value types without today's object semantics while preserving a single class hierarchy at the same time. The Valhalla team thinks that's achievable.
All of them refer that having value types alongside GC had a relevant impact improving performance.
All systems designed before Java was a thing.
Or since you refer to JS, the paper about SELF's design.
Even Dylan was designed with AOT/JIT and value types support, which is relevant here given that its domain was being a systems language for the Newton. That politics killed it is another matter.
I don't know why there was no emphasis on AOT back then. I guess they started with interpreter/JIT, and then there just wasn't much demand for AOT until now.
QuickBasic supported value types and AOT to native code, and while Visual Basic used P-Code, version 6 introduced a proper AOT native compiler.
Modula-3 was also a big influence, at least accordingly to some papers.
There was surely demand for AOT, given that most commercial JVMs had it in some form or the other since 2000.
Even Sun actually supported it in Java Embedded variant for OEMs, probably grudgingly.
Common Lisp certainly has support for value types.
As for AOT, there may not have been sufficient demand from Sun/Oracle. I only joined relatively recently, but we generally do expensive things only if we believe they have a huge benefit or in huge demand, and we believe it can be long-lasting. The assumption is that any new feature will require maintenance for 20 years, taking away resources from other things. So if something is expensive, even if it's cool or some people could find it very useful -- we don't do it. The assumption is that the ecosystem is large enough that others can, and will.
I can check the respective manuals if you wish.
Yep, I did VB programming for a short while.
And please note that even though my focus is now elsewhere, Java is one of my favourite eco-systems.
As a peasant I just wished that Java 1.0 was more like Go, given the existing alternatives back then.
So it kind of stayed as a pet peeve of mine.
Same applies to .NET, just in a different way.
However due to the hardware architecture changes and new kids on the block, it is starting to be an issue.
I keep wishing to see them arrive, have watched all the JVM Language Summit, Devoxx and JavaONE talks about them.
Meanwhile I can already enjoy them elsewhere. :(
That's perfectly fine. We think that our priorities are right for the workloads Java is used for (e.g. people care more about a low-latency GC like ZGC, and deep low-overhead in-production profiling, like JFR, than about AOT).
Value types were pretty much obvious as necessary.
More so when one dives deep into how languages like CLU and Mesa/Cedar were designed.
Having a AOT support doesn't preclude having a JIT as well, like Common Lisp or Eiffel already had in 1995.
Gosling said that his goal was to have nothing you can somehow live without (I don't know how well early Java lived up that ideal, but that was the ideal). Hardware changes made user-defined value types absolutely necessary for workloads Java wants to target.
If I recall correctly it even depended on WINE.
Are there any plans to fix those?
C# i s one of the best dev experiences in any language/IDE
[1]: Maybe not C# programmers, but there are easier ways to do a single-language runtime.
Go's goroutines seem okay - but I don't like how much control they take away from the programmer. For example, last year I worked on calling-into a black-box C DLL from a Go program and we learned the C DLL had code that was actually simply terminating the thread inside of it (by design!) because the author of the C DLL assumed ownership of the thread. That caused a problem for us because Go's goroutines are scheduled by the Go runtime and it will never let you give-up ownership of a Go thread - and I couldn't see how I could use my own thread (e.g. getting a thread from a native OS call to keep it outside of Go's control) with goroutines. The project was almost DOA after we learned this, fortunately we convinced the author to always return instead of killing the thread. I'm not sure if anything's changed in Go since then that would have made things easier for us. But since then we haven't used Go for anything new. The only reason we used Go was because it gave us binaries that "just worked" for Windows, macOS and Linux without having to worry about Java, .NET and other dependencies - but I wasn't happy about the ~20-30MB-sized executable output.
Care to expand on this? Java is very careful to release new features.
Java has made a U-turn in adding streams and related functional features on top of a language that used to be strongly for OOP (actually defining the meaning of OOP for a generation of developers.)
These different paradigms together make for code that does not read the same no matter who writes it.
I love how Go code usually ends up being extremely similar, no matter who write is. (Actually, Kubernetes is a counter example for this: Go should have gone even further in forcing style.)
If you think that "all code reads the same" is detrimental to developers, you are conflating the idea of developer (problem solver) to that of coder (keyboard typist.)
So, by adding a feature which works extremely well with OO and enhances the language they have no soul? That doesn't make any sense. Javas soul is being a blue collar language. It leaves the experiments to other (JVM) languages and takes the parts which have been shown in the field to be useful for many cases.
Go on the other hand is a half-finished Java, produced for the sake of saying "We are Google, OF COURSE we have our own language".
One package is written in the "new" functional style, another is written in "old" object oriented style, other parts use classes for nothing more than name spaces to house static methods. The reality is it's already a mess.
But isn't that just an inevitable outcome of aging? The only way to never age is dying young.
And practical use of Java had stopped being textbook OOP (which means using classes to model the world and putting your logic where the data is) long before the streams API etc came along. Actually the shift away from textbook OOP integration between logic and data already started when the beans pattern drowned us in getters and setters, which already happened when Java generics were still the Pizza language sitting as a draft on Odersky's desk. I even suspect that lack of generics was a confounding factor in that shift, because when you look at a pre-generics codebase (which I happened to do just yesterday) you will find that the brave men and women back then spent an enormous amount of boilerplate just for hiding untyped collections behind typed facades which is a form of using OOP features (meant for modeling the world) for program structure, which is basically what post-textbook-OOP Java is all about.
A design philosophy. Some sort of measurable practice that influences design. This is not limited to Java. Design by committee has been destroying the maintainability of many languages.
Streams are inspired by some idioms of functional programming. But they are not functional, and they cannot be made to be functional, because it is impossible to evaluate one without causing a rather glaring side effect.
I want expert code to be concise and uncluttered. When everything reads like a novice wrote it, that's a problem.
Your comment is the problem with the Go community. I have seen a number of comments from Golangers that they want a "fun" language that helps them reminisce about the past. They also want to write a lot of senseless boilerplate because for them more typing is somehow about them reliving their past. And tracking down nil pointers... and writing containers for every concrete type.
The simple fact is software development has gotten more complex because business requirements have changed and Go does a poor job of addressing that with its limited feature set. The rest of the programming world has accepted that we need better tools whether it be toolchain stuff or language features. Hate on Java all you want but at least it, like most other non-Go languages, has realized the need for better tools in the toolbox.
Sure, and the "right tool for the right job" is still my mantra. Go is a very good at solving for an incredible amount of tasks in many problem spaces. Users will always want to bend tools to work in new places, and that's okay -- sometimes it isn't a fit.
Have some business requirements that make using Go a chore or a pain? Use a different language, or restructure the requirements.
That's such a cop out answer when our industry is basically doing fad-oriented engineering. It's great when you can greenfield build a project but when you're taking over a project the selection of language has usually been decided. Or you know the management team has decided for hirability reasons to use X. Or just legacy requirements don't match reality eventually.
This is why we need more expressive languages than Go. Requirements change over the course of a projects life and what made sense in year 1 rarely makes sense several years later.
This isn't the first time google open sources internal tools, trying to build a community but really ignoring them completely. GWT, Closure compiler and of course Angular comes to mind.
Angular built a great momentum and community, and the angular team at google basically ignored most ongoing concerns to work on their next big project that'll fix everything (first it was Object.observe, then dart then angular 2).
Contrast google's handling of Angular to Facebook's handling of React (and react-native) - The routinely incorporate community influencers into the core team, they include other major corporations in their decisions and community, actively engage in developer relations to get feedback, explain controversial choices and build a community.
Sun's model with Java is even more different - incorporating major stakehodlers in the language into the actual decision process via the JCP.
Of course Google isn't the only ones who are bad at building developer communities around their open source. Apple and Amazon barely even try.
If google is Ivory tower, Microsoft is the Herbalife way of building a developer community - actively supporting influencers, providing official seals of approval and using a top down hierarchy of advocates. They do listen to community input a lot more, but Microsoft is still the overlords of all their projects.
The things mentioned as evidence that community doesn't matter have a lot of buy-in from the community. Modules in particular are an effort that - at least from what I can tell - is heavily driven by non-Googlers (in particular Rog Pepe, Paul Jolly and Daniel Marti are people who put a lot of work into making modules actually work for practical workloads).
These kinds of pieces only make sense if you have an extremely limited view of who is or is not part of "the community" - in particular, if you throw everyone agreeing with the Go team out of that bucket.
I would say the main drivers of Haskell these days are academics, PhDs and consultancies.
Haskell is a complex language, with an expressive type system giving you more tools and guarantees but I would call the learning / dev experience everything but streamlined.
I wonder whether the difference in the organisational structure (single entity vs community) manifests in the characteristics of these languages.
Can you create a Haskell compiler that is faster than GHC? Probably. Can you create one that is fast? I'm much more skeptical of that.
[1]: Edited, thank you maxiepoo.
"Avoid (success at all costs)" or "(avoid success) at all costs."
Squeak Smalltalk had this. "Burn the diskpacks!"
I'm confused as to what's stopping someone from forking it, calling it OpenGo, and building a community around that.
But adding features to Go by popular demand would make it a new language and a new ecosystem. So if that is what people want, they should go ahead with it. Even if it just is an engineering prototype, which showcases features that Google should add to the Go main line.
I don't think this is necessarily true. There are a lot of fuzzy factors that go in to making a language successful and it's tricky at best to get these right, even if openGo was a better language.
As a practical example, go effectively has one person who's full time job is keeping the testing infra happy. It'd take time and money to establish this in a go fork and going without it would make development of the fork much harder.
Isn't that part of the fundamental conundrum though? If your need is so great, and so common, and so beneficial to get solved then the cost of development should be less than the benefits accrued, and smart business would bring that money and time to bear on the challenge and solve it. As Google has done with the main project...
Saying there isn't time enough or money enough to solve the technical challenges sounds like saying those challenges aren't important, or valuable, enough to be prioritized. Which is to say our wallets are in agreement with Googles wallet on the issue of generics in Go.
The considered 'best approach' from the community isn't the best technical approach to the technical issues, it's the best balance of pragmatic solutions for produced benefit (ie ROI), that create a sustainable project/product.
There's one exchange in a blog post linked from the article[1] about dep/modules that I think is illustrative of the entire issue (double >> are quotes in the article from Google/go, single > are commentary from the linked blog author):
>>Although it was a successful experiment, Dep is not the right approach for the next decade of Go development. It has many very serious problems. A few:
>>Dep does not support using multiple major versions of a program in a single build. This alone is a complete showstopper. Go is meant for large-scale work, and in a large-scale program different parts will inevitably need different versions of some isolated dependency.
>Russ [a member of the Go team] has asserted this from day one, and has brought several examples out in evidence, but has simply not convinced the committee that it’s true. Calling it a serious problem, let alone a showstopper, is a significant overstatement. The strongest claim that can be made on this point is that it’s a matter of opinion.
That, to me, is that. Go is Google's language, and Google said that for them, not supporting multiple versions of a dependency was a showstopper. The community read that and saw it as a point for debate, and the author continues to try to debate it in the article.
And that's the issue! It was not a point for debate. Google was being forthright. Google was saying "from day one" it was a literal showstopper, and the community seems to have read it as a figurative showstopper. Who was right in this instance is irrelevant; if the community wants to litigate Google's decisions rather than integrate them into their tools/patches/etc., then the community will not get those things adopted into go.
[1] https://peter.bourgon.org/blog/2018/07/27/a-response-about-d...
For a long time people on the C++ standards committee insisted that we need trigraphs because it had to support systems that didn't even have ASCII. We still don't have pragma once as a standard replacement for include guards because other people seem to compile on some crazy network typologies where it cannot reliably identify files. Taking every "literal showstopper" serious without questioning its merits gets you stuck with C++98 and a lot of quickly accumulating legacy cruft.
This has zilch to do with not being community led, so perhaps the complainers should fish for better arguments. Rust makes the exact same call wrt. this particular issue, and it's very much a community-led language, with a public RFC process.
The only thing we don’t allow is multiple copies of dependencies that link to native libraries, and the -sys pattern means that this is rarely an issue in practice.
1. Yay!
2. Yes, native libraries would be difficult. Or impossible.
3. Could you elaborate on the "-sys pattern"?
I am happy that similar kind of situation did not prevail for that long in Go's case.
And the final Java module system is much less flexible than OSGi (which is much more than a module system, which in turn is both a strength and a weakness in this case). Or do Java modules support multiple versions of the same package?
And that new language would be Go++ (i.e. Go with generics) and what would be wrong with that?
Consider how C++ started.
It was nothing more than a preprocessor extension to the C language called C with classes.
There is nothing stopping that Go++ turning into the Go equivalent of C++.
So back to the previous OPs question, what's stopping someone from forking it?
So when tasked to write his distributed network application in C at Bell Labs, his first step was to build something that would bring his Simula back, instead of bare bones C.
As with many open source projects under benevolent dictatorship, this can result in streamlined and consistent features with long-term success.
Actually, the community disagrees on stuff, so you're unlikely to get what you want, regardless. The only way you always get what you want is if you write your own language. (Assuming you're skilled enough to implement it.) But a language nobody else uses is of little benefit.
There needs to be some core team that makes coherent decisions. Unless the community is tiny, the core team is not the community. There are inherently tensions. However it's unclear that Go's core team is doing worse at listening to their community than other language's core teams?
Democratic creation of software would be a disaster. There's so many philosophies of development and differing opinions that you wouldn't be able to make progress. At the end of the day the reason a language exists is to implement the vision of those who created it. The community is a labor force to implement, test, and verify the decisions made by the heads.
I totally encourage people to write their own languages though. A language no one uses can be beneficial to computing at large as experiments in language implementation. We all know silly languages like Brainfuck that you would probably never use for work, but can be useful learning tools.
Many models around how those disagreements are resolved exist across many projects. You can choose one of them or build your own project and make your own decisions :)
Dismissing valid criticism with “just fork it if you don’t agree” has got to be some of the most useless advice parroted around open source.
We can hope that draft 2 of Error Handling [2] won't look anything like draft 1, for reasons such as [3].
[1] https://github.com/golang/go/issues/29934
[2] https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback
[3] https://medium.com/@mnmnotmail/golang-how-dare-you-handle-my...
> The most contentious point of the original design was the special-case handling of a trailing ": %v", ": %s", and ": %w" in the format string, which did not follow the usual printf model in which the meaning of % verbs is context-independent and all non-% text has no meaning at all. We will remove those special cases from Go 1.13.
At least, they removed the really ugly special cases!
[1] https://github.com/golang/go/issues/29934#issuecomment-48968...
(from the article) I think the high-level point that Python has not been tied to a company is true, but it's not been true that Python is "Guido's language" for decades. Python has a very effective community process. Guido has certainly served as a tie-breaker and of course as BDFL (no longer!), but I see the language being largely steered by the community and community leadership.
I don't like any language, but tbh I hate go the least, and I believe this is because few very very dedicated people with enormous amount of experience can simply make unpopular decisions.
But Go is one in a long line of proprietary languages that those of us who have been around the block know to stay away from. Recently: Java was Sun's, C# is Microsoft's, Swift is Apple's, Go is Google's. With any luck, all will be footnotes in ten years. Those of us who knew better than to get invested in them will be fine. Everyone else gets a chance to learn something.
Maybe they do now, in this decadent era of Lite beer, hand calculators and "user-friendly" software but back in the Good Old Days, when the term "software" sounded funny and Real Computers were made out of drums and vacuum tubes, Real Programmers wrote in machine code. Not Fortran. Not RATFOR. Not, even, assembly language. Machine Code. Raw, unadorned, inscrutable hexadecimal numbers. Directly.
(It's a joke...)
Go is the language that taught me to really appreciate writing things in Java.
What? Python's peak (2.7) has come and gone.
Java is also used by Facebook, Microsoft, Salesforce, Apple, and many other companies that aren't necessarily known for their Java development.
Java usually is the base for every core banking system that's not old enough to have been written in COBOL (and even those are being migrated to Java in many cases) or hasn't been written from scratch in .NET.
The same Java is also used by governments throughout the world.
If Oracle vanishes completely tomorrow, there's huge incentives for a community initiative to completely take it over ASAP. There's probably tens of billions of dollars in existing code bases that have to be maintained and extended.
More than that, Java's already 23 years old. It's not a new language. Plus: https://en.wikipedia.org/wiki/Lindy_effect
So not just all the big corporates but plenty of tech companies like Facebook, Uber, Spotify, Twitter, Linkedin, Netflix, Apple, Google etc all rely heavily on it.
I think also it's inaccurate to call any of these languages proprietary. They are all open source and if you wish you can fork them and make your own. C# in particular is now run by the dotnet foundation which is nonprofit with elected board seats, putting it in a better place for governance than many community driven languages.
Ios development is a walled garden. C# is barely used except to target Windos. Go? Too early to say. If it did fade away, who would miss it, really? Its express design purpose was to be not powerful enough to make big mistakes in. Has it transcended that? If so, what is its purpose now?
Java has shown staying power, despite its shortcomings, although its connection to the Apache Foundation ("where projects go to die") offers just a ray of hope.
The Unity game engine use C# for scripting; I wouldn't call that "barely used".
Anything less than ten billion lines counts as "little used".
How big is Unity?
Also Xamarin which if I read this [2] correctly owns a third of the mobile app market. I don't know whether that's credible but apps are a huge market.
It is possibly that could get you the 10 bn. It is quite certain that there has been more than 10 bn lines written on.NET Framework, probably far more, as for 15+ years it has been the dominant language for corporate apps built on the Microsoft stack.
On top of that.NET Core is growing much faster over time,according to their blogs, and it's cross platform as you know.
[1] https://www.google.com/amp/s/techcrunch.com/2018/09/05/unity...
[2] https://www.datanyze.com/market-share/madp/xamarin-market-sh...
I know I get a little absurd towards the end but no more so than your remarks about Java.
Now they are driven by ISO Standards bodies, with many, many participants -- ATT not among them anymore, to my knowledge. Even in 1995 ATT had nothing approaching veto power.
My remarks lumping Java in with C# and Swift are transparent wishful thinking.
If you have a contractual obligation that requires to exactly use a specific version of C/C++, then you'll need to pay money for the actual specification. In pretty much any other situation, the drafts are sufficient and perhaps even better (because they will have incorporated some errata).
I'm sure you were perfectly aware of it, but C and C++ working drafts are almost identical (I think? Never bought an ISO version), and available for free from open-std.org. For example, http://www.open-std.org/jtc1/sc22/wg21/docs/standards
I’m not saying it was all terrible nor that Go is managed better. But whenever there is a conversation about Go on HN people get so caught up in their own snobbery about how terrible they perceive Go to be that they lose all touch with reality.
The fact remains a language backed by a company is far less likely to die into insignificance than a language that isn’t. This is because it takes a lot for a language to gain momentum. You have a bit of a chicken and egg problem where developers won’t use a language without a good ecosystem, frameworks and community. But people aren’t going to write that if there aren’t already developers using it. This is where corporate sponsorship really helps.
Thankfully there are a plethora of good languages out there you can choose from. If you don’t like the direction of one language then you can use another. Or, alternatively, since Java, C# and Go all have open source compilers, you could fork and build your own community.
Having said that, just because it exists in Julia does not mean it can exist in Go. I just wanted to mention that there are exceptions to the rule which begs the question if it is a rule in the first place.
Java isn't dying for a while either - anyone who still needs to support applets aside, or corporate applications written when Java was the fashionable thing to ship apps in, Android's install base will mean it's relevant for a fair stretch yet, even if OpenJDK fell into the sun tomorrow.
Swift I don't have much insight into, as I haven't done much with OSX or iOS in a while, and I have indeed not seen much uptake outside of those.
Which languages are you suggesting were/are good targets?
Python is technically not one company driving it but a bunch of developers on it are employed by large companies to work on it.
JavaScript is seeing a bunch of use in a great many places, but originated with one company's implementation and development.
Rust is pretty obviously one company's child, even though it is seeing decent uptake from other users. No predictions on whether it would survive said company dropping their work on it, though.
Java and C# are not going anywhere, especially now that .NET works on OSX and Linux. Swift, unlikely. Go, still uncertain.
It's fairly short-sighted to criticize a language and hope it dies out in usage just because a corporation is chiefly responsible for it.
I won't put survival rating for it to be very big. I'm sure Apple would keep it for decades to come, but I'm wouldn't bet on it being anywhere near as popular as it is now in the future.
Swift is actually a very pleasant language, and apple provides some pretty good documentation although it could be better.
It's going to play out like this: Swift or Objective-C (for legacy codebases/people who already experts in objective-c and don't want to switch), and some other, slower languages that will always be second class.
That would mean its fate would be tied to iOS, which is used only on phones built by a single company. When that company stopped producing mobile phones, or decided to use a different operating system, the language would die.
I would be inclined to say no, it's rather unlikely, short of apple somehow suddenly going bankrupt.
TensorFlow also has a Swift API in development [3]. The people at FastAI seem quite excited about it [4].
[1] https://developer.ibm.com/swift/
[2] https://github.com/IBM-Swift/Kitura
A lot of the tools in the modern ops ecosystem are written in Go, and that trend is not slowing down. Not even going to start to list them. A lot of devs also love Go and it has a very nice community. If you would have said this 5 years ago? Sure - but now it's past the 10y mark in age - I think it's safe to say Go isn't going to go away any time soon.
1. https://news.ycombinator.com/item?id=8733705
The lack of generics makes Go uniquely unsuitable for functional programming, an unfortunate outcome when functional programming is the New Cool Thing.
1. Compared to most compiled languages the toolchain is very easy. 2. Reduced ways of solving things in the language itself.
My main dislike of C and C++ is that there are numerous ways of solutions for the same problems, this forces me to weigh the solutions constantly against things like "Is this a safe way, does it create fast code, will this way fit when my project is further or must I constantly refactor my code". The extreme flexibilty of C and C++ are more a burden for me than an asset.
Go made me enjoy the programming again. And of course, managing modules is a very difficult task so it had to be done somehow and somehow really, really good and I think they delivered the working solution. Various previous attempts were bad for various reasons (Kubernetes can tell you).
Having said that, Go's license allows everything and it would be interesting to see a fork and compare it with the mainstream a year from now.
More precisely, its design belongs to a small number of capable people who are on the same page, with regards to a pragmatic, minimal-ish design. This is better than a "benevolent dictator," in that there are some checks and balances. It's also better than design by mass committee from the public.
Suggesting that we should split the community for a feature that you like in other languages is a dumb and lazy argument.
I love open-source and libre software but there needs to be some central authority who oversees the changes and is forward-thinking. I actually love Go in the way it is and it wouldn't be it if you kept asking community what features to integrate. I am looking forward to generics as it solves some cases (containers holding items of a templated type sharing some common methods). But even if Go stayed the way it is, I would be fine. The point of open and libre in this project for me is that Google can't shut it down and that's enough for me in the case of prog language.
Please, if you want to make super-crazy-new community-driven uber-language which will change the world, make yet another and truly yours language or join Rust or whatever more community-driven language you like. Thank you! :)
In an alternative timeline where Go was not sponsored by Google, deciding what to merge into it and what to leave out would fall into some sort of "Core Team". In that timeline, if that Core Team decided to not include the features that the article author is describing, then we would have an article titled: "Go is The Core Team's language, not the community's".
I can only offer one answer. Maintaining an open source project is a lot of work. If you care enough about those changes, make a fork, include those changes, and maintain it yourself. If that's too much work, then you are stuck with what others able to dedicate the effort decide.
But that’s all just my personal opinions. What I found interesting was the callout of OpenJDK as a community-run language, but is it? I feel like OpenJDK is the worst of both worlds. Too much corporate overhang, and all the worst aspects of design by committee. But YMMV.
I value individuals and companies sharing their developments with a community. One has to remember though, to own something is different from benefitting from other's work, and if you want to have a say, you'll need to get your hands dirty, fork, and work.
Take Umbraco, for example. If someone were to port it to .NET Core and rewrite parts of it to use Postgres as a db option there would be zero reason to ever use WordPress again.
Most of the time, in my experience at least, someone that wants cheap hosting and is using something like .NET or Python will Google "cheap python hosting" and see what is cheapest/recommended.
PHP tends to be the outlier, because it's absolutely everywhere, but I think the web has matured to a point where people will look for specific hosting for their choice of tech. Hell, back in my freelancing days when I used to rebuild broken WP builds, most people that weren't given hosting by their client chose it from looking up "cheap wordpress hosts".
Nowadays I am able to use PHP 7.x, so I just keep using it there, and suggesting it for the less tech savy friends that want some kind of dynamic website.
Because while I do build sites in Java and .NET, I do accept that they aren´t that easy to set up at most ISPs, and cloud based one click solutions tend to be more expensive.
So it really depends on the purpose of the project, who else works on it, what it needs to integrate with, etc.
Thinking about what I use, C# didn't even come to mind. I only used it when required in school or when interning in companies that run Windows. I've written some C# on Linux at home but it's not much more than my experiments with Brainfuck were...
Strong central leadership is great, but leadership needs to actually listen to the people they're leading (and not just as an after thought).
Also a huge fan of go mod over vgo so I had no issues of them scrapping the community dependency manager and rewriting it to be part of the language
This is laughable. Anything built within Google belongs to Google. There's no way the company will let anyone from the core team leave and take the language with them. Keep in mind, Google's version of Go and the community might be vastly different, as the former has different needs versus the latter.
There is someone who need to govern the project. This is a company in these cases.
The only other option I see is some board like (in case of .NET) the .NET foundation to allow more control.
They extended plan9s c compiler with some syntax Sugar for co routines and fixed some whacky c stuff then threw in some gc.
There's new and innovated about golang.
They just had to open source golang because they used the plan 9 c compiler which was open source.
So ... much like Linux where Linus is the gatekeeper, and he decides what goes in and what doesn't, and also abuses people while at it?
[1] https://medium.com/@valyala/open-sourcing-victoriametrics-f3...
Python looks most promising and I already worked with it, but I am not sure yet. Can anyone recommend a viable alternative for Go? Any web-focused language that is performant, modern andalready well used?
Python is good for algorithmic stuff and things that need specific libraries (tensorflow, NumPy etc)
But if you want a garbage collected language for moving bits from place to place over the network, it's kinda hard to beat Go.
I mean, Java and all the JVM based languages comes to mind. Python, Ruby, Node.js (assuming performance isn't at the top of your list, which for many it isn't).
Go has a small community compared to all of the other popular languages.
I wouldn't worry much about "performant" though.
I'd pick Go among those every day of the week, but it's not perfect.
If there are no major non-Google contributors to Go, then the fork may not be successful due to lack of familiarity with the code base.
Then you rather do some new language.
Python is mostly an application programming language. It competes with Java, Ruby, C# and those kind of languages. Python also has tons of excellent libraries for a wide variety of specific domain areas, like Machine Learning (perhaps most famously at the moment), but also many others.
If you want specifically web-focused, Javascript or Typescript are the obvious places to go. Nothing is more web-focused than those two.
Often enough it seems like companies go out of their way to deal with open source just for the "cred" and hiring opportunities that it brings. The open source itself is a just a drag on their internal team, which has to deal with tickets and contributions they don't want or need.
For example, FB doesn’t use DraftJS on mobile, so it took a whole year long effort and a person who used to work for FB to fix mobile support. They just didn’t need it, didn’t have resources allocated to dealing wit it, and were understandably unresponsive on the subject. Now maybe they can use it in the future on mobile if they want, but they would have just fixed it if that need had ever arisen for them organically.
Maybe this is just an inherent problem for all company focused languages/frameworks (react, golang, kotlin, etc), and we need a good example of how to make it work for everyone
Thanks God, we have Javascript, and maybe Rust.
Best language to write multi-threaded apps.
What is being proposed as the alternative here?
In both aspects, just compare .NET/C# with PHP.
And yeah, I'd rather go with .NET/C# over PHP any day (although I understand PHP is getting better and better, which is good to hear.)
I developed PHP till 2007, then as a hobby project in 2013. Massive improvement. And I heard very good things about performance the last years. Swoole even can compete with the top tear languages
I'd be surprised if any new language becomes prevalent in less than multiple decades within Google's unfathomable scale.
For some things Democracy is excellent (governance of nations, because it might be the least bad option). For other things a dictator is good (Amazon seems to be providing a lot of societal value under Chairman Bezos) . For yet other things perhaps a motivated group of technocrats might be better (Go).
I don't suggest I know the answer definitively. I could be wrong. But Go's results are good. Perhaps it would be fair for me to concede that I should examine this question again in 10 more years. What is good for 5-10 years might show problems in 20-50 years time.
After all, even communist North Korea was a relatively functional place for a time.
Some hard decision was made for the better of the language and its users at the end. Thank you for the courage taking the hard decision.
If want to argue, argue that other package manager do better job than modules instead of community did effort and it goes for nothing but experimental.
The whole point of Go is to be small and opinionated and committees can only produce outcomes that are large and inclusive of all opinions.
Go at least has gcc-go, which is a compliant implementation that gets some benefits from being part of GCC (like not completely broken support for dynamic link libraries!).
Having a second compiler implementation forces the language grammar and behavior to be specified in a formal manner that allows anyone to understand how it works.
OCaml and Haskell are one-horse towns, with substantial history, that are not going away.
But as Stroustrup says, there are languages people complain about, and languages no one uses. You generally end up better off investing your time in mastering a language people complain about. Bitterly. Once that meant FORTRAN.
The Go language is defined by a spec with compatibility guarantees, but beyond embedded systems and WASM, there don't seem to be a lot of use cases for alternate implementations.
Let's don't forget the fact that Huawei had legally binding contracts with all those US suppliers.
Until then, it's a bsd inspired license. And you get code from Cox, Griesmer, Taylor, Pike, Hudson and Clements under those terms. It's a big team on several aspects.
So you can remove your tinfoil hat and check the code for yourself. It is valuable.
Essentially Google gets "free" developer time as people work on problems and pitch in possible solutions. Google can influence what is worked on by whining about things, and they are free to take or discard the offerings.
This isn't particularly surprising to me as it feels very similar to the way I felt when working there. Which is that people in engineering worked on projects that they were passionate about, but whether or not those projects got support, or were shipped, or released into products. That stuff was all done "elsewhere" by some group of people who were generally known, but not really part of the day to day. I tended to think cynically of them as 'class A' shareholders, or 'class B' shareholders[1].
I don't think there is anything wrong with managing a program this way, I do however think they go out of their way to create a community illusion to foster more participation. That tells me that if they were up front about things, they feel people might not be as eager to participate. To the extent that they are deceptive in their communications, that I would consider wrong.
[1] Class B shareholders get to vote on shareholder issues, but there is always more voting power in the class A shares so that the class A folks can veto or reject any notion they dislike, no matter how popular with the class B folks.