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

31–40 of 249 posts

Re: 3.5 Years, 500k Lines of Go

#31

Post by noir_lord »

alsadi wrote: post #25
therealmarv wrote: post #3

What do people think about the future of Juju?

For automation of deployments we prefer ansible (ex. it's agent-less) For container orchestration it's clear that kubernetes is the winner (if you have k8s deployed you don't need juju) For managing the whole thing manage iq have much to offer.

I like Ansible and use it for deploying vagrant setups and such but I've found quite a few things broken enough that I'm wary of using it to do deploy production stuff for quite a while I had issues with apt: so much so I ended up using shell, last time I wrote a new playbook they had resolved that though so things do get fixed.

Re: 3.5 Years, 500k Lines of Go

#32

Post by emodendroket »

jerf wrote: post #26
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…

You're now the third person in the past couple of weeks I've seen who are insisting that the only explanation is that Go language users must be ignorant of all these other wonderful features. But I'd say that in order for that to be true, you must believe that there is a large number of Go programmers who either learned Go for their first language, or their other languages they know are all bereft of these features.…

If they came from any scripting language they probably have never worked with generics -- that doesn't really strike me as an outlandish scenario.l

Re: 3.5 Years, 500k Lines of Go

#33

Post by infogulch »

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 sufficient to locate problem areas.

But then package management is listed as an honest pain point.

Anything else?

Re: 3.5 Years, 500k Lines of Go

#34

Post by johnfn »

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.

When people say "magic", what they often mean is "code over here can effect the execution of code over there in an implicit way". Like in Ruby, I could conditionally monkey-patch a function into an object someone way over there was using, causing code to break.

Other languages, like those with stronger type systems, will not allow this to happen.

Re: 3.5 Years, 500k Lines of Go

#35

Post by jerf »

emodendroket wrote: post #32
jerf wrote: post #26

Earlier quoted context omitted.

You're now the third person in the past couple of weeks I've seen who are insisting that the only explanation is that Go language users must be ignorant of all these other wonderful features. But I'd say that in order for that to be true, you must believe that there is a large number of Go programmers who either learned Go for their first language, or their other languages they know are all bereft of these features.…

If they came from any scripting language they probably have never worked with generics -- that doesn't really strike me as an outlandish scenario.l

Ask a dynamic language enthusiast about that. Dynamic languages don't have "proper generics" but what they do have is all the generic use cases covered... so... which is more important, having a particular feature, or being able to do all the things that the feature can do?

A generic enthusiast can argue that the type safety is a fundamental difference. A dynamic language enthusiast is obviously going to take issue with that. I'll let the two of you fight it out.

From a Haskell perspective, dynamic types and the sort of generics that Java implements are probably closer together than you might think. Haskell expects your "generics" (which are actually the type classes; what haskell calls "generics" is more like what other languages call "reflection") to be able to provide mathematical guarantees like "If I have an A, I am guaranteed to be able to produce a B for that" which is much stronger than what imperative generics tend to be able to guarantee.

Re: 3.5 Years, 500k Lines of Go

#36

Post by rogpeppe1 »

jerf wrote: post #19
weberc2 wrote: 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?

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

> 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 not uncommon in practice.

I think clock-mocking can be very useful for testing hard-to-reach places in leaf packages. But at a higher level, I think it can end up producing extremely fragile tests that depend intimately on implementation details of packages that the tests should not be concerned about at all. In these cases, I've come to prefer configuring short time intervals and polling for desired state as being the lesser of two evils.

Re: 3.5 Years, 500k Lines of Go

#37

Post by eriknstr »

mynegation wrote: post #18

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…

I found a program someone wrote called sortxml that will prettify and sort XML files. It's written C#. Might be possible to run it on Linux also, or to find another similar program for Linux that will. I'd investigate further if it wasn't for the fact that I rarely work with XML files.

https://github.com/kodybrown/sortxml

You may be able to write a small wrapper script that does the following: For each filename passed as argument to your script you will run sortxml on it and store the result in a temporary file, then once you've done so for all files, you pass the sorted files to an existing merge tool such as for example meld, kdiff3 or vimdiff.

Let's say that you name your script mergexml.bash and that you put it in ~/bin/. Then it should be possible to first git merge as usual but when a conflict arises in an XML file, you will run something like

  git mergetool -t ~/bin/mergexml.bash example.xml
And your script will have simplified the process.

For bonus points, you might write an unsortxml program that your script will call at the end to rearrange the nodes and attributes to be in the same order as they were in one of the original XML files -- the user would be prompted to select which of the original XML files to use for ordering the nodes and attributes.

I haven't tested this of course, otherwise I'd probably have actual code to share for it but I think something like what I've outlined above should work.

Re: 3.5 Years, 500k Lines of Go

#38

Post by johnfn »

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…

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

Re: 3.5 Years, 500k Lines of Go

#39

Post by sinatra »

emodendroket wrote: post #32
jerf wrote: post #26

Earlier quoted context omitted.

You're now the third person in the past couple of weeks I've seen who are insisting that the only explanation is that Go language users must be ignorant of all these other wonderful features. But I'd say that in order for that to be true, you must believe that there is a large number of Go programmers who either learned Go for their first language, or their other languages they know are all bereft of these features.…

If they came from any scripting language they probably have never worked with generics -- that doesn't really strike me as an outlandish scenario.l

You're missing his point. Maybe you should consider that people who don't have the same opinion as you (Go doesn't have this feature, so it sucks) don't have the same opinion for valid and rationale reasons, not just ignorance.

Re: 3.5 Years, 500k Lines of Go

#40

Post by tonyedgecombe »

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…

> It appears to offer a lot with minimal complexity.

Actually I think it offers little with minimal complexity.

Post reply on HN