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

241–250 of 679 posts

Re: Go is Google's language, not ours

#241

Post by jacques_chester »

weego wrote: post #133
cryptos wrote: post #32

Earlier quoted context omitted.

This could be done, of course. But how likely is such an approach to succeed? It would effectively create a new language and in turn to a new ecosystem. Why not just use a different language (Rust comes to mind) then?

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?

A major thesis of the article is that even if something was successful outside of the core team, they would ignore it in favour of their own ideas. Go modules is the reference case.

Re: Go is Google's language, not ours

#242

Post by foldr »

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…

According to this usage, C has generic functions because you can, e.g., index into an array of ints. The whole point of generics is that the language makes available some form of abstraction over types. Go does not have this feature. It has some built-in operators that can operate on multiple types. Most languages have this. The arithmetic operators in C, for example, can take operands of many different types. This is not "generics".

>Because the core Go team assumes and asserts users of Go should not and can not be trusted with anything more complex than a wooden cube with rounded edges large enough that it can't fit in their mouths.

This can't really be the right explanation given that generics are now being added to the language. In any case, this kind of mean-spirited speculation about people's motives is borderline trolling, IMO. The Go team have publicly stated their reasons for not (initially) putting generics in the language. Unless you have some inside info suggesting that they're lying, I'd refrain from saying this kind of thing.

Re: Go is Google's language, not ours

#243

Post by 0815test »

User23 wrote: post #145
calcifer wrote: post #63

Earlier quoted context omitted.

By my count, fewer than half of Rust's core team [1] are Mozilla employees, whereas the number is 100% for Go. Rust also has a very clear and open governance model [2], where the Go team is more closer to "we'll do what we want". [1] https://www.rust-lang.org/governance/teams/core [2] https://www.rust-lang.org/governance

Also Rust is observably a better Go than Go.

It'll be that too, eventually. But not yet!

Re: Go is Google's language, not ours

#244

Post by _trampeltier »

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…

The simple and sad truth:

-Nobody gets fired for buying Oracle. -It's easy .. explaining an investment in open source .. good luck

Re: Go is Google's language, not ours

#245

Post by weavie »

foldr wrote: post #218
weavie wrote: post #208

Earlier quoted context omitted.

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.

You can opt out of using those extensions in your own code, but many of them are now deeply embedded in the library ecosystem.

Indeed. It's like a feature democracy where each library gets a vote on which features it finds most useful. Those that then get deeply embedded are clearly those that are most useful. Those features that aren't particularly used don't really get anywhere.

Re: Go is Google's language, not ours

#246

Post by swah »

jaabe wrote: post #167
rococode wrote: post #66

Earlier quoted context omitted.

I'd use this as an argument that if PHP is the gold standard for a community-driven programming language, I'd rather every popular language be backed by a large corp haha. 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 communit…

Is modern PHP really that bad? I kind of think it makes a lot of sense in a world where almost everything, even major government IT systems, are basically java/.net on the backend and some JavaScript MVVM framework on the client. I know a guy who works with laravel, and we’ve teased him so much about PHP over the years, because PHP. The truth is, that his backend is actually more suited for the modern world than what…

The thing I "envy" about PHP guys is that they aren't on proglang forums; they are somewhere happier making money and clients happy, and not giving a f* about the things our niche here does...

Re: Go is Google's language, not ours

#247

Post by lucb1e »

72deluxe wrote: post #181
lucb1e wrote: post #146

C# unfortunately has the same issue, but the effect is much more visible. Few people (I'm sure you can find examples, but given how popular the language is on Windows, it's a tiny minority) use C# outside of Windows and it's a shame. There is no good open ecosystem so even as a former Windows dev I hardly use it anymore.

Out of interest, what do you use instead? I have been trying to stick with C++ because it seems the one language that isn't too badly dragged into platform-specific fan clubs.

Depends on the purpose. I write mainly Python at home and at work, sometimes create small to medium sized Bash scripts, use PHP for my personal websites and most web projects, sometimes a few lines of Javascript (command line, I mean, not as part of html/css/js), sometimes some Java at work, LaTeX macros for documents... If speed is paramount (rarely) I'll also write C/C++ or maybe Go, but those are not my forte.

So it really depends on the purpose of the project, who else works on it, what it needs to integrate with, etc.

Thinking about what I use, C# didn't even come to mind. I only used it when required in school or when interning in companies that run Windows. I've written some C# on Linux at home but it's not much more than my experiments with Brainfuck were...

Re: Go is Google's language, not ours

#248

Post by koffiezet »

henridf wrote: post #73
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…

Prometheus is a (rare) recent example of a significant, thriving open-source project that is community-based. Not quite as broad in scope as something like Elasticsearch though.

But it started out as a Soundcloud project...

Re: Go is Google's language, not ours

#249

Post by jacques_chester »

grepgeek wrote: post #199
meddlepal wrote: post #33

Earlier quoted context omitted.

Modern Java is a pleasant experience compared to Go.

Can you elaborate? In what ways, is modern Java a more pleasant experience compared to Go?

Richer type system, richer concurrency, richer tooling, greatly advanced and advancing runtime, interoperability with multiple languages on the JVM, a naming system that doesn't cause frustrating workarounds a la the Kubernetes ObjectMeta / TypeMeta / "v1alpha1", "v1beta2", "v1" nonsense ...

Go is the language that taught me to really appreciate writing things in Java.

Re: Go is Google's language, not ours

#250

Post by crispinb »

doesnt_know wrote: post #162

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…

> The last thing I personally want to see is Go being handed over to the community to be designed by committee.

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.

Post reply on HN