Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Love Go; I Hate Go

dtrace.org

Post reply on HN
Print view View original

81–90 of 329 posts

Re: I Love Go; I Hate Go

#81

Post by dang »

Sylos wrote: post #80
dang wrote: post #77

Earlier quoted context omitted.

As Tomte and jdoliner pointed out, 4 points in 11 minutes would get you on the front page at any time, let alone a slow time like this one. As for why the post would get rapid votes, that's easy: moth-to-flame subject matter. It's not great to post comments like this taking a thread so badly off topic, let alone jumping to conclusions that the admins are manipulating what is obviously (once you're familiar with it) b…

That seems like a dangerous system, though. Just a few coordinated upvotes can get a post to the front page. And if it's so easy, you'll almost certainly have people/companies abusing that to promote their content.

Sure, but this problem has been around for years, and HN has developed many mechanisms to deal with it. Some are obvious—if a post gets to the front page without community interest, it will quickly attract flags, and probably a lot of ornery comments too—and many more run silently beneath the surface. I think the proof is in the pudding: we don't see a lot of this. Anybody getting away with it regularly is probably being so devilishly clever as to deserve their ill-gotten gains.

Re: I Love Go; I Hate Go

#83

Post by majewsky »

greyskull wrote: post #30
andrewfromx wrote: post #11

Earlier quoted context omitted.

i was shocked by that at first too. Then I came to love it. It's sooooo go. Don't import stuff you aren't using. Don't declare a var and just leave it there un-used. When I go back to ruby and commit that crime, I see why golang did what it did. There's something magical about a golang program that will compile without error. It's worthy of checking in to git. And months later, there will be no unsed imports FOR SURE…

What about just really obnoxious compiler warnings that can't be disabled?

More than once I've built some free software from source, only to witness literally thousands of warnings being spit out during the compile phase.

Re: I Love Go; I Hate Go

#84

Post by sagichmal »

wruza wrote: post #35
andrewfromx wrote: post #11

Earlier quoted context omitted.

i was shocked by that at first too. Then I came to love it. It's sooooo go. Don't import stuff you aren't using. Don't declare a var and just leave it there un-used. When I go back to ruby and commit that crime, I see why golang did what it did. There's something magical about a golang program that will compile without error. It's worthy of checking in to git. And months later, there will be no unsed imports FOR SURE…

Stockholm syndrome in action. There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. If someone is not disciplined enough to throw out unused variables/imports/whatever from release, Go will not save him from hell.

    > There are two phases: active development and release 
    > engineering.
For you, perhaps. Go encourages you to think about your problem and develop it in the "release engineering" style from the very beginning. This is a virtue of the language, in my view.

Re: I Love Go; I Hate Go

#85

Post by millstone »

pjmlp wrote: post #79
millstone wrote: post #73

Earlier quoted context omitted.

These are just experiments on the margins. In each case, the flagship languages are not implemented on top of GC'd runtimes or interpreters. Apple's Objective-C and Swift runtimes are both C++. Microsoft's C# CoreCLR is C++. Google's V8 and Dart have runtimes written in C++. Oracle's HotSpot is C++. Go's core runtime is in a Go-minus-GC subset. It didn't have to be this way - Swift could have been written atop the JV…

The question was "What interpreters did these orgs write in GCed languages?". It doesn't matter where those interpreters are being used, the fact is that they exist. > Microsoft's C# CoreCLR is C++. Yes, but they have moved their compilers to C# with the Rosylin project with MDIL and .NET Native moving more code to C# side. Also check the Phoenix compiler framework, a LLVM like project from MSR using C#. > Go's core…

> Yes, but they have moved their compilers to C#

A compiler is a different matter. GCed languages are very compelling for static compilers. Even gcc uses GC internally.

The claim is that GCed languages make for poor interpreters - and also poor JIT compilers and runtimes.

> If you take Nashorn engine running on Jikes, it is an 100% Java stack running a JavaScript interpreter

Nashorn gets participation points, but it's not competitive with any of the major JS engines, all of which have C++ runtimes.

> Taking Swift as an example bootstraping the language would increase the burden designing it, as they are still far from fully stable design. If they would throw away in man years invested into the LLVM, which happens to be written in C++,

This still confuses the compiler with the runtime. The Swift compiler is indeed written in C++ using LLVM, but it could have easily been written in a GCed language without affecting much of anything.

But the runtime is separate, and it also happens to be written in C++. It's possible to imagine the Swift runtime written in a GCed language, but that is not what Apple chose to do.

Re: I Love Go; I Hate Go

#86

Post by masklinn »

nneonneo wrote: post #74
millstone wrote: post #55

Earlier quoted context omitted.

> How do you decrement an atomic in Go? Ooh. How do you delete from a slice in Go? With append() of course! http://stackoverflow.com/questions/25025409/delete-element-i...

That solution (append(a[:0], a[1:]...)) doesn't look remotely performant. I don't have a copy of go handy to test, but exploding most of the list into individual arguments and passing them to a variadic function, just to pack them all back into an array, seems quite circuitous to me. Is that really the _best_ way to delete from a slice in Go?

> Is that really the _best_ way to delete from a slice in Go?

Yep[0], and it needs a special case to remove the last element of the slice (if the index is user-provided). If you don't care about the slice order you can also swap the element you want to delete with the last element of the slice and shrink the slice by one element. Also fun, it can leak memory.

[0] https://github.com/golang/go/wiki/SliceTricks

Re: I Love Go; I Hate Go

#87

Post by laumars »

wruza wrote: post #35
andrewfromx wrote: post #11

Earlier quoted context omitted.

i was shocked by that at first too. Then I came to love it. It's sooooo go. Don't import stuff you aren't using. Don't declare a var and just leave it there un-used. When I go back to ruby and commit that crime, I see why golang did what it did. There's something magical about a golang program that will compile without error. It's worthy of checking in to git. And months later, there will be no unsed imports FOR SURE…

Stockholm syndrome in action. There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. If someone is not disciplined enough to throw out unused variables/imports/whatever from release, Go will not save him from hell.

> Stockholm syndrome in action.

That's a very negative way of saying "that's not my personal behavioral preference"

> There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter.

Many of Go's idiosyncrasies are for code readability and maintainability, which is very much a part of active development. The point being to mitigate the likelihood you end up with spaghetti code (yes, I know you ultimately end up with code quality only as good as the developer, but some languages do still make the process easier than others)

> If someone is not disciplined enough to throw out unused variables/imports/whatever from release, Go will not save him from hell.

Except it does though, since that's the very behaviour you're complaining about.

Re: I Love Go; I Hate Go

#88

Post by superswordfish »

dpc_pw wrote: post #49

Oh. Go love-hate relationship post. My turn. So I really like channels and coroutines built into language and used everywhere: it makes some patterns compose nicely and language very productive. But just as in the article - some of Golang choices are opinionated and IMO just stupid. Lack of assertions is one: Sure programmers are prone to ignoring errors, but Go is not helping at all. Just bans assertions and provide…

> ignoring years of research and good ideas

And people are falling over themselves to use Go in places that seem inappropriate. Most of Go's strengths shine in a large team of mediocre developers: Low build times, low abstraction, quick ramp-up, etc. So why do startups choose Go? You're just shooting yourself in the foot. Use OCaml, use C++, use Clojure, hell, use Swift or Rust, just use something that at least pretends to care about expressiveness and abstraction. I actively avoid working for shops that use Go heavily, it's an indicator of cargo-culting.

Re: I Love Go; I Hate Go

#89

Post by millstone »

patates wrote: post #70
millstone wrote: post #68

Earlier quoted context omitted.

Devil's advocate: if you can disable -Werror, then users will disable -Werror, and we'll end up in a C-like situation where everything warns all the time, and real problems get buried. Better to inflict some pain during development if it keeps the Go source corpus hygienic. One under-appreciated consequence is that this policy limits Go to one implementation. Say I write an alternative implementation of Go, that has…

> Devil's advocate: if you can disable -Werror, then users will disable -Werror, and we'll end up in a C-like situation where everything warns all the time, and real problems get buried. I already mentioned that case. To be more clear: Let it not build with default options. Make it not `go get`able. Let me develop first, and not force me to optimize prematurely.

Enforcing -Werror at the "go get" phase would achieve 90% of the benefit with 10% of the pain. It would be a big improvement.

Re: I Love Go; I Hate Go

#90

Post by barrkel »

andrewfromx wrote: post #11
_skel wrote: post #10

The most frustrating thing for me, by far, is that Go won't let you import unused packages. When you are commenting stuff out to debug a program, or adding debug statements and removing them later, it constantly requires you to go back to the top of the file and comment out the unused libraries, only to uncomment them later when you've solved your problem. The fact that there is not a compiler flag to disable this be…

i was shocked by that at first too. Then I came to love it. It's sooooo go. Don't import stuff you aren't using. Don't declare a var and just leave it there un-used. When I go back to ruby and commit that crime, I see why golang did what it did. There's something magical about a golang program that will compile without error. It's worthy of checking in to git. And months later, there will be no unsed imports FOR SURE…

Unused Ruby variables stand out like a sore thumb, if you have a linter configured with your editor. I use emacs with rubocop through flycheck.
Post reply on HN