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

641–650 of 679 posts

Re: Go is Google's language, not ours

#641

Post by weberc2 »

pjmlp wrote: post #627
weberc2 wrote: post #441

Earlier quoted context omitted.

> proper software engineering Only if you define this in such a way that it's tautologically true. If your definition of software engineering incorporates some degree of economic success, then no, these languages don't work well. I'm sure someone will be tempted to levee this strawman argument: "But lots of languages drive projects that make more money than Go!" Note that I never claimed market success was the sole c…

Well, then pick C++, Java and C# instead. All of them provide more features for software engineering at large scale that Go is still catching up with, hence Go 2.0 proposals.

There’s no evidence that those languages are better at engineering at scale than Go is. In particular, all of them are riddled with anti-features e.g., inheritance and all of them have ridiculously convoluted tooling (especially build tooling a la CMake). If I want to get something done, especially in a team setting, I’ll reach for Go over those languages every time.

Re: Go is Google's language, not ours

#642

Post by pron »

pjmlp wrote: post #638
pron wrote: post #635

Earlier quoted context omitted.

Oh, I don't deny that value types would have helped performance back in '95, just that they were absolutely essential for Java. Smalltalk/Self and Scheme/CL didn't have them, and those were probably Java's greatest influences; I don't think VB had them, either. Also, in its first four years, before HotSpot was ready, Java was interpreted, so it had bigger performance problems. I don't know why there was no emphasis o…

Microsoft Basics have support for value types since MS-DOS. QuickBasic supported value types and AOT to native code, and while Visual Basic used P-Code, version 6 introduced a proper AOT native compiler. Modula-3 was also a big influence, at least accordingly to some papers. There was surely demand for AOT, given that most commercial JVMs had it in some form or the other since 2000. Even Sun actually supported it in…

What user-defined value types did CL have in '95? Also, are you sure about VB having had them then?

As for AOT, there may not have been sufficient demand from Sun/Oracle. I only joined relatively recently, but we generally do expensive things only if we believe they have a huge benefit or in huge demand, and we believe it can be long-lasting. The assumption is that any new feature will require maintenance for 20 years, taking away resources from other things. So if something is expensive, even if it's cool or some people could find it very useful -- we don't do it. The assumption is that the ecosystem is large enough that others can, and will.

Re: Go is Google's language, not ours

#643

Post by pjmlp »

pron wrote: post #642
pjmlp wrote: post #638

Earlier quoted context omitted.

Microsoft Basics have support for value types since MS-DOS. QuickBasic supported value types and AOT to native code, and while Visual Basic used P-Code, version 6 introduced a proper AOT native compiler. Modula-3 was also a big influence, at least accordingly to some papers. There was surely demand for AOT, given that most commercial JVMs had it in some form or the other since 2000. Even Sun actually supported it in…

What user-defined value types did CL have in '95? Also, are you sure about VB having had them then? As for AOT, there may not have been sufficient demand from Sun/Oracle. I only joined relatively recently, but we generally do expensive things only if we believe they have a huge benefit or in huge demand, and we believe it can be long-lasting. The assumption is that any new feature will require maintenance for 20 year…

Arrays, structs, fixnums, explicit stack allocation.

I can check the respective manuals if you wish.

Yep, I did VB programming for a short while.

And please note that even though my focus is now elsewhere, Java is one of my favourite eco-systems.

As a peasant I just wished that Java 1.0 was more like Go, given the existing alternatives back then.

So it kind of stayed as a pet peeve of mine.

Same applies to .NET, just in a different way.

Re: Go is Google's language, not ours

#644

Post by pjmlp »

0815test wrote: post #640
pjmlp wrote: post #639

Earlier quoted context omitted.

It sure did, as long as you were a Windows shop.

No need for Windows. There was an official Linux implementation back in the day, codenamed Kylix.

Kylix was full of issues and was a mismanaged product variant, largely ignored.

