Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go is Google's language, not ours

utcc.utoronto.ca

Post reply on HN
Print view View original

451–460 of 679 posts

Re: Go is Google's language, not ours

#451

Post by mshockwave »

cryptos wrote: post #24

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…

LLVM is also an interesting examples: it was first driven by Apple but now it's driven by many different large companies. I mean it's not completely driven by community but i think it's better than dominated by single authority

Re: Go is Google's language, not ours

#452

Post by weberc2 »

willtim wrote: post #75

Haskell is an excellent example of a community-driven language. It's more mature and advanced than most commercial offerings too, offering a superior type system, fast and efficient executables, lightweight fiber concurrency, software transactional memory, higher-kinded parametric polymorphism and many more features.

And Haskell's market success is still very limited. This isn't a very compelling argument for community-driven language design. I think a better one would be Rust (to the extent that we can agree that Rust is designed by community) which seems to be getting a fair amount of market penetration given its age.

Re: Go is Google's language, not ours

#453

Post by 0815test »

steveklabnik wrote: post #447
0815test wrote: post #435

Earlier quoted context omitted.

> 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. 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. t…

Rust does support multiple major versions of dependencies in a build. 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.

Yes, but the folks who are now complaining about Go not being 'community-led' enough were pushing for a module system ("dep") that does not allow for this, and being told that not allowing multiple major versions in the same build was indeed a major problem (and even a showstopper) with their approach. I'm just pointing out that this is clearly a bad argument for calling Go "not community led"! Sorry if that was unclear.

Re: Go is Google's language, not ours

#454

Post by jjdjr0odo7 »

This post seems to conflate implementation and specification.

All the required bits (permissive license, specifications, etc) for writing a community tool chain (compiler, linter, fmt) are in the open.

Won’t the oppressed community rise up for itself and end this programming language tyranny!

Re: Go is Google's language, not ours

#455

Post by jayd16 »

akerro wrote: post #186
danielmg wrote: post #177

For what it's worth I'm a semi-grey beard (20 years in) and I love golang. For me it was like going back to being 8 years old on my Commodore Plus/4 and really enjoying writing code again. It needs close parenting. Java has been ruined by the push to include everyone's pet feature.

>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.

C#'s language is much better designed IMO. Can anyone compare LINQ and Java's streams and not pick LINQ? Feels much sloppier in Java and Java came second.

Re: Go is Google's language, not ours

#456

Post by baby »

Illniyar wrote: post #84

Google are bad at building developer communities (or at the very least they don't care about it much). They build things for themselves and their way is the Ivory Tower way of running a community. The overlords decide and their word is set in stone, the plebs should just accept the fact that their concerns and use cases are just too trivial and they should listen to the smart people at google and do it their way, whi…

Saying that they have failed to build a community around Golang is totally wrong

Re: Go is Google's language, not ours

#457

Post by BowBun »

skybrian wrote: post #445

There is an assumption here that the community is unified, you are part of the community, and therefore if the community doesn't get what it wants, then you don't get what you want. 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…

100%. Look at Ruby's community. It's a pretty great community in my experience, but at the end of the day Matz, Kokubun, etc. act as gatekeepers.

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.

Re: Go is Google's language, not ours

#458

Post by grumpydba »

masklinn wrote: post #236
foldr wrote: post #225

Earlier quoted context omitted.

Go does not have generic arrays any more than C does. You cannot e.g. write a generic Go function to reverse an array. 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…

> Go does not have generic arrays any more than C does. 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 Beca…

> 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.

It looks like you are in golang core team's minds. You appear to be able to judge intent. Impressive quality you have here.

Re: Go is Google's language, not ours

#459

Post by zimpenfish »

vinceguidry wrote: post #285
uranusjr wrote: post #108

Earlier quoted context omitted.

I guess the most important distinction is the “B” part (benevolent). Guido is called that because he is known (since before BDFL is a thing) to listen to other people, and adapt when they disagree strongly with his decisions. Google has never demonstrated the same attitude afaict, and in multiple occasions showed exactly the opposite. Edit: And to answer the question, no, there’s no philosophical differences. And the…

Wasn't Linus the original BDFL?

Seems to have been Guido.

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.

Re: Go is Google's language, not ours

#460

Post by apta »

divan wrote: post #352
brown9-2 wrote: post #255

Earlier quoted context omitted.

In my opinion the monotonic clock example cuts against this argument - originally the core team was extremely dismissive of the idea, even though it had been shown to cause pain for a lot of people: https://github.com/golang/go/issues/12914#issuecomment-15075...

It's a great example, as it shows the complexity of the discussed topic and attempt to justify any changes to the language/stdlib. In the above-mentioned comment rsc replies to another Googler, not to "community". 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 we…

Or, you can view this from another angle, that the golang authors yet again disregarded previous established work in the industry for the sake of avoiding hard work in the language and the compiler. It's no wonder the time package in golang is garbage compared to established offerings in mature languages like Java and C#.
Post reply on HN