Live data from Hacker News

3.5 Years, 500k Lines of Go

npf.io

41–50 of 249 posts

Re: 3.5 Years, 500k Lines of Go

#41
post #28

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…

Sadly yes, today I learned C# is a programming language for 10x programmers.

Why is this a surprise? Microsoft employs a fair chunk of the researchers currently working on functional programming languages in industry. The ideas get exchanged between Haskell, F#, and C#. Look at C# 7.0, where many of the new features seem to be an effort to make the language friendlier to Haskell programmers.

At least, that's my perspective as someone who uses Haskell.

Re: 3.5 Years, 500k Lines of Go

#42
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.

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't obvious by its on-screen representation.

Re: 3.5 Years, 500k Lines of Go

#43

Earlier quoted context omitted.

edit: there are other more useful responses

Actually, I can't deny that I'm a language snob. I also don't think that's a bad thing. I find Go's magical maps and slices, its null pointers, its verbose error handling and its lack of generics to all be in fairly poor taste. So, yeah, I'm a snob.

Few people would accuse airline pilots, surgeons, construction engineers of snobbery for demanding high standards.

When it comes to software, challenging this "everything goes" culture is called "snobbery". People are called "senior engineer" after 2 years of copypasting javascript from stack overflow - and become "proficient" in a language in a week.

And yet we wonder why so much software is bloated, unreliable, insecure, overly expensive to develop.

Re: 3.5 Years, 500k Lines of Go

#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 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?

Re: 3.5 Years, 500k Lines of Go

#45

Wonder how long does it take to build juju?

42 seconds.

Just tried it with go 1.8 and a clean gopath (after downloading). That's on a 3 year old quad core i7 laptop w/ SSD. That's `go install github.com/juju/juju/...` which actually builds two binaries - the client and the server.

Re: 3.5 Years, 500k Lines of Go

#46
post #38

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…

I can't believe that I read a nice article about working on a massive project in Go over a couple of years - a meaningful experience that we could probably all learn from - and the top comment doesn't build on the content of the post at all, but is rather a thinly veiled accusation of "Go is a terrible language".

Really? Because your profile says you've been a member for over 2700 days, so you should be used to HN comments by now.

Re: 3.5 Years, 500k Lines of Go

#47
post #8

Earlier quoted context omitted.

This is a minor nit, but it seems to me that it would have been easier to configure the unit with a shorter timeout duration rather than mocking out the time functions. Am I mistaken?

It really depends. You might want to test something that requires days/weeks expiration. I would agree that the Clock interface is a bit large. In personal projects I prefer to just have something simple like timer func() time.Time

I don't understand your argument. What's special about a days/weeks that would prevent you from shortening this value for your tests? In other words, if I want to test my timeout logic, it should be independent of the timeout value, so I should be free to use a shorter timeout value in my timeout tests.

Re: 3.5 Years, 500k Lines of Go

#48

Off topic rant: I don't know much about the details of godeps hash file but I do wish that there were a better infrastructure for merging contents of various file formats. Built into git or shipped as a separate repository. I wasted too much time merging vcxproj.filters files just because in its XML representation one item of a sequence of folder assignments occupies 3 lines (opening tag, contents, closing tag) inste…

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.

Re: 3.5 Years, 500k Lines of Go

#49
post #30

Earlier quoted context omitted.

Grabcocque is not advocating for less in the marketplace of ideas. He's advocating for quality criticism. But what are you trying to say? That grabcocque doesn't think there's more than one way to do things? That he's a snob? That he should get over himself? Why do you hide your derogatory speech behind implications and snideness?

Grabcocque is not advocating for anything, but attacking the article and go enthusiasts. There is no criticism to Go as a language presented, only criticism of those that claim to be productive in it. In fact in its original form the comment contained only the link to the blub article and nothing else. This isn't enlightened discourse, this is a knee-jerk reaction :)

I just found it problematic that aaron-lebo was specifically and snidely attacking a user's personality, whereas grabcocque was attacking an article author.

At this juncture the conversation had shifted from Go to a question of conduct.

Re: 3.5 Years, 500k Lines of Go

#50
post #5

Earlier quoted context omitted.

Go was released in 2007, it's 10 years old. Rust is closer to be 5yo, it's 7yo according to wikipedia.

It only became stable in mid-2015. https://blog.rust-lang.org/2015/05/15/Rust-1.0.html

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