Live data from Hacker News

Go is Google's language, not ours

utcc.utoronto.ca

491–500 of 679 posts

Re: Go is Google's language, not ours

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

Wasn't Haskell created by a university? That would be more tax dollars than community-driven.

Aren't tax dollars the ultimate manifestation of "community driven"?

Re: Go is Google's language, not ours

#493
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…

Companies pay Oracle because 1) PostgreSQL doesn't take you to lunch and 2) Oracle "just works." I mean, we all know #2 is effectively a lie but having the option to go to Oracle directly for issues (even if the response is just "pay a contractor") immensely reduces risk for executive leaders.

Are they paying Oracle though? A quick Google found this:

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?

Re: Go is Google's language, not ours

#494

Um, Yeah, GOOD! This demand for Generics is pure sheep brain garbage. Once you learn to write software properly you find only like 1 or 2 small use cases where Generics might actually help

Down vote me all you want. Been writing production software in Go for nearly 4 years and have never asked or needed Generics. Saying that there isn't a community because Generics are wanted by "some people" is daft.

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.

Re: Go is Google's language, not ours

#495
post #286

Earlier quoted context omitted.

Generics were added so late because they had to figure out how to do it properly, correctly, on the first time.

Generics in Java are giant hack from the early 2000’s to maintain backwards compatibility with 1990’s-vintage JVMs. C#’s generics we’re done right.

I'm of two minds of that, these days. I came from C# so of course reified generics were of course better, of course--but these days I would rather have them in Java more and in C# less. I often find myself wanting to write the moral equivalent of `IFoo` in C# and end up having to have two separate interfaces, etc. just to have a way to handle a list of a thing that I end up working on in an abstract manner. (Though I'd caveat that that is more of a gamedev-related concern than in Java/Kotlin, which I write for work.)

I do appreciate, though, that when Microsoft decided to do generics for C#, they did so decisively. These days, when C# gets a new feature, it seems like it's the complete opposite of decisively delivered.

Re: Go is Google's language, not ours

#496
This is absolutely true. In general I feel like it's good when a language belongs to a core team, but they don't appear to be learning from past mistakes. The core team put out a proposal for modules and then immediately implemented it with very little community feedback except what could be done after the fact without breaking much. There was huge backlash and they claimed they would do better and seek community feedback earlier, but now they require that you use a Google web service when fetching modules (I've turned it off) and shoved that out between two versions without any community feedback as well.

Strong central leadership is great, but leadership needs to actually listen to the people they're leading (and not just as an after thought).

Re: Go is Google's language, not ours

#497
post #455
post #186

Earlier quoted context omitted.

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

Yes, I personally prefer streams, LINQ seems to me like mixing SQL in C# and that feels wrong.

Re: Go is Google's language, not ours

#498

Earlier quoted context omitted.

It's not about being careful (they are--but always with the baggage of backwards compatibility), it's about not having a soul. 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 writ…

I have no idea what having a "soul" means. But I suspect that my career has been well-served by being dead inside.

> I have no idea what having a "soul" means

A design philosophy. Some sort of measurable practice that influences design. This is not limited to Java. Design by committee has been destroying the maintainability of many languages.

Re: Go is Google's language, not ours

#499
post #472

Earlier quoted context omitted.

> I don't see any value in the "nice shorthand." Typing out "SomeStupidClassName" has never once been a material bottleneck in my 15+ years of programming There are a few rather glaring spots that I've noticed. First, when you're refactoring, you've now got to edit every spot where a variable of that type is created. At the very least, when you're just renaming a class, your IDE can help you, but you still create a l…

It would appear that all of your code quality arguments are "people are too lazy to actually write good code." So it's not clear why you would decry that assertion. I don't have a horse in the race one way or another, but you're not refuting mieseratte's objection.

A tool that encourages you to shoot yourself in the foot is a bad tool.

If a language encourages bad patterns by making good patterns overly verbose, the language should address that.

Re: Go is Google's language, not ours

#500

Earlier quoted context omitted.

Interesting, that I saw a similar pattern like "at first I complained, but as time went on I found some benefits" quite a lot. 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 ex…

The nice thing about walking minefields is learning how to watch your step.

That's like the idea of planting a bamboo plant, then jumping over it every day. It's a nice idea, but you won't ever be able to jump over a two story house. Instead, you'll eventually catch your foot and tumble. Likewise with the minefield. The result, is that you'll eventually step on a mine. At best, you can use a simulated minefield as an exercise, then use mine detection equipment and proceed with caution.

Or, you can avoid the minefield entirely.

Post reply on HN