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

141–150 of 249 posts

Re: 3.5 Years, 500k Lines of Go

#141

Post by taco_emoji »

jerf wrote: post #72
jasode wrote: post #66

Earlier quoted context omitted.

>... Go language users must be ignorant of all these other wonderful features. All of your comments are reasonable but I don't think it addresses what grabcocque was complaining about. It seems grabcocque was criticizing the writing about Go but others seem to be interpreting it as an insult to Go programmers . They are 2 different things! (My guess is that the word "blub" triggers the misinterpretation.) All of the…

"Whenever I see a writer talk about "magic", "simplicity", "spooky action at a distance", etc it usually turns out that the author picked adjectives that sounded good but not well-defined enough for readers to learn anything useful from it." A valid objection. Here's my personal definition for "magic", which is still a bit fuzzy around the edges, but much more solid than most loose definitions of it: A bit of code is…

I really appreciate this definition of "magical"... reminds me of some code I was reviewing that was something like this:

HTML:

    Foo
    Bar
JS:

    var handlers = {
        fooClicked: function() { /* stuff */ },
        barClicked: function() { /* stuff */ },
        /* etc */
    };

    $('.does-stuff').each(function() {
        $(this).click(handlers[this.id + "Clicked"]);
    });
And like... OK, that's clever, but when I'm debugging the fooClicked() method 4 months from now, I can't just do a Find All for "fooClicked" and track down where it's being called from.

Re: 3.5 Years, 500k Lines of Go

#142

Post by johnfn »

brightball wrote: post #80
johnfn wrote: post #34

Earlier quoted context omitted.

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.

Yea, monkey patching is helpful when dealing with a 3rd party library that needs to be tweaked 10 layers up the inheritance chain without having to change the object type all over the whole system. If it gets overused it causes problems but there are times when it is close to a miracle. That said, there is a reason ruby devs are so test conscious.

Yeah - of course monkey patching has good uses :) The problem is that when you're trying to debug an issue, it's another thing that you'll have to remember - "is anyone monkey patching something in here?"

Re: 3.5 Years, 500k Lines of Go

#143

Post by threatofrain »

gatestone wrote: post #129
alpeb wrote: post #81

Earlier quoted context omitted.

The Blub Paradox argument basically states that you must use the most powerful language because it's the only one that'll let you have a broader perspective to judge all the other programming languages. Ironically, this kind of perspective is very narrow itself. You gotta consider the ultimate goal of writing software is to generate solutions that successfully solve users' problems. For complex problems that require…

The mentioned paradox is simply not true. How would being fluent in Haskell make you appreciate the need for assembler programming in, say, math opitimizations in Go crypto packages, or any low level stuff?

I would like to hear this claim with more specificity, like if the claim is that learning Clojure will help you predict how the language atoms of Go might lead to some structures, or more narrowly that if Clojure has more supported concurrency models, then it helps you judge Go vs Elixir from a concurrency perspective, or if learning a multi-paradigm language helps you judge a language with a paradigm focus.

Re: 3.5 Years, 500k Lines of Go

#144

Post by goatlover »

weberc2 wrote: post #63
excepttheweasel wrote: post #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…

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

Re: 3.5 Years, 500k Lines of Go

#145

Post by jd20 »

lloeki wrote: post #121
kasey_junk wrote: post #29

Earlier quoted context omitted.

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

Rails is the epitome of the magic philosophy. Stuff "happens" through inference because you touched some part of the code (check out routes, foo_{url,path} methods, url_for , and passing some models as argument to those), or the database schema (defining accessors from DB fields or adding features when magic-imbued names are used, such as type , version or foo_id / foo_type ). This makes one feel fast and powerful at…

I've been pondering this topic lately, as I come back to Rails (seems every few years I'll write a Rails app on the side, and my brain has totally forgotten everything since last time): one other way to look at this "magic", is it makes programming feel "intuitive". Not sure how to do something, I often find I can just "guess" the right and most natural way, and the code will just work. For that reason, I always feel like I'm most productive when writing Ruby (I really love Go too, just for different reasons).

I can totally see how the situation you describe would be frustrating too, I felt the same about Java annotations when they came out, and on massive code bases it could become a nightmare when used to the extreme. My own experience has been that Go scales very well to large code bases, I've never wanted to try the same with Rails.

Re: 3.5 Years, 500k Lines of Go

#146

Post by goatlover »

grey-area wrote: post #133
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…

The blub article assumes that the computer is the ultimate arbiter of language utility: But Lisp is a computer language, and computers speak whatever language you, the programmer, tell them to. A program, especially a large one, spends far more time being read by humans than being written. Computer languages need to be readable by humans , they need the right abstractions, and the minimum of those, so that there is l…

Doesn't Graham in his Lisp book talk about how using macros properly leads to more readable and maintainable code, and that Lisp is great at producing that kind of code in general because you can mold it to closely fit the problem domain?

Re: 3.5 Years, 500k Lines of Go

#147

Post by infogulch »

f2f wrote: post #23
rjammala wrote: post #21

Wonder how long does it take to build juju?

dave cheney has been tracking juju build times since the regression in the compiler when it was rewritten from C to go: older article here: https://dave.cheney.net/2016/04/02/go-1-7-toolchain-improvem... spreadsheet: https://docs.google.com/spreadsheets/d/1mczKWp3DUuQvIAwZiORD...

Wow the latest revision is down to 140% of 1.4.3. I'm impressed.

Re: 3.5 Years, 500k Lines of Go

#148

Post by goatlover »

goatlover wrote: post #118
eloff wrote: post #103

Earlier quoted context omitted.

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

And really, it's Go versus C++, C# and Java that's the actual comparison, not Haskell. That's what Go competes with, and then Python, Ruby, PHP and Node on the web server side.

Lauding Go's success over Haskell is not really saying much.

Re: 3.5 Years, 500k Lines of Go

#150

Post by dasil003 »

greenhouse_gas wrote: post #132

I happened to believe that a language should have one style. You want a functional language? Use it. You want a procedural language? Use it. You want an OOP language? Use it. They're all good, but not in one language. For example, you like FP idioms, and program everything with maps. I like for loops. You have to fix my code one day I'm on vacation. You think that it's ugly, and rewrite it as a map. I get back, bug c…

Even though I've written more ruby than anything else over the last decade, I have to agree with this. Ruby is nice OO language, but it's unabashedly multi-paradigm, and that leads to a lot of mess when you get a team with varying backgrounds the result is potentially a byzantine mix of procedural, object-oriented and functional styles.
Post reply on HN