Live data from Hacker News

I Love Go; I Hate Go

dtrace.org

131–140 of 329 posts

Re: I Love Go; I Hate Go

#131
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 prete…

I think it really depends on what kind of software you're writing. At my startup (around 30 engineers) most of what we do is web based, and our backends are mostly written with Java and Spring Boot now. Go is simpler, more productive, has better concurrency, and still has good static analysis. The benefits mostly seem to come from the removal of bullshit rather than the addition of nice abstractions.

Re: I Love Go; I Hate Go

#132
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 prete…

I run a few side projects with a pool of about a dozen developers. Some love Java but others won't touch it, some are C developers, one of them only has experience with PHP, there are lispers, an Erlang zealot and even a Delphi refugee. I personally like Perl and OCaml but couldn't convince them to even consider them. It was a nightmare to agree and settle up with something.

Enter Go, and while we all agreed that the language kind of sucks and $FAV_LANG is better, we somehow stopped bike-shedding and started to get real work done.

Sure, it's not the most exciting language in the block and its community seems to live in the 70s, but sometimes targeting the lowest common denominator can pay off, as is the case for us.

Re: I Love Go; I Hate Go

#133
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…

Meh, I just have emacs configured to run goimports on save, right along with gofmt. I never even worry about, unless I have to resolve which of two packages with the same final name component I'm using.

That can be a bit annoying, but it's not terrible. Back when Go had insanely great compile times, it was worth it. Now that compile times are … okay … it's — okay.

Re: I Love Go; I Hate Go

#134
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 prete…

You don't know what you are talking about. Have you seen any Swift backend used in production? Would you use C++ for a web API? Go was developed because C++ is a horibble language and I'm glad it didn't adopt the expressiveness and abstraction from C++.

Re: I Love Go; I Hate Go

#135

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?

It's because it's the wrong data-structure for the job. A slice is not sparse.

If you need to delete from the middle of an ordered collection of items then it's better to use a linked or doubly-linked list (unless it's small then it doesn't matter).

Re: I Love Go; I Hate Go

#136
post #43
post #34

Earlier quoted context omitted.

>It's very clear to me when to write Go and when not to. Would you care to elaborate on this? :)

My main two use cases so far have been services and command line tools where it's not worth taking the effort to manage memory. The former I would have previously written in Java or C# (yeah, tie me to the cross right now language hipsters, I don't care, I already said I'm a pragmatist), and the latter in Ruby or Python. I actually enjoyed going from dynamic to static typing for command line tools, the compiler saves…

[deleted]

Re: I Love Go; I Hate Go

#137

Earlier quoted context omitted.

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

You don't know what you are talking about. Have you seen any Swift backend used in production? Would you use C++ for a web API? Go was developed because C++ is a horibble language and I'm glad it didn't adopt the expressiveness and abstraction from C++.

It really depends on the project. I'd prefer Clojure or Erlang for most frontends, a Lisp for the backend of an expert system, and C++ or OCaml for any heavy lifting. Python still can be a great choice for all sorts of systems too. Swift and Rust aren't quite there yet but for a startup might be worth a look in time. We're not talking about "nobody ever got fired for choosing IBM" business here and being risk-averse is itself risky.

Re: I Love Go; I Hate Go

#138
post #124
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…

For your unit-testing problem, I highly recommend `testify/assert`: https://godoc.org/github.com/stretchr/testify/assert

The fact that golang ships with a unit test library that does not contain equality assertions is aggravating. Their political stance on it is just one of many places the language designers come off less as opinionated and more as that they know my problem sets better than me.

Re: I Love Go; I Hate Go

#139
post #100

Earlier quoted context omitted.

(I've never used Go, so please correct any errors.) > var _ = unusedImport This is what the devs suggest as an alternative to having a compiler flag to turn off the check. But with a compiler flag, I can easily discover the unused import when I build for production, simply by turning that flag off. By using the variable in a dummy way, I need to remember to go back and check for such things. Presenting this as a way…

In practice you don't really have this problem. It's a beginners issue thst's not worth "fixing" because there are tools that can help(goimports). I'm glad there are not such compiler flags.

Goimports doesn't help when the name is ambiguous.

>I'm glad there are not such compiler flags.

Because if they were there people would force you to use them? Or are you just unhappy that people could have a different debugging workflow than you?

Re: I Love Go; I Hate Go

#140
post #128

Earlier quoted context omitted.

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?

A slice is a view over a continguous array. deleting an index in a continguous array is inherently O(n). Go doesn't obscure this. The pain of writing it out reflects the complexity of the operation.

[deleted]
Post reply on HN