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

241–250 of 329 posts

Re: I Love Go; I Hate Go

#241

Post by unscaled »

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…

I'm using goimports too, and it works like magic 95% of the time, while I can manually take care of the rest.

But it only solves the unused imports issue. During development (especially when playing with code) I often need to temporarily comment out a section of code. I go build, and the situation usually unfolds like this: - ERROR! Yes, now, I have an unused variable dangling around, because this code was using it. - No problem, let's go on and comment out that variable as well. - Oh noes! That variable was defined using two other variables which are now unused! - The first one comes from a function result, but I still want to call that function, so I need to actually change (not comment out) the calling line to use an underscore. - The second is a global variable which using another variable? Where is it going to end?

At this point I end up following the FAQ's advice and just add the line "_ = unusedVariable". The only problem I have with that is that wasn't all this unused variables thing meant to keep us from shipping code with useless bits we don't need in production? Now I actually might end up not using this variable, but because I've ended up adding "_ = unusedVariable" during my debugging and left that on, I have no way of knowing that.

Re: I Love Go; I Hate Go

#242

Post by themihai »

philh wrote: post #239
themihai wrote: post #227

Earlier quoted context omitted.

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

> You can fork it and set it to RemoveOnly. This seems like it removes half the value of the tool, though. I can comment out a line of code, compile and test the program. But if I uncomment that line, I'm now missing an import. edit- how does a tool like this sound? * If it sees an unused import, it comments it out * If it sees an import is needed, and there's a commented-out import which would fit, it uncomments it.…

Well, that's the point! If you don't want inaccurate imports and just want to remove unused imports you can comment that line. A better option would be to use an additional argument to that function (removeOnly bool) and perhaps a flag on the executable so that you can choose when to use the removeOnly option. Either way the automatic imports and even the removeOnly option alone requires various trade-offs(i.e. accuracy, compiler speed etc) and this is another reason why such features are better developed in stand alone/external tools.

Re: I Love Go; I Hate Go

#243

Post by unscaled »

themihai wrote: post #235
coldtea wrote: post #182

Earlier quoted context omitted.

> You don't know what you are talking about. Have you seen any Swift backend used in production? He said "hell, use Swift" -- which didn't imply that he's considering it the first or best recourse. That said: 1) There's far more Swift in production (on iOS devices as native apps, not as backend, but still production code) than Go. 2) Merely 4-5 years ago nobody had seen Go in backend (web/server) production either. O…

