281–290 of 346 posts
> 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 group of people. I'm continually surprised that more of the greater, vocal community does not grok this.
Earlier quoted context omitted.
Almost every major significant OSS project has a corporate sponsor (usually in the form of paid employees doing the bulk of contributions). Don't see the problem with that. And it's usually problems people are solving are work that instigate most of these contributions, so it's a damn good thing Go has a company like Google to act as steward, regardless of all the useless FUD people like to pretend "may" happen becau…
> Almost every major significant OSS project has a corporate sponsor (usually in the form of paid employees doing the bulk of contributions). Don't see the problem with that. Your arguments are deeply cargo cult-ish: they lack any rational train of thought and boil down to an empty belief on how a greater power will eventuall deliver good things to those who have faith in it.
What does that even mean? It's such a ridiculous statement, don't even know where to begin.
> they lack any rational train
Care to back this up with facts rather than slinging mud?
> 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 group of people. I'm continually surprised that more of the greater, vocal community does not grok this.
I think it’s disingenuous to paint this as a tyranny of the masses type situation as no one is calling for democracy. And even if they did, Apache and Python are showing successes in that area.
If google wanted an OSS language, they would have non-google committers. It’s perfectly cool to have company run languages. I think people just need to be aware and not confused that Go is anything other than Google’s language that we all get to use for free.
For me, with almost all things google, the risk is when Google grows bored with this and makes all the employees work on other stuff.
> 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 group of people. I'm continually surprised that more of the greater, vocal community does not grok this.
Earlier quoted context omitted.
> ...but no one would have adopted it if it weren't. It's a C-like language with GC, that compiles to native code supported by an efficient runtime, and can work effectively with parallel/concurrent code. In many ways it's Java done right, or a more intuitive (and from certain POVs, preferable) alternative to Haskell and Ocaml. That would seem to be enough to drive adoption.
Then why did D never take off?
Earlier quoted context omitted.
> If I were them, I would be looking for an opportunity to arrange to have at least one non-Googler on the core Go team, for the same reasons. That's how I read the 50 or so out of 100 approvers as being Google. That means 50 (or so, can't remember the exact number..) are not Google. When I read "Approvers", I match that in my head to "Core Team". Is there a "rank" above approvers that defines the core team?
I don't think he defined his terms very precisely in his document; but as my comment says, yes, there are two levels. There are people who can approve changes to the implementation of Go, and people who can make changes to the specification of Go. There are 100+ people who can approve changes to the implementation; but there only a handful of people who can make changes to the language specification, and all of those…
Should that be "the reference implementation of Go" ?
The specification mentions "implementation restriction" many times, so the Go spec writers seem to be encouraging other implementations. Besides gc, google also provide gccgo. If you download the gc source, change it a little so it still conforms to the spec, and publish, then that would be another implementation of Go. I believe there's an incomplete JS-based version of Go around as well, so if that's ever finished, that would be another implementation of Go.
Earlier quoted context omitted.
You probably don't. You can still use gopath and choose to use gopath for another project that doesn't.
> You always know where everything is do you always work on projects in which you made every decision?
Earlier quoted context omitted.
This is my biggest worry about the future of Go, that it will gain enough adoption at enterprise shops that we'll end up with another Java-esque ecosystem. So far it has seemed to have avoided that trap, but it is still a young language.
The only people in my experience that complain about the Java ecosystem have limited experience with Java 7 or before and haven't done any real modern Java development in many years.
The amount of cognitive overhead in dealing with all the history that's baked into Java is really annoying. Things like the dated concurrency model, the overachieving in logging (and other) libraries (when one to use?), the poorly thought out I/O libraries, the crazy build tools and slow builds, ... It's always a relief to get back the the smoothness of Go.
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…
Many of those languages came out in the 1990's when the big corporates were busy pushing visual 4GL's to replace programming languages. But programmers prefered to write a Perl ten-liner rather than fire up a visual environment, click on some toolbars to place some widgets on a form, link in the data files using the right-click form, wait while the OS thrashes the hard drive as it paints the screen for the first test, and on and on. When those corps realized they'd dropped the ball, they soon built their own.
> 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 group of people. I'm continually surprised that more of the greater, vocal community does not grok this.
I don’t think the issue is a small group of people holding a vision. For me, the issue is that a company changes the vision based on some unknown goals that the company has that are not known to the community. I think it’s disingenuous to paint this as a tyranny of the masses type situation as no one is calling for democracy. And even if they did, Apache and Python are showing successes in that area. If google wanted…
I find both of these communities to be huge turn offs. I think Apache projects and Python demonstrate varied quality; design by committee.
Conversely I find Go releases to be pretty high quality. When they are marginally suspect, I tend to find the strongest critics are members of the Go core team (e.g. future of http, sql packages).
> If google wanted an OSS language, they would have non-google committers.
I don't buy this line of reasoning. Go has been extremely welcoming to contributors. You don't need to be a committee to contribute. Are the thousands of projects open sourced by corporations under their corporate GitHub account not _true_ OSS to you?
> For me, with almost all things google, the risk is when Google grows bored with this and makes all the employees work on other stuff.
I understand this, but it's FUD. We've heard nothing but positive feedback from Googlers (no "they won't let us do X"), and if this _did_ happen, I would expect the existing committers to rebel sufficiently (i.e. quit) that this problem solves itself. Until then, I see no cause to warrant a change in management.