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

81–90 of 249 posts

Re: 3.5 Years, 500k Lines of Go

#81

Post by alpeb »

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 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 lots of people working together, usually the effectiveness of that collaboration is the hardest of all problems, well above the technical problems. Most of all modern programming languages can solve all the problems, in different ways. So the criteria for selecting a language is not power, but how it facilitates existing and new members of a team to make progress.

Re: 3.5 Years, 500k Lines of Go

#82

Post by jerf »

emodendroket wrote: post #57
sinatra wrote: post #39

Earlier quoted context omitted.

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.

Maybe so, but I reject the argument put forward in favor of that position.

I actually lean in your direction. I've strongly headed back to static typing in the last 3-4 years after a lot of dynamic typing. I'm just not in the mood to have that argument with dynamic typing enthusiasts right now. :) I've done my time on that battlefield.

Re: 3.5 Years, 500k Lines of Go

#83

Post by Koshkin »

NateDad wrote: post #68
emodendroket wrote: post #32

Earlier quoted context omitted.

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

I worked in C++, C#, and Java for 15 years before my work in Go. I've used generics. I will freely admit to not having a lot of experience in functional or ML style programming languages a la Rust. I'd love to spend some time getting up to speed on Rust, it seems like an interesting language, and at the very least, a great learning experience.

If you want to learn an interesting language, try Swift.

But if you really want a "great learning experience", you should look at Haskell or F#.

Finally, if you want your mind blown, learn yourself a Lisp.

Re: 3.5 Years, 500k Lines of Go

#84

Post by microtonal »

NateDad wrote: post #68
emodendroket wrote: post #32

Earlier quoted context omitted.

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

I worked in C++, C#, and Java for 15 years before my work in Go. I've used generics. I will freely admit to not having a lot of experience in functional or ML style programming languages a la Rust. I'd love to spend some time getting up to speed on Rust, it seems like an interesting language, and at the very least, a great learning experience.

I would definitely recommend looking at Rust (and the ML family).

I have spent most of my programming life in C++, Java, and Prolog (probably in that order). Two years ago I switched to Go for most of my work, because I needed a native language, C++ was just becoming too much effort, and Rust was still changing monthly. I have written some substantial projects in Go, including a neural net natural language parser and a part-of-speech tagger, both used to annotate web corpora.

Since 1.0 has been released I have slowly transitioned into Rust and am now using it for most new work. What I strongly like about Rust above Go: parametric polymorphism (which I do use on a daily basis), limited operator overloading, sum types, RAII, the borrows checker, Cargo, quickcheck [1]. What I strongly dislike compared to Go: compile times.

Deep in my heart, I like ML more than Rust ;), but having a quickly-growing ecosystem is also important.

[1] There is property-based checking for Go, but in my experience it's usefulness grows with the strength of the type system.

Re: 3.5 Years, 500k Lines of Go

#85

Post by jerf »

rogpeppe1 wrote: post #36
jerf wrote: post #19

Earlier quoted context omitted.

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 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 intimately on implementation details of packages that the tests should not be concerned about at all."

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.

It may also help to understand my opinion when I point out that I tend to break my packages down significantly more granularly than a lot of the rest of the Go community, which in my opinion is a little too comfortable having the "main app" directory contain many dozens of .go files. My packages end up way smaller, which also mitigates against the issues of excessively-coupled tests. I have a (not publically published) web framework, for instance, that is broadly speaking less featureful than some of the Big Names that are all in one directory (though it has some unique ones all its own), but is already broken up into 16 modules.

Re: 3.5 Years, 500k Lines of Go

#86

Post by RSZC »

alpeb wrote: post #81
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 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…

Conversely, though, if moving to a higher level language / paradigm makes you more productive, you may not need so many people in the first place.

Modern-day parallel would probably be WhatsApp, with Erlang taking the place of Lisp.

Re: 3.5 Years, 500k Lines of Go

#87

Post by threatofrain »

alpeb wrote: post #81
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 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…

I agree with your framing that the collaboration aspects of large projects are probably harder than the technical aspects.

However, I think there are still lingering questions about whether the "power" of a language has noteworthy interaction with the difficulties of collaboration. For example, some might argue that the guard rails put up by FP languages allows them to reason better about interaction with colleagues' code. Talking to colleagues about code interaction is a human collaboration problem too.

If that's the case, then part of choosing a programming language is also in service to mitigating the difficulties of collaboration.

Re: 3.5 Years, 500k Lines of Go

#88

Post by infogulch »

voidlogic wrote: post #78
infogulch wrote: post #52

Earlier quoted context omitted.

I don't think that's quite right. E.g. if you do call a method, it's complexity is unknowable with only local context, so it can't be obvious. I would rewrite that to: > Magic is when the run or space time complexity of code is misleading by its on-screen representation. An apparent field access that is actually a method is misleading. Calling a method explicitly just directs you to check that method to know for sure…

I think we are on the same page.

Yes, I'm just being pedantic about how you say it. :)

Re: 3.5 Years, 500k Lines of Go

#89

Post by Filligree »

weberc2 wrote: post #70
grabcocque wrote: post #15

Earlier quoted context omitted.

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.

> I find Go's magical maps and slices Magical? What's magical about a hashmap or a pointer into an array? There are a lot of valid criticisms of Go; "magic" is not one of them.

Go has special syntax for channels, maps and slices. It's impossible to define your own data structures using the same syntax.

An argument can be made for array subscripts, certainly, but why can't you use 'make' for your own code?

They're also magic in that Go does have generics, but only for those three types.

Re: 3.5 Years, 500k Lines of Go

#90

Post by jimktrains2 »

NateDad wrote: post #50
jimktrains2 wrote: post #7

Earlier quoted context omitted.

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.

I wouldn't say rust was hugely adopted before 1.0 (not that it's hugely adopted after, either).
Post reply on HN