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

341–350 of 679 posts

Re: Go is Google's language, not ours

#341

Post by house_atr »

rococode wrote: post #66
fetbaffe wrote: post #54

Earlier quoted context omitted.

For community driven programming languages I would say PHP, large user base, mature & very active.

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…

PHP BAD!

Re: Go is Google's language, not ours

#342

Post by blankaccount »

sgift wrote: post #213
dullgiulio wrote: post #197

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…

> 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.) So, by adding a feature which works extremely well with OO and enhances the language they have no soul? That doesn't make any sense. Javas soul is being a blue collar language. It leaves the experiments to other (JVM) la…

How do you feel about streams/lambdas with Java's checked exceptions?

Re: Go is Google's language, not ours

#344

Post by MisterTea »

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.

I'm thankful for exactly that. Go is developed by Bell Labs people, the same people who bought us C, Unix and Plan 9 (Ken, Pike, RSC, et al). They took the time to think through all their decisions, the impacts of said decisions, along with keeping things as simple as possible. Basically, doing things right the first time and not bolting on features willy-nilly simply because the community wants them.

Reminds me of Joe Armstrong's quote: '''I remember thinking “how simple, no qualms of conscience, no soul-searching, no asking "Is this the right thing to do” …''' source: http://harmful.cat-v.org/software/OO_programming/why_oo_suck...

Re: Go is Google's language, not ours

#346

Post by jbergens »

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.

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

Re: Go is Google's language, not ours

#347

Post by asark »

naikrovek wrote: post #235
reflexer wrote: post #209

Earlier quoted context omitted.

wrt a "proper" way: adding item to a slice, uhmm?

A slice isn't an array. A slice is a view into an array. You don't look through a window in your house into the backyard, and plant a tree in the backyard by fiddling with the window. It's the same with arrays and slices in Go. If you want to insert an item into a slice, insert it into the array (by copying to a new array and adding your new element to it while copying), then creating a new slice which includes your…

> edit: (adding for clarity) In a lot of programming languages, whether they use slices or not, arrays are of a fixed size and must be copied to a new array if you want to add elements. Some languages have some syntax that makes it feel like you are modifying an array in-place, while doing the copy to a new array behind the scenes.

It's that or some magic with larger-than-needed arrays that automatically grow by a bunch extra every time they hit their boundary to make appends faster, while blowing up memory use and making append performance unpredictable.

Lots of (especially) scripting language hide this behind automagic and you see tons of append-in-a-loop where it's not really necessary, as a result.

[EDIT] had insert two places I intended append. Me need coffee.

Re: Go is Google's language, not ours

#348

Post by bunderbunder »

RHSeeger wrote: post #333
akerro wrote: 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.

And they failed. They did the best they could, but the fact that they were added onto the language later (plus the desire for backwards compatibility) means there are lots of gaps and warts in what they wound up implementing.

And the hacks to work around them started rolling in quite quickly. For example:

http://gafter.blogspot.com/2006/12/super-type-tokens.html

At its root, the real problem here isn't "reification good" vs "reification bad", per se. Haskell has an excellent implementation of generics, and erases types far more aggressively than Java does. C# also has a very good implementation of generics, this time based on reification.

The problem is more that Java's particular mix of design decisions resulted in a language that operates at cross purposes with itself. Once upon a time, back in the beginning, Java was a reflective language. Being reflective requires type information to be available at run time, though. When Java decided to use type erasure in its implementation of generics, they created a really bad set of interactions: They kneecapped reflection, so now you can no longer call Java truly reflective; it's only partially reflective. You can no longer effectively and accurately reflect on what have come to be some of the most-used classes in the language. And, at the same time, they forever sealed a rather important corner of the type hierarchy off from generics. They also delayed a bunch of type checking until run time - after types have been erased - so that certain things can just never be made to cleanly type check. Meaning you also can't say Java is any more than partially generic.

Re: Go is Google's language, not ours

#349

Post by Merovius »

I'm so tired of people purporting to speak for "the community" - especially when they diametrically oppose my own views. It feels a lot like they are co-opting me for their own agenda while simultaneously excluding me.

The things mentioned as evidence that community doesn't matter have a lot of buy-in from the community. Modules in particular are an effort that - at least from what I can tell - is heavily driven by non-Googlers (in particular Rog Pepe, Paul Jolly and Daniel Marti are people who put a lot of work into making modules actually work for practical workloads).

These kinds of pieces only make sense if you have an extremely limited view of who is or is not part of "the community" - in particular, if you throw everyone agreeing with the Go team out of that bucket.

Re: Go is Google's language, not ours

#350

Post by anchpop »

mieseratte wrote: post #336
read_if_gay_ wrote: post #311

Earlier quoted context omitted.

>I'll never forgive the addition of `var` to the language. I'm inexperienced with Java and didn't know this existed until I saw your post. It seems like a nice shorthand to me. Can you explain why you don't like it?

I'm of the mind that it is un-Java like. Whether or not there is a "Java" as a philosophy is not the hill I'm trying to die on. Consider these contrived lines of code: ``` String first = someMethodCall(); var second = someMethodCall(); ``` The first provides more useful information at a glance. I don't see any value in the "nice shorthand." Typing out "SomeStupidClassName" has never once been a material bottleneck in…

To quote another comment from this thread:

> [D]rop the strawman argument and borderline ad hominem. It'll do you better.

Post reply on HN