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

111–120 of 249 posts

Re: 3.5 Years, 500k Lines of Go

#111

Post by gatestone »

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.

Magic is when you access struct pointer members w/o the asterisk. ;-)

Re: 3.5 Years, 500k Lines of Go

#112

Post by NateDad »

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 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 + could in theory do anything. And what's bad about that is that it is deceptive. It's easy to miss the fact that this line might actually be doing something complex.

It also means that if someone is looking at your code, they can't make any assumptions about what any particular line of code is doing, without complete understanding of a vast amount of code.

This is one of the pieces of magic that I'm glad go doesn't have.

Re: 3.5 Years, 500k Lines of Go

#113

Post by rogpeppe1 »

jerf wrote: post #85
rogpeppe1 wrote: post #36

Earlier quoted context omitted.

> Mocking out the time functions means you don't get any race conditions. This is a common misapprehension. Actually, even if you fully mock out time, you can still get race conditions, because goroutines can remain active regardless of the state of the clock, and there's no general way to wait until all goroutines are quiescent waiting on the clock. This is not just a theoretical concern - this kind of problem is no…

OK, correction acknowledge (no sarcasm), mocking out time functions means you can write test code that doesn't have any race conditions. "and there's no general way to wait until all goroutines are quiescent waiting on the clock." Hence my semi-frequent usage of "sync" channels which I described in the previous post. "But at a higher level, I think it can end up producing extremely fragile tests that depend intimatel…

> I'd rather have a test that correctly reasonably verifies that a package is correct (or at least "passes the race detector consistently") and reaches into some of the private details than fail to test a package. Too many bugs I've found that way.

I agree with this, with the caveat that if you can test a package with regard to its public API only, it is desirable to do so because it gives much greater peace of mind when doing significant refactoring.

The difficulty comes in larger software where the package you're testing uses other packages as part of its implementation which also have their own time-based logic. Do we export all those synchronisation points so that importers can use them to help their tests too? If we do, then suddenly our API surface is significantly larger and more fragile - what would have been an internal fix can become a breaking change for many importers.

Re: 3.5 Years, 500k Lines of Go

#114

Post by oppositelock »

VMG wrote: post #95

> The first was assuming forward slashes for paths in tests. So, for example, if you know that a config file should be in the “juju” subfolder and called “config.yml”, then your test might check that the file’s path is folder + “/juju/config.yml” - except that on Windows it would be folder + “\juju\config.yml”. Wait what? I thought this was solved ten years ago https://en.wikipedia.org/wiki/Path_(computing)#MS-DOS.2F…

Go gives you the tools to handle this, but you have to do it yourself. filepath.Join(), filepath.ToSlash() and filepath.FromSlash() are used for this.

I find myself very productive in Go, I've written a lot of it now, but I do also find myself writing more code than I thought I would, having had some expectations set by Python and Java. Go's philosophy seems to avoid doing something which can be done incorrectly, and instead punting it to developers. It's not always as simple as simply replacing forward and backward slashes.

Re: 3.5 Years, 500k Lines of Go

#115

Post by omegaham »

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…

> I know this is heresy, but has this article really held up well over time?

One immediate thought that I have - programming is now much more accessible. High-quality compilers are much easier to get, good documentation is much easier to find. Much fewer people have done nothing but work on one language, one technology stack, etc. They still exist, of course, but they're much fewer in number.

This means that people are more likely to choose the right tool for the job, which kinda defeats the point of the Blub paradox - that people's perspectives on problems are constrained by the languages that they know.

Seeing as how a lot more people are dicking around with Haskell and Lisp in college and in toy projects, I don't think that this is as much of an issue. You know what generics are, and you've used generics in other code, but you're making the conscious decision not to use a language that has them in order to get better traits in other areas.

Re: 3.5 Years, 500k Lines of Go

#116

Post by whateveracct »

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?

Yes they are. And actually they would play nice with generics! Imagine

    type Ord a interface {
      Compare(a) int
    }
Also it would be nice to do something like

    func Max[a
(Syntax stolen from Scala)

Right now, interfaces are too opaque. You can't take a value of interface type X and return the same type. You have to return an opaque X, which gives you no guarantees about its concrete implementation. Parametricity is an extremely well-motivated and solved language feature!

I think if you add parametricity to Go functions (not even parametric types. Just type variables that play nice with all the builtins) you can write this and get guarantees about its implementation (assuming it follows the functor laws)

    func map[a,b](func(a) b, []a) []b

Re: 3.5 Years, 500k Lines of Go

#117

Post by infogulch »

themihai wrote: post #101
infogulch wrote: post #33

Earlier quoted context omitted.

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

Right. My point is that it's acknowledged and not dismissed or reframed at all.

Re: 3.5 Years, 500k Lines of Go

#118

Post by goatlover »

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…

Or Haskell is just too different from what most programmers are familiar with. It's not really Go versus Haskell, It's Haskell/Ocaml/ML/Lisp versus mainstream languages.

It's also not like Go is the only popular language. Other popular languages like Javascript, C# or Python have plenty of features and magic. Also, Elixir seems to be doing pretty well, so maybe that's a way for functional languages to gain traction.

Elixir, being newer, was made with modern environments and tooling in mind. Go has the same advantage.

Re: 3.5 Years, 500k Lines of Go

#119

Post by greenhouse_gas »

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…

I've got another heresy coming up:

Outside of very specific fields, language doesn't matter.

I was quite strongly attacked on another thread for implying that WhatsApp is just another CRUD app.

The thing was that I wasn't bashing their dev team. They could have done a crazy amazing job, and it helped their company take off, but what was their secret sauce?

The ability to have an (almost) free SMS/MMS app which worked the same across all devices and worked with numbers rather than names/userid's, followed by network affects.

They could have written it in PHP and have it take off. And a competitor could have written it Haskell and had it fail.

(FB is written in PHP, MySpace was written in CF, Friendster was written in jsp, so logically PHP > CF > Friendster. Therefore, PHP > Java. QED?)

Twitter didn't fail because it was written in Ruby. It failed because of business.

Diaspora isn't FB not because of tech, but because of business.

Re: 3.5 Years, 500k Lines of Go

#120

Post by jksmith »

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…

Yes. A toolchain that's easy to code, easy to test, and easy to hire for provides more business value, especially as teams get larger. Why this is assumed to be some xor with advanced or clever programmers is really too bad, because actually the same toolchain supports keeping more of the solution in the advanced programmer's head over the same experience with a complicated toolchain, in my experience.
Post reply on HN