Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

3.5 Years, 500k Lines of Go

npf.io

Post reply on HN
Print view View original

101–110 of 249 posts

Re: 3.5 Years, 500k Lines of Go

#101

Post by themihai »

infogulch wrote: post #33
grabcocque wrote: post #10

This entire piece sounds like the Blub Paradox made real. http://paulgraham.com/avg.html It's written with knocking down a very specific set of straw men in mind, but rather carefully avoids coming anywhere close to addressing the legitimate criticisms of Go as a language. One of the things that's most irritating about Go enthusiasts is the way they try to close ranks on legitimate critique and reframe their language…

> '... therefore NOBODY does' The author never said that, just 'I don't need generics' and they very rarely missed them. What other criticisms did they dismiss/reframe? Lack of stack traces in errors is mentioned and mostly dismissed, and error handling in general is reframed I guess... but these claims are backed up by evidence that it works . Crashes and NPE are extremely rare, and for those standard errors are suf…

Package management is in the works though

Re: 3.5 Years, 500k Lines of Go

#102

Post by kuschku »

NateDad wrote: post #61
excepttheweasel wrote: post #44

I think the go language has taken a position along the lines of "re usability and abstraction are overrated". I certainly think there is some truth to that, I am really enjoying working with go on smaller projects and it is this philosophy that has made understanding the code much easier. But I wonder how it really scales on a large code base like this? Some of the best projects I've worked on leverage usability more…

functions and methods are the original abstraction. Interfaces allow you to abstract implementations of sets of methods. I fail to see how that is saying that abstraction and usability are overrated. They're not. They're important.

And go can not write abstract functions and methods.

I can not write a function dealing with arbitrary values.

Somethind I’d do in Java with

    public static  T increment(T val) { val.increment(); return val; }
is impossible to do in Go.

You can not abstract over types, and write metric fucktons of duplicated code. I’ve tried porting some of my Java code, and it quickly grew to some classes being duplicated hundreds of times, once for every type. Fixing bugs became a nightmare.

Re: 3.5 Years, 500k Lines of Go

#103

Post by eloff »

akinalci wrote: post #92
grabcocque wrote: post #10

This entire piece sounds like the Blub Paradox made real. http://paulgraham.com/avg.html It's written with knocking down a very specific set of straw men in mind, but rather carefully avoids coming anywhere close to addressing the legitimate criticisms of Go as a language. One of the things that's most irritating about Go enthusiasts is the way they try to close ranks on legitimate critique and reframe their language…

> rather carefully avoids coming anywhere close to addressing the legitimate criticisms of Go as a language. The "criticisms of Go are addressed every time the language is discussed: in practice, generics are rarely missed. They would be nice to have, but their absence is outweighed by other benefits of the language. Critiques of Go tend to be principal-based: "Go doesn't have features X, Y, and Z, therefore it canno…

It's clear that if a powerful language was such a competitive advantage, languages like Haskell would rule the world - instead they're hardly used for business projects.

Along comes Go and in 8 years people have built more production code with it than probably all the functional programming languages of the world combined. If that's not true yet, it will be soon the way the trend is going. And those languages have been around for many decades.

I think this means Paul Graham was wrong - a powerful language isn't a killer advantage. Other things matter more. Like simplicity that means being able to read other people's code and cooperate on a large code base. Strong language tooling. A batteries included standard library. Being able to hire developers not skilled in language X and get them up to speed quickly.

At the end of the day it seems pragmatic wins.

Re: 3.5 Years, 500k Lines of Go

#104

Post by gentoo »

kasey_junk wrote: post #100
voidlogic wrote: post #42

Earlier quoted context omitted.

Example, properties in C# can be method calls, and while they appear to have the complexity of accessing a field they actually could be arbitrarily algorithmically complex. This leads to a programmer down the road, calling it in a tight look, expecting field access overhead and getting somones complex property-method-logic. That is an example of magic. IMHO magic is when the run or space time complexity of a code isn…

So by that definition of magic, something like ranging over a channel is magic? It looks like a simple for each loop, just like over a slice or map, but under the covers involves locking semantics. If so, I guess I'll buy that definition of magic, I'm not sure thats any different than knowing what the language does .

In go, there are a minimal amount of primitives (like channels, slices) to learn. Once you know them, they're fairly intuitive.

In C#, properties can be arbitrarily complex. You can't just know how properties "work" and then do mental shorthand on them. Every time you look at a new codebase you might have to dig through several files to find out what one line does.

Re: 3.5 Years, 500k Lines of Go

#105

Post by NateDad »

excepttheweasel wrote: post #44

I think the go language has taken a position along the lines of "re usability and abstraction are overrated". I certainly think there is some truth to that, I am really enjoying working with go on smaller projects and it is this philosophy that has made understanding the code much easier. But I wonder how it really scales on a large code base like this? Some of the best projects I've worked on leverage usability more…

To actually answer the question - yes it holds true, yes it scales (in my experience). There are a lot of abstractions that we built for Juju. And we absolutely tried to ensure there was only a single source of truth for everything. It would have been totally unworkable if we couldn't reuse logic etc. We may not always have chosen the best abstraction, but that's a problem in any language.

Re: 3.5 Years, 500k Lines of Go

#108

Post by systems »

kasey_junk wrote: post #29
ben_pr wrote: post #9

I'm looking forward to my first project with GO. It appears to offer a lot with minimal complexity. > Because Go has so little magic, I think this was easier than it would have been in other languages. You don’t have the magic that other languages have that can make seemingly simple lines of code have unexpected functionality. You never have to ask “how does this work?”, because it’s just plain old Go code. That lack…

> That lack of magic I have a really hard time understanding what people mean when they say magic. In every language I've ever worked in I spend a fair bit of time saying "how does this work". Go doesn't seem any different in that regard to me.

One way to look at it is, some languages, I would suggest, C, C++, Clojure

When you start learning those languages, and then compare the code you write, to the code of popular major or standard libraries, they look completely different

They say, that Go is different and special this way, in that advanced Go code, doesn't look all that different from average Go code

Anyway, I can't really judge, I never looked or tried to learn Go, hence (They say)

Re: 3.5 Years, 500k Lines of Go

#109

Post by buckhx »

k__ wrote: post #79

Are generics really that big of a thing if you got structural typing? I mean, you don't have to implement all the interfaces explicitly, you just have to get your structure right and be done with it. Am I missing something?

It can be annoying to not have a generic collection. So if I build a heap I need to build it for a specific type or use interface{} as the values.

That being said, it's never been a deal breaker for me and don't end up missing generics THAT much.

Re: 3.5 Years, 500k Lines of Go

#110

Post by tonyarkles »

snoman wrote: post #99
voidlogic wrote: post #77

Earlier quoted context omitted.

When the programmer sees a function call they know its complexity is a O(?) and will (hopefully) vet it before calling it in a tight performance sensitive loop.

When a C# programmer sees any call to code they don't know - property or function - they should know its complexity is O(?) and will (hopefully) vet it before calling it in a tight performance sensitive loop. I get that someone could say "Go has fields, and they're always fast" and that seems like a great facility of the language, but any C# developer that says similar about instance members is wrong, and has some in…

A corollary to this is that C# property accesses can have side effects. I recently started working on a legacy code base where reordering access to a set of properties on an object resulted in different results!

And I'm not saying that properties are strictly a negative; in some cases, they can be very useful for refactoring an underlying implementation without having to change the API exposed to callers. But just like any magic, it needs to be applied thoughtfully and judiciously.

Post reply on HN