If I recall correctly it even depended on WINE.

Re: Go is Google's language, not ours

#645

Post by hundt »

NateDad wrote: post #576
naikrovek wrote: post #235

Earlier quoted context omitted.

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…

names = append(names, "Bob") .... that's really it. Will it have the same backing array as it did before you did append? Maybe, maybe not. Should you care? Absolutely not, and if you do, you're probably doing something wrong.

Sometimes you need to care!

https://play.golang.org/p/goL1JtapY7q

Re: Go is Google's language, not ours

#646

Post by hundt »

weberc2 wrote: post #414
naikrovek wrote: post #235

Earlier quoted context omitted.

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…

This is absolutely not best practice. It's perfectly idiomatic to insert an item into a slice (without the copy shenanigans you describe). The slice will manage the copy if necessary.

That's fine as long as you don't mind if the underlying array is modified. As the parent points out, a slice is a view into an array and there could be other views into the same array.

https://play.golang.org/p/goL1JtapY7q

Re: Go is Google's language, not ours

#647

Post by takeda »

dirkg wrote: post #545
richardwhiuk wrote: post #466

Earlier quoted context omitted.

Go already supports generics - the hashmap is generic, and the array is generic. It's just you can't implement your own hashmap in Go, and make it compile time type safe.

C also supports generics - just use void * !! no, Go doesnt' support generics.

void * is the C's equivalent of interface {} it has little to do with generics although it can be used to work around lack of it.

Perhaps there are other ways, but in C you have parametric polymorphism functionality through macros. That's why min() and max() are not functions but macros and they work with any type that can be compared, not just float64.

Re: Go is Google's language, not ours

#648

Post by takeda »

mcguire wrote: post #579
DannyBee wrote: post #432

Earlier quoted context omitted.

Which is nonsense, and is equivalent in this case to "i never bothered to ask so i'm just going to assert some stuff that agrees with my viewpoint". They could have just asked. In fact I can answer this for you, since I was the relevant director (IE Go directly reported to me) It was driven by the core team, and more particularly, the leads and what they want to be trying to do. I have provided precisely 0% of the vi…

So, why is Google paying them? Is Google getting enough value out, or PR, or...?

People are stepping around trying not to offend anyone, but it is no secret that Go was created for Google to solve their needs, it supposed to be a simple language that even a fresh graduate out of school could pick it up quickly and work with it. It is also very opinionated for example regarding the formatting or (at least initially before vgo was introduced due to outside pressure) to work well only in a mono repo scenarios.

Google makes it free to use, so it will be easier to recruit people that already know it. Many companies do that as well, the difference is that still generally no one uses their languages. This one is different, because well it's Google. The Go itself isn't really that great language, but there's a lot of hype behind it. I wonder when it will die out, but I guess it will be a while.

Re: Go is Google's language, not ours

#649

Post by kccqzy »

Twisell wrote: post #488
kccqzy wrote: post #198

Earlier quoted context omitted.

Like automatically refreshing materialized views, by which I mean when a base table is changed, the engine uses the definition of the materialized view to run triggers to update materialized view.

This is related to default implementation details, this behavior can be achieved using trigger/materialized view on PostgreSQL as well.

My entire point is that I shouldn't have to write the triggers myself. PostgreSQL figures out the triggers from my definition of the materialized view.

Re: Go is Google's language, not ours

#650

Post by hwj »

chimeracoder wrote: post #415
pjmlp wrote: post #155

Earlier quoted context omitted.

Not really, that is the hand waving when the issue ever pops up. Rob Pike already stated publicly that he is against the proposed idea for Go 2.0. "Rob Pike - Go 2 Draft Specifications" - https://www.youtube.com/watch?v=RIvL2ONhFBI

> Rob Pike already stated publicly that he is against the proposed idea for Go 2.0. Rob Pike is not a member of the Go team anymore, and he has not been for several years.

That's sad. Was it because of disagreements?
Post reply on HN