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

11–20 of 249 posts

Re: 3.5 Years, 500k Lines of Go

#11

Post by f2f »

akerro wrote: post #5
zalmoxes wrote: post #2

Great point about time. At work we've adapted github.com/WatchBeam/clock and it's helped a lot. Thanks for blogging about your work on juju! Despite Go already being five years old, many of the patterns around building large applications are only emerging now.

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

Go was announced to the world on November 10th, 2009.

Re: 3.5 Years, 500k Lines of Go

#12

Post by zalmoxes »

weberc2 wrote: post #8
zalmoxes wrote: post #2

Great point about time. At work we've adapted github.com/WatchBeam/clock and it's helped a lot. Thanks for blogging about your work on juju! Despite Go already being five years old, many of the patterns around building large applications are only emerging now.

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

Re: 3.5 Years, 500k Lines of Go

#14

Post by aaron-lebo »

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…

edit: there are other more useful responses

Re: 3.5 Years, 500k Lines of Go

#15

Post by grabcocque »

aaron-lebo wrote: post #14
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…

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.

Re: 3.5 Years, 500k Lines of Go

#16

Post by [deleted] »

grabcocque wrote: post #15
aaron-lebo wrote: post #14

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.

[deleted]

Re: 3.5 Years, 500k Lines of Go

#17

Post by rwmj »

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…

As with many programming language discussions, it's an experiment without a control.

Re: 3.5 Years, 500k Lines of Go

#18

Post by mynegation »

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) instead of having everything on one line. Similar problems with JSON files when new items added concurrently to the end of the array.

Re: 3.5 Years, 500k Lines of Go

#19

Post by jerf »

weberc2 wrote: post #8
zalmoxes wrote: post #2

Great point about time. At work we've adapted github.com/WatchBeam/clock and it's helped a lot. Thanks for blogging about your work on juju! Despite Go already being five years old, many of the patterns around building large applications are only emerging now.

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?

Mocking out the time functions means you don't get any race conditions. If you try to just twiddle with how long the time functions run, you still never quite know how long to set them. Bear in mind that even rather generous timeouts like a full millisecond to set a map entry in another goroutine can still fail if your system's CPU is loaded or the system is in swap, and spurious test failures are spurious test failures regardless of their cause. Often with this sort of code you're testing in one goroutine and the test code is in one or more other goroutines. If your test code can emit something down a synchronous channel, then your test code can also be sure it is staying in sync. I mean, even to test with "extra special small test timeouts" still means you're writing in extra test structure, you might as well just use one of these time mocking things. (In fact, you should generally always use time mocking libraries. In all languages, direct access to the system clock that can not be easily redirected for testing is at least a code smell and could possibly even rise to the level of "antipattern".)

I have a lot of places in my Go test code where my test code is deliberately pushing things down channels. It's one of the top reasons my test code often still ends up being in the same package, so it gets private access to those channels for safe, properly-sync'ed testing. (Not that I'm really all that concerned about trying to test only the public interface; I don't have a lot of troubles with that anyhow. YMMV.) I also have some places in my code where I have channels in the private interface of some goroutine server whose sole purpose in life is to sync with the tests. This generally appears when I have some server that I am sending a message that I expect to change the state of the server, but for which there is no reply. In order to verify that the proper changes have occurred in the data structures of the server, I need to sync with the change before I do the check. Having a simple struct{} channel whose sole purpose in life is to synchronize works well enough for that.

Re: 3.5 Years, 500k Lines of Go

#20

Post by lossolo »

mylons wrote: post #13

And half are from dependencies? ;)

Read the article:

As of this writing, the main repo for Juju, http://github.com/juju/juju, is 3542 files, with 540,000 lines of Go code (not included in that number is 65,000 lines of comments). Counting all dependencies except the standard library, Juju is 9523 files, holding 1,963,000 lines of Go code (not including comments, which clock in at 331,000 lines).

Post reply on HN