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.
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.
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.
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.
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.
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 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...
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?
[1] https://www.rust-lang.org/governance/teams/core [2] https://www.rust-lang.org/governance
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.
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.
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.
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.
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.
Has it ever happened though? Genuinely curious.
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.
-Nobody gets fired for buying Oracle. -It's easy .. explaining an investment in open source .. good luck
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...
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.
Well does PostgreSQL offer anything like Oracle's CDC?
Edit: Nevermind, I just read up on using a WAL replication slave with triggers.
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.
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...
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.
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.
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.
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.
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
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.)
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.
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.
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 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).
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?
Why is that?
I thought your comment made a lot of sense.
Personally, I like go a lot for writing services and console applications.
I feel Go's 'opinionated' language design insults my intelligence.
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/...
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.
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.
It's just you can't implement your own hashmap in Go, and make it compile time type safe.
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.
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)
- 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.
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.
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.
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.)
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.
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.
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.
I would say the main drivers of Haskell these days are academics, PhDs and consultancies.
I'm confused as to what's stopping someone from forking it, calling it OpenGo, and building a community around that.
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.
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.
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.
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.
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.
1. https://news.ycombinator.com/item?id=8733705
I know I get a little absurd towards the end but no more so than your remarks about Java.
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.
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?
I'd pick Go among those every day of the week, but it's not perfect.
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 wouldn't worry much about "performant" though.
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.
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.
What is being proposed as the alternative here?
In both aspects, just compare .NET/C# with PHP.
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.
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.
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.
