211–220 of 679 posts
Earlier quoted context omitted.
No, but it's very likely that they'll make decisions that'll alienate the community and thereby cause it's ecosystem to lose more and more relevance. It has done that with other open source projects they stewarded.
If they alienate the community, the community can fork it, right?
Then you rather do some new language.
Actually there are relatively few real (TM) open source projects driven by the community, at least if you look at important projects. Many open source projects are just commercial projects driven mainly by a single company. Look for example at Redis, MongoDB, MySQL, and Elasticsearch. They follow exactly the model described in the article. Technologies like these could have been developed by a community, too, but it…
> 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. Because that are plenty of nice enterprise features that PostgreSQL still doesn't cover.
Earlier quoted context omitted.
"Java has been ruined by the push to include everyone's pet feature." Care to expand on this? Java is very careful to release new features.
It's not about being careful (they are--but always with the baggage of backwards compatibility), it's about not having a soul. 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 writ…
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".
I'm going to risk being labeled an ~incompetent dev~ or whatever but learning golang was seriously a breath of fresh air compared to literally any language I have ever tried to grok before. 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 worr…
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.
Earlier quoted context omitted.
Most languages I can think of have one very dominant implementation and maybe another one or two that few people use. Python, Ruby, Java, C#, Go, Rust, Haskell... C/C++ are the only exception since Clang became serious competition to GCC and Visual Studio. Even Javascript only really has Chrome and Firefox.
What about Intel's compiler for C++? Or Borland's? Or EDG's? Or DigitalMars? They were around for a long time.
Earlier quoted context omitted.
If they alienate the community, the community can fork it, right?
Only if there are major contributing developers who do not work for Google. Is that the case with Go? 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.
Earlier quoted context omitted.
Most languages I can think of have one very dominant implementation and maybe another one or two that few people use. Python, Ruby, Java, C#, Go, Rust, Haskell... C/C++ are the only exception since Clang became serious competition to GCC and Visual Studio. Even Javascript only really has Chrome and Firefox.
That's "consumerization of IT" for you. Millenials and younger are used to looking at pretty websites of "language ecosystems" and blogs about trivial programming problems to assess languages, rather than independence, maturity, and long-term viability as they used to before, and as demonstrated by having language specs and multiple interworking implementations, pluralism of APIs, etc.
Earlier quoted context omitted.
It's interesting that you bring this up, because I'd consider Go and Haskell as almost polar opposites. Go is a simple language which lacks expressibility but with strong opinions on almost everything from formatting to architecture, which leads to a streamlined (and refreshing) developer experience. Haskell is a complex language, with an expressive type system giving you more tools and guarantees but I would call th…
I think a big part of the success of Haskell is down to its language extensions. New features are introduced as off by default and can be opted into. This allows all kinds of crazy features to be introduced without really impacting users if they don't want to. It does allow the community to be quite experimental without fear of destroying things.
Earlier quoted context omitted.
Sure, but that's a different issue. If it doesn't gain traction then the decisions made by Google are clearly considered the best approach, at which point what relevance does the openess have?
> If it doesn't gain traction then the decisions made by Google are clearly considered the best approach 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 ta…
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.
Earlier quoted context omitted.
ML (1973) and CLU (1975) introduced generics to the world, followed by a myriad of approaches to implement them across multiple languages, so plenty of time.
No one claimed, that languages with generics don't exist. But if you follow the discussion about generics in Go, Russ Cox did a thorough discussion of all the proposals on the table and why they would mean giving up some of the core traits of the Go language. As soon anyone suggests an implementation not colliding with the core Go goals, the Go team probably would pick it up quickly. Or phrased it in another way: wit…
"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...