221–230 of 346 posts
There is a difference between open source and open governance. Go is open source but the governance is controlled by Google. For example, the committee that accepts proposals is all Google employees and a subset of the core team, if I read it right. From what I can tell, they definition of consensus is that of this group rather than the community at large. This has business decision implications. Those who have had i…
Everyone's upset that Go is Google's language, but no one would have adopted it if it weren't. It's not enough to have a cool idea for a language, even if your cool idea is not to put any new cool ideas in the language. You have to be Mozilla, or Google, or someone it seems in order to convince people this language is for real and will be supported for many years to come, and will have a healthy ecosystem. If I had m…
History doesn't really support that. PHP, Python, Ruby, Tcl, OCaml, Lua. Successful programming languages seem to come in equal measures from both large corporate backers and not. There is certainly the need for network effects which large corporations often can provide more consistently, but we have seen plenty of examples within the space where individuals or smaller companies have been successful in providing thes…
Earlier quoted context omitted.
What's the bad news?
"you always know where everything is" is no longer true. https://github.com/golang/go/wiki/Modules
Earlier quoted context omitted.
I never implied otherwise, I merely answered the parent's question. It's worth noting however that Go's maintenance burden is higher than many other languages which are often a layer atop existing infrastructure (Clojure with Java, Rust with LLVM for instance). AFAIK Go devs write maintain the entire toolchain, including a custom linker for instance.
Who takes this kind of argument seriously? The Go community can't support Go without Google because only a company like Google can maintain a linker? You're reaching.
That being said, Go is mainstream enough that, if Google EOLs it, the community will pick up the torch. Simias says its harder for Go than, say, Rust. It probably is.
Everyone's upset that Go is Google's language, but no one would have adopted it if it weren't. It's not enough to have a cool idea for a language, even if your cool idea is not to put any new cool ideas in the language. You have to be Mozilla, or Google, or someone it seems in order to convince people this language is for real and will be supported for many years to come, and will have a healthy ecosystem. If I had m…
I guess because it does not merit that adoption. The only reason it gets attention at all is either 1) "oh it's made by the same people who made UNIX and C and UTF-8", or 2) "oh it's made by Google".
So if it isn't Google's language, does it mean i can go and make my own compiler for it, call it -say- "Crinus Go" (to differentiate it from Google's Go but still point out that it is an implementation of Go) and not worry about Google coming after me?
llvmgo and gccgo would indicate, yes you can.
Earlier quoted context omitted.
Actually, Elixir did add the bells and whistles to Erlang, sort of. That is pretty much the whole point of Elixir.
I assume OP meant that Elixir is a purposefully small language. It taps into a lot of functionality in Erlang without necessarily re-implementing it. There isn't even a wrapper around the Erlang :sleep function.
Not to hate too much on erlang, but I would say that beyond being small, as a pushback to characterizing it as "bells and whistles", Elixir brings to the table "21st century" understanding/opinions on what makes for readable and maintainable code (build packaging, first-class documentation, module organization, file types, strings, map-focused vs struct-focused, sane function parameter ordering). As a result, I can confidently onboard a junior into Elixir (especially if they were in a RoR bootcamp) and have them be productive. I probably wouldn't for erlang.
A very well written piece by Ian Lance Taylor. If you don't want to read it all, he summarizes it here: > In effect, then, the current state is what the blog post suggests at the very end: final decisions about the Go language are made by the core Go team, and the core Go team all work at Google, but there is no meaningful sense in which Google, apart from the core Go team, makes decisions about the language.
I think it's also worth highlighting this: no successful language-indeed, no successful free software project of any sort is a democracy [...] Successful languages pay attention to what people want, but to change the language according to what most people want is, I believe, a recipe for chaos and incoherence. I believe that every successful language must have a coherent vision that is shared by a relatively small gr…
On that note, I also seem to remember that LLVM/Clang are pretty democratic, but I haven't dug deeply and may be completely wrong.
Like it or not, Google is probably paying around a million $$ a year to keep senior full-time developers around that want to work on the language. That could be used as a benchmark to calculate how much of an investment is required to have a healthy development cycle. If a community-maintained fork is created, it would need time and monetary investment similar to what google is doing just to maintain and develop non-…
So these Linkedin/Twitter style thought leaders demanding some kinda OpenGo foundation need to ask if they have capacity to raise this amount consistently over years to start and run this foundation.
Earlier quoted context omitted.
Yes, you have always been able to do that. The open source license it uses enables that.
The open source license allows me to fork the implementation of Go, but not use a derivative of the Go name for my derivative of the Go implementation (to ensure/show, among others, that people know that my work is about Go and not some other language or something i came up with).