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

161–170 of 249 posts

Re: 3.5 Years, 500k Lines of Go

#161

Post by fauigerzigerk »

kasey_junk wrote: post #136
gentoo wrote: post #104

Earlier quoted context omitted.

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.

But the "magic" in this case is that properties can be methods. Once you know that how is it any different than methods? In go methods can be arbitrarily complex. You can't know how they work without digging through several files to find what one line does. Another example of magic in go would be method names . You have no idea if it is safe to change the name of a method because it could be satisfying an interface f…

>But the "magic" in this case is that properties can be methods. Once you know that how is it any different than methods?

It's different because you have to apply that general knowledge in every single case when reading code that you are not familiar with.

In Go or Java, the information on whether a.x is a constant time variable access or a function call of arbitrary complexity is available at the call site. You don't have to look it up. It's one less thing to do when reading code.

And when you do have to look up what an expression means, how straightforward is it? Consider this expression:

  f(x)
In Go f(x) means whatever the function f does, and f is exactly one function in the current package.

f(x) in C++ (and to a slightly lesser degree in Java, C# or Swift) is one of a set of functions called f. Knowing which one actually gets called requires knowledge of tens of pages of name lookup rules plus knowledge of possibly large swaths of the codebase.

It is often claimed that languages more powerful than Go just have a steeper learning curve. But it's not true. Even if you know all the name lookup rules of your favorite language (do you?), you still have to apply them every single time you read unfamiliar code.

In my view it's pretty simple. If you have to read a lot of unfamiliar code all the time then Go is great. If you can know both a more powerful language and your codebase inside out, then Go will be frustrating for its lack of abstraction features.

Re: 3.5 Years, 500k Lines of Go

#162

Post by weberc2 »

goatlover wrote: post #144
weberc2 wrote: post #63

Earlier quoted context omitted.

> 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 effectively to create a sort of vocabulary. They're far more concise, there is rarely more than one source of truth, they're far easier to change and improve. Does this hold true for 540,000 lines of go code? Doesn't this article speak to this? It mentions juju has over a million lines.

Yeah, but there is no comparison to the same project done in Lisp, Haskell, Java, etc. All the author is doing is relating their success using Go, which is great, but there is no comparison to how it would have fared in another language, except his previous frustrations with C#, on other projects, I guess.

It would be ridiculous to expect Canonical (and even moreso, the author alone) to rewrite juju in another language as a simple comparison. Even if it were feasible, the comparison would be polluted by the experience gained by building the application initially (or you could rebuild with a completely new team of developers, but then you're introducing a whole new set of variables). The best we can reasonably do is compare applications aggregating on language.

Re: 3.5 Years, 500k Lines of Go

#163

Post by stymaar »

jimktrains2 wrote: post #90
NateDad wrote: post #50

Earlier quoted context omitted.

Comparing 1.0's is a much better comparison, except in cases where there was huge adoption before 1.0.

I wouldn't say rust was hugely adopted before 1.0 (not that it's hugely adopted after, either).

I think gp meant that for some platforms it can make sense to count even 0.x releases (nodejs is the best example I think), even though for most it doesn't (including Rust and Go).

Re: 3.5 Years, 500k Lines of Go

#164

Post by rogpeppe1 »

NateDad wrote: post #48
rogpeppe1 wrote: post #27

Earlier quoted context omitted.

The godeps file is just a dependency-per-line, tab-separated values, deliberately so it's easily amenable to shell script processing. Aside: the conflicts mentioned in the article should never be a real problem because you can always resolve the conflict by just recreating the dependences.tsv file (you should never be editing it manually anyway).

That's not exactly true, Rog. If two people have changed the file, which causes a conflict, then you have resolve the conflict manually. Recreating the file with godeps would populate it with whatever commit happens to be in your gopath right now, which has no relevance to what is conflicted in the file and could be a completely different hash.

I tend to check out one branch, run godeps -u, then check out the other one and run godeps -N -u. Then you've got the newest deps from both branches. I still wouldn't resolve the conflict manually.

Re: 3.5 Years, 500k Lines of Go

#165

Post by NateDad »

Nanshan wrote: post #106

I think the author just wan to said: choice Go is exactly a mistake.

_>

No.

Go was a good choice. The project benefited from it, both from a hiring perspective and from a technical perspective. If I were in charge, I would make the exact same choice again.

Juju lives exactly in Go's sweet spot. A networked server worked on by more people than you can fit around your dining room table. Not every project would benefit from Go, but this one certainly did, IMO.

Re: 3.5 Years, 500k Lines of Go

#166

Post by brightball »

eloff wrote: post #103
akinalci wrote: post #92

Earlier quoted context omitted.

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

To be fair

> Along comes Go

Really means

> Along comes Google

It's nothing against Go, but we have to be realistic that having Google's weight behind it significantly increases its marketing while also making business owners a little more comfortable (aka - a modern nobody ever got fired for buying IBM).

There are a lot of frontend frameworks out there but React and Angular dominate largely because of Facebook and Google's influence.

That said, every language has tradeoffs. All you have to be able to do in order to have a rational conversation is to acknowledge those tradeoffs. Go has some tradeoffs but there's a general feeling that the resulting balance is worth it.

Re: 3.5 Years, 500k Lines of Go

#167

Post by jy3 »

pjmlp wrote: post #122
NateDad wrote: post #112

Earlier quoted context omitted.

one of the things that go eschews is operator overloading. a := b + c What's the runtime complexity of this statement? How much memory will it cause to be allocated? In go there's only two possibilities for what this code is doing... either this is string concatenation, or it's adding two numbers. Both of which are immediately comprehensible for impact on run time and memory. In C#, you can overload operators, so the…

a := Sum (b, c) How can you be sure that Sum actually does a sum without looking at its implementation?

I think you are missing the point. Of course you can't assume what a function will do with certainty.

Re: 3.5 Years, 500k Lines of Go

#168

Post by NateDad »

zzzcpan wrote: post #155
NateDad wrote: post #112

Earlier quoted context omitted.

one of the things that go eschews is operator overloading. a := b + c What's the runtime complexity of this statement? How much memory will it cause to be allocated? In go there's only two possibilities for what this code is doing... either this is string concatenation, or it's adding two numbers. Both of which are immediately comprehensible for impact on run time and memory. In C#, you can overload operators, so the…

"they can't make any assumptions about what any particular line of code is doing, without complete understanding of a vast amount of code." Yes, this is a problem with many designs. More importantly they can't easily look up what does an operator do. But this problem can be easily avoided if a set of operators used in a particular scope had to be explicitly specified. For example, if you want "+" to mean a bigint add…

I agree, I wish + wasn't string concatenation either.

Re: 3.5 Years, 500k Lines of Go

#169

Post by NateDad »

microtonal wrote: post #84
NateDad wrote: post #68

Earlier quoted context omitted.

I worked in C++, C#, and Java for 15 years before my work in Go. I've used generics. I will freely admit to not having a lot of experience in functional or ML style programming languages a la Rust. I'd love to spend some time getting up to speed on Rust, it seems like an interesting language, and at the very least, a great learning experience.

I would definitely recommend looking at Rust (and the ML family). I have spent most of my programming life in C++, Java, and Prolog (probably in that order). Two years ago I switched to Go for most of my work, because I needed a native language, C++ was just becoming too much effort, and Rust was still changing monthly. I have written some substantial projects in Go, including a neural net natural language parser and…

I really want to learn Rust. It's been on my next-to-learn list for a while now. I have limited time because of young kids and getting embroiled in politics (actual politics). Someday :)

Re: 3.5 Years, 500k Lines of Go

#170

Post by NateDad »

rogpeppe1 wrote: post #164
NateDad wrote: post #48

Earlier quoted context omitted.

That's not exactly true, Rog. If two people have changed the file, which causes a conflict, then you have resolve the conflict manually. Recreating the file with godeps would populate it with whatever commit happens to be in your gopath right now, which has no relevance to what is conflicted in the file and could be a completely different hash.

I tend to check out one branch, run godeps -u, then check out the other one and run godeps -N -u. Then you've got the newest deps from both branches. I still wouldn't resolve the conflict manually.

TIL I learned about godeps -N.... a month too late :) Cool, though, that definitely would help with that problem.
Post reply on HN