>He said "hell, use Swift" -- which didn't imply that he's considering it the first or best recourse. I've got that but it was too late... the comment was already posted. I've up-voted his response. The rest of your points are invalid. Development is not only about a http server(which I'm sure is subpar compared with Go). You will burry your time and energy in making basic things work. As developer that's great becau…

C++ is horrible in many ways, but Go never really tried hard to replace it (although it claimed to do that in the beginning, before it was refocused as a language for backend and tools).

The are many reasons for that, but most importantly, Go doesn't support deterministic memory management (like C++, Rust and Swift) and opts for GC instead, which makes life easier for at least 95% of its use cases, but not for some of the use cases C++ used to shine on.

I think that the Plan 9 Googlers dislike of C++ (and in truth, Modern C and UNIX as well) is closer to be the real reason for creating Go. It really was never designed to be a proper system language.

Re: I Love Go; I Hate Go

#244

Post by rogerdpack »

zaphar wrote: post #166
gnuvince wrote: post #162

Earlier quoted context omitted.

Rust warns you about those things; allows for quicker iteration in development, and gives you a list of things to address when you are ready to polish.

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…

I thought it ironic that go also has a "go vet" which spits out "warnings" but...are those warnings bugs? Were they examined? etc. etc. :|

Re: I Love Go; I Hate Go

#245

Post by Ygg2 »

masklinn wrote: post #105
valarauca1 wrote: post #98

Earlier quoted context omitted.

This was where I stopped reading. The author clearly hasn't worked with Rust. Not only are the messages very descriptive, but you have an extended explaination for each error in the form of: rustc --explain EXXX Which pulls up a long form explaination, and code samples of what is happening/why it is happening/how to fix it. The blog explaining the author's disdain for Rust mostly just seems to whining about the borro…

> The author clearly hasn't worked with Rust. The author links to a previous post on the subject, from mid-2015, so they clearly have at least tried Rust in the past. And while many Rust messages are OK, one should be careful not to confuse familiarity with Rust's error messages[0] with Rust's error messages being good (being inherently informative and good). Here's a clearer example (fixed since): http://dbeck.githu…

> By comparison Elm makes much more extensive use of spacing and tries to avoid repeating the same information (e.g. file names) over and over.

Yeah, but you need that kind of repetition to get text editor jumping to correct line number.

AFAIK, Rust already implements concise messages on nightly.

Re: I Love Go; I Hate Go

#246

Post by unscaled »

_ph_ wrote: post #171
junke wrote: post #163

Earlier quoted context omitted.

I am really curious about the kind of tasks that are easily done in Go but for which Lisp doesn't quite fit.

Sometimes I like to have a fully statically typechecked program. You can do that in Lisp, its easier in Go. Also, it directly produces statically linked executables. You can do a lot of this in SBCL, it also produces executables, has type checking etc. But for some of this, you have to wrestle a bit with the Lisp system. The Common Lisp numeric tower is great - until you want to write low level programs where you jus…

If you're looking for a FULLY statically typechecked program, you can easily do better than Go. Heck, even using Typescript or Javascript with Flow would give stronger typing than Go with its ubiquitous "interface{}".

Static executables by default is something that Go is famously good at, but I'm pretty sure Haskell can do this as well without so much pain and with a type system many times stronger than Go's.

Re: I Love Go; I Hate Go

#247

Post by dmoy »

junke wrote: post #62
dmoy wrote: post #15

Earlier quoted context omitted.

I think it depends on what you're using it for. On my day-to-day I'm working with absolutely massive pieces of software that have dependency trees that would literally make me cry if I stopped and thought about it too hard. In that world, this sort of thing enforced strongly makes me much happier. For random one-off hacking, yea, it'd be a pain. Differing use cases lend cause to different tooling.

People are ok with compilers telling them what is wrong, they complain that Go wants to control when you fix the problem: "fix that import NOW, bad developer" is not opinionated, it is stupid. > Differing use cases lend cause to different tooling. What?

By differing use cases:

If you're messing around with your own test code, it's fine if your compiles get slower, etc. On the other hand, if you're writing code that thousands of other engineers are immediately going to depend on, it's better if you're not allowed at all to make things slower via unused imports. True, if you could globally mandate the use of a lint/presubmit rule disallowing unused imports, that would also work. But, that's a harder swing.

Re: I Love Go; I Hate Go

#248

Post by im_down_w_otp »

vertex-four wrote: post #225
themihai wrote: post #144

Earlier quoted context omitted.

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

With the recent addition of better semantics for Map type specs combined with the dialyzer flags Wunderspecs, Woverspecs, and Wspecdiffs there's nothing I've found that Dialyzer misses that I'd expect a type-checker to be able to find and warn me about.

Re: I Love Go; I Hate Go

#249

Post by laumars »

ckastner wrote: post #97
laumars wrote: post #87

Earlier quoted context omitted.

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

>> Stockholm syndrome in action. >That's a very negative way of saying "that's not my personal behavioral preference" In my experience, Stockholm syndrome is not used to describe personal behavioral preferences, but rather (unexpected) transitions between such preferences from the negative to the positive. In the grandparent's own words: >>> i was shocked by that at first too. Then I came to love it.

It's possible that's what he meant, but that's not how I understand the term.

Stockholm syndrome refers is a victim forming emotional bonding with his or her captor[1]. Which would mean in instances like this, where the "captor" is a voluntary choice of language, the term is used akin to "masochism" (albeit without the sexual element). In essence, saying "the pleasure from use feature x is derived from the pain of using feature x".

Which is why I commented that "Stockholm syndrome" is a needlessly colourful way if saying "I disagree".

[1] https://en.wikipedia.org/wiki/Stockholm_syndrome

Re: I Love Go; I Hate Go

#250

Post by junke »

laumars wrote: post #249
ckastner wrote: post #97

Earlier quoted context omitted.

>> Stockholm syndrome in action. >That's a very negative way of saying "that's not my personal behavioral preference" In my experience, Stockholm syndrome is not used to describe personal behavioral preferences, but rather (unexpected) transitions between such preferences from the negative to the positive. In the grandparent's own words: >>> i was shocked by that at first too. Then I came to love it.

It's possible that's what he meant, but that's not how I understand the term. Stockholm syndrome refers is a victim forming emotional bonding with his or her captor[1]. Which would mean in instances like this, where the "captor" is a voluntary choice of language, the term is used akin to "masochism" (albeit without the sexual element). In essence, saying "the pleasure from use feature x is derived from the pain of us…

The "masochism" aspect makes Go part of Bondage and Discipline languages:

http://c2.com/cgi/wiki?BondageAndDisciplineLanguage

Post reply on HN