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

551–560 of 679 posts

Re: Go is Google's language, not ours

#551

Post by detaro »

repolfx wrote: post #228
tremon wrote: post #192

Earlier quoted context omitted.

That's not really a problem for computer science students, I think. Their area of focus tends to be on the algebraic, theoretical side of the spectrum. It's much more of a problem for computer (software) engineers.

Be careful. Rob Pike asserted Googlers can't handle an "advanced language" or whatever his exact words were, but he provided no evidence this was true, or that others at Google agreed with him, or that this was even the reason Go was created to begin with. The most obvious evidence he's wrong is that Google's codebase is all C++ and Java, both languages that have generics and other more advanced features than Go. So…

> The most obvious evidence he's wrong is that Google's codebase is all C++ and Java, both languages that have generics and other more advanced features than Go.

Alternatively: Seeing people continue to make mistakes in those languages that are widely used has informed the position about language features and design aspects that are problematic, and things that would be helpful to have. Proposing a new language to avoid them is an (admittedly fairly extreme) solution to that.

Re: Go is Google's language, not ours

#552

Post by agumonkey »

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…

I appreciate a lot of Golang, but I really wonder how they'll do generics differently than others

Re: Go is Google's language, not ours

#553

Post by mcguire »

coldtea wrote: post #226
th3iedkid wrote: post #189

Earlier quoted context omitted.

Generics was introduced in Java in 2004 with J2SE 5.0[0]. [0]: https://en.wikipedia.org/wiki/Java_version_history#J2SE_5.0

Generics should have been in Java (and Go) from the beginning. Those surely are not the proof that Java adds "everybody's favorite feature". I think the parent means the newest Oracle projects (Valhalla, modules, value types, streams, and so on).

(Technically, I think Java modules have been floating around in weird, likely broken suggestions since before Oracle bought Sun. As far as I could ever see, the primary design constraint was always, "NOT OSGi!")

Re: Go is Google's language, not ours

#554

Post by mcguire »

bunderbunder wrote: post #348
RHSeeger wrote: post #333

Earlier quoted context omitted.

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

IIRC, the choice was between Java 5's version of erasure or drastically modifying the JVM, with the likely result that the new Java would be incompatible with the old Java. (Like C# has done.) This was considered unacceptable at the time. (Unlike C#.)

Re: Go is Google's language, not ours

#555

Post by dang »

pjmlp wrote: post #149

I pity the recent CS graduates that weren't able to attend a decent CS degree and need Go to fit their mental model.

Haven't we had to ask you before not to do programming language flamewars on HN? Please don't do programming language flamewars on HN.

We detached this subthread from https://news.ycombinator.com/item?id=19978882 and marked it off-topic.

Re: Go is Google's language, not ours

#556

Post by floatboth »

weberc2 wrote: post #452
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.

Haskell deliberately "avoids success at all costs" though.

Re: Go is Google's language, not ours

#557

Post by eropple »

jimmaswell wrote: post #522
eropple wrote: post #495

Earlier quoted context omitted.

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…

You mean like this, right? class A {}; class A : A {}; I don't mind that. It can even be an aid to organization - all the generic stuff goes in the generic class, all the stuff that doesn't rely on that can go in the base class. But it would be nice to use something like . Too bad generics don't inherit implicit casts, like A to A .

I do mean that, and I do mind it a lot when I'm so used to just being able to erase the generic.

There are performance implications to type erasure, to be sure, but when our computers are mostly all future machines from beyond the moon, I'm more interested in minimizing the impedance between my brain and a solved problem.

Re: Go is Google's language, not ours

#558

Post by pron »

emn13 wrote: post #536
pron wrote: post #527

Earlier quoted context omitted.

Value types add complexity and they weren't necessary in 1995. They only became necessary due to hardware changes circa 2005. Similarly, AOT compilation has only become attractive for the kinds of applications people use Java for only recently, when startup time became important for serverless. The lack of neither has caused Java lasting damage; what has is the domination of the browser on the client, but that has af…

Value types aren't "necessary", but they would have been valueable at day 1. The GC heap is simply inefficient; not necessarily because of the GC (which indeed is harder with massive multicore), but simply because of the per-object memory overhead. There's a reason java had built-in value types from day 1, because it made sense even back then. Frankly, I think both java and C# kind of got this wrong. There was an ove…

> because it made sense even back then.

That was necessary for performance back then. User-defined value types weren't, and Java has done well without them.

> Object has semantics, and that was a mistake, because it contributes to the bloat.

I think most of the RAM bloat is due to the GC trading off extra RAM for speed rather than object headers, and I'm not sure trading off complexity for headers was right 25 years ago (JS is doing fine on the client without value types). What changed was the performance characteristics.

As to object semantics, it may be a fixable mistake. The goal is to get value types without today's object semantics while preserving a single class hierarchy at the same time. The Valhalla team thinks that's achievable.

Re: Go is Google's language, not ours

#559

Post by chupasaurus »

folkrav wrote: post #541
ncmncm wrote: post #41

Earlier quoted context omitted.

Actually Mongo doesn't even look at pull requests. So, yes. Postgres (do we really still need the "QL" reminder?) has demonstrated staying power, and repays invested time in spades. Linux, obvs. Rust, it's still too early to be sure about. Learning it will be at least educational, maybe formative, and at worst it won't be taken away.

Projects like Linux are "community" projects in the sense that there is not a single company backing it, sure. However, for Linux, only 7.7% of contributions were made by unpaid developers as of this 2016 report[0]. I have a hard time calling this a "community" project when the community is paid by corporations. Don't get me wrong, I'm not really complaining, as a project the size of a commercially viable operating s…

Don't forget that most of the kernel's codebase are drivers and some of the most impactful additions were made by employees of corporations (on top of my mind - cgroups and namespaces by googlers, and not only as a base for containerization).

Re: Go is Google's language, not ours

#560

Post by pron »

pjmlp wrote: post #546
emn13 wrote: post #536

Earlier quoted context omitted.

Value types aren't "necessary", but they would have been valueable at day 1. The GC heap is simply inefficient; not necessarily because of the GC (which indeed is harder with massive multicore), but simply because of the per-object memory overhead. There's a reason java had built-in value types from day 1, because it made sense even back then. Frankly, I think both java and C# kind of got this wrong. There was an ove…

C# got it right from day one, regarding value types. AOT compilation not so much, given the NGEN constraints. However they got it both wrong, considering CLU, Modula-3, Delphi and Eiffel are considered influencial languages on their design.

Mutable structs are not exactly value types, but Microsoft has always preferred control over simplicity (after all, they pushed C++ really hard). I won't say whether that philosophy is right or wrong, but it is very different from Java's.
Post reply on HN