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

221–230 of 329 posts

Re: I Love Go; I Hate Go

#221

Post by mmargerum »

kmiroslav wrote: post #157
_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…

It's a simple reflection of the fact that the Go creators have never used a modern IDE. Anyone using a modern IDE pretty much never even thinks about imports, which are (and should be) automatically managed by the tool, not by the programmer.

Assuming emacs doesn't qualify as a "modern" IDE. I have a hook that calls go imports to remove and add imports.

Re: I Love Go; I Hate Go

#222

Post by zaphar »

gnuvince wrote: post #192
zaphar wrote: post #166

Earlier quoted context omitted.

There are a lot of languages that warn you about such things. There are also a lot of projects in those languages that spit out a hundreds of warnings when they compile. Are those warnings bugs? Were they examined by someone to make sure they are acceptable? The older the project the less likely the above is true. Go eliminates an entire class of bugs with this feature. It doesn't just make them detectable and less l…

> On a side note why do we as developers tend to prioritize making the act of writing code easier than the far more frequent act of maintaining that code? Different phases of the development process call for different priorities: in early dev, you want reduced friction and quick turn-around time (something that the unsed imports and variables errors in Go infringe upon). Later on, you want maintainability and ensure…

    (By the way, why is it okay for a function to have 
     unused input parameters?)
That's caused by Go's interfaces and function type signatures. It may be necessary for a method or function to accept certain arguments to satisfy an interface or type signature even when those arguments don't get used. It's a bit of a wort I agree.

Re: I Love Go; I Hate Go

#223

Post by comex »

junke wrote: post #209
comex wrote: post #196

Earlier quoted context omitted.

Heh: my initial thought was that Go is nothing like Lisp - Lisp has the most powerful metaprogramming around thanks to its macro system, while Go doesn't even have C-level macros, or any of the type-system features some languages use as an alternative approach to metaprogramming. As a result Lisp is notoriously unopinionated, while Go is very opinionated. Lisp is functional, Go is aggressively imperative. And so on.…

> Lisp is functional Not really, multi-paradigm. > and at least Go has reflection. Go is introspective. Lisp has both introspection (e.g. find-class allows to look at existing classes) and intercession (e.g. ensure-class creates/modifies a class at runtime).

> Not really, multi-paradigm.

Yeah, that's probably a better way to describe it; it certainly ain't Haskell. But Go really doesn't want you even to use things like map and filter.

Re: I Love Go; I Hate Go

#224

Post by structorg »

tptacek wrote: post #29
_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 used to feel this way. It was my top complaint about the language. But it, and, more importantly, the use requirement for variables, has saved me from bugs repeatedly; I more and more notice the bugs it's protecting me from as I keep coding in the language. I am rapidly coming to the conclusion that this was very, very much the right call. I get the sense that most Go programmers use "goimports" to work around the…

Fortunately, I don't see this as a big issue in Go so far because I have used it for small components connected by zeromq or http. In a way, Go is also enforcing distributed/microservice style of development since a huge monolithical/business-rules program with it seems like nightmare material.

Re: I Love Go; I Hate Go

#225

Post by vertex-four »

themihai wrote: post #144
clessg wrote: post #108

Earlier quoted context omitted.

> the community is a bit smaller than Go's For now! Phoenix [0] will hopefully help turn the tide. I switched from Go to Elixir/Phoenix a year ago and I couldn't be happier. I've used a lot of web frameworks over my decade as an engineer, and Phoenix is the first one that has remained fun to use, fast (!), and productive. Crucially, its community has remained accepting and helpful under Jose's leadership - in contras…

what about the lack of static typing?

Elixir and Erlang both actually have static typing in the style of Facebook's Flow - type annotations can be added to your functions[0] and there's a tool, Dialyzer[1], which can be run via Mix[2] to type-check your programs.

It's not perfect - among other things, it can't type-check certain things that can and do happen in Erlang/Elixir programs, and won't complain about some errors - but it's better than being purely dynamic at not a whole lot more effort.

[0] http://elixir-lang.org/getting-started/typespecs-and-behavio... [1] http://erlang.org/doc/apps/dialyzer/dialyzer_chapter.html [2] https://github.com/jeremyjh/dialyxir

Re: I Love Go; I Hate Go

#226

Post by zaphar »

coldtea wrote: post #183
zaphar wrote: post #180

Earlier quoted context omitted.

And Google is actively replacing a lot of those with Go because using C++ for a web api is painful .

That's a myth. Google is not actively replacing anything with Go. Some new stuff is written in Go, and a few small parts here and there were rewritten in Go during a major refactor. There's no active program to rewrite things in Go, and most things are not meant to be written in Go from now on or anything -- it's just one of the supported languages.

Fair enough. I used poor wording there.

Re: I Love Go; I Hate Go

#227

Post by themihai »

hueving wrote: post #139
themihai wrote: post #126

Earlier quoted context omitted.

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?

> Goimports doesn't help when the name is ambiguous.

You can fork it and set it to only remove unused imports. In fact I've done just that few days ago but for different reasons(i.e. I generate some small programs and I use goimports as a quick and dirty way to to clean-up the unused imports). Here is the line where you need to return https://github.com/golang/tools/blob/master/imports/fix.go#L...

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

Yeah, I don't want being forced to use a dozen of flags just to compile a hello world program. Nor I do what to see various warnings that nobody really care about. It should fail or succeed. I prefer basic/minimal API that I can build upon not a kitchen sink approach. I think that's what makes Go a great ecosystem compared with many others. Compare the current Go compiler with various C++ compilers and you understand what I mean.

To sum it up you may use separate tools to do various magic things (i.e. goimports), they do not need to obey the Go1 compatibility rules. The issue is not that big to warrant a compiler flag.

Re: I Love Go; I Hate Go

#228

Post by tigershark »

Klathmon wrote: post #220
tigershark wrote: post #213

Earlier quoted context omitted.

How in the world forcing someone to put an underscore before the import name or adding a dummy variable to use the import (both should be removed after the debugging) helps to avoid bugs instead of making easier to introduce them?

Adding a dummy var won't work, because then the dummy var will trip the "no unused variables" check. Adding a _ to the front of an import is not the correct way to get around this "problem" during development, commenting out the whole import is the correct way. That way if you forget, it's not in your code anywhere (as it shouldn't be since it isn't used). The underscore system is meant only to be used when you need…

I have seen both suggestions in this thread: var _ = unusedImport

If you can't even agree among yourselves what is the right thing to do then I think that this is another sign that this go behaviour is not the proper solution.

Re: I Love Go; I Hate Go

#229

Post by fauigerzigerk »

_ak wrote: post #191
fauigerzigerk wrote: post #150

Earlier quoted context omitted.

I think these are goals, not guarantees, and the numbers are predicated on assumptions about extra free memory available to the GC. There is an inherent tradeoff between pauses, throughput and extra memory requirements.

Well, the latency is capped at 10 ms, the STW phases will stop at that limit. So that guarantee can be kept as long as your memory allocation throughput is low enough so as not to trigger a GC run more than 20 times a second. Which is pretty good. There aren't that many GC implementations in production that will give you a guarantee of the same or similar quality.

Can you point me to an authoritative source that explains what exactly is guaranteed under what assumptions and what is done on a best effort basis only?

Re: I Love Go; I Hate Go

#230

Post by bbatha »

masklinn wrote: post #86
nneonneo wrote: post #74

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?

> 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

That article is a concession speech on why generics are useful. Every single "trick" in the article is titled with the name of the equivalent method in more powerful languages. I don't think its possible to look at that list of tricks or the amount of boiler plate to get simple methods like `sort` or `keys` and assert the language is "simple" and better off for it.
Post reply on HN