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

301–310 of 329 posts

Re: I Love Go; I Hate Go

#301

Post by coldtea »

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…

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

The same could be said, and was said for Go compared to Java C#, etc just a few years ago. And it probably can still be said, as older languages have much more stable, richer ecosystems, support, tooling, and use bases.

>I must say it again: C++ is a horrible language. It may perform well and it may be widely spread but that doesn't change much as far as its design is concerned. C++ competes mostly on its reach not on its merits. Hopefully that will change as new platforms emerge(i.e Rust).

Well, it gets a lot of things right. Compatibility with C. Great performance. Enough abstractions to be usable. Enough batteries built-in compared to C. Great ecosystem and tooling, first class vendor support, etc. A language is not just its syntax -- not even just its semantics.

Re: I Love Go; I Hate Go

#302

Post by jerf »

Someone wrote: post #276
jerf wrote: post #181

Earlier quoted context omitted.

The use requirement for variables saves him from bugs, goimports fixes the problem with required use of packages. It's separate. The requirement that packages aren't used isn't to prevent bugs, it's to prevent packages from claiming spurious dependencies that you're then too afraid to remove. Or, in the case of a static language like Go, don't want to take the time to remove one-by-one and see if the compilation brea…

"It's separate" I don't think I misquoted the OP. He said "A and B help me with C" and I questioned how A could help with C, given the other claim that the OP doesn't pay any attention to A anymore. "Or, in the case of a static language like Go, don't want to take the time to remove one-by-one and see if the compilation breaks" That is a problem with perl, a language whose 'grammar' is about as free-form as it gets (…

"I don't think I misquoted the OP."

I don't think so either. What he wrote was unclear (sorry, tptacek). I was clarifying what I'm pretty sure he meant. It's not like I've never done the same thing in writing myself.

"Also, this requirement effectively rules out ever using go in a repl. I think that is a minus for modern programming languages."

It's ruled out for a lot of other more fundamental reasons. Go is probably the most highly polished language from the 1980s.

This would be a much greater condemnation, except the sort of people who tend to frequent HN (including me!) tend to grotesquely overestimate how much most programmers are spending coming up to speed on the latest and greatest. In many contexts, a "really nicely polished 1980s language" is a step up in either reliability or speed. Perl is nominally a more advanced language, but on the whole, most programmers just use it as a sort of dynamically-typed C. I think the majority of programmers still aren't all that clear on what a "map" is. Arming my fellow programmers with more capabilities doesn't solve any problem either I or they have, but can make them worse.

Also, I'd observe that even for modern programming languages, "needs a REPL" is setting the bar high. Rust will probably never have a REPL. I see a couple of defunct projects trying and I haven't studied them, but at best Rust could have an all-in-unsafe REPL dialect, because who's going to be able to reliably type borrow-safe code into the REPL on the first try?

Re: I Love Go; I Hate Go

#303

Post by tekknik »

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

This also infuriates me (more-so the "know-it-all" attitudes of the devs). What's even more infuriating is how simple of a change this is. It took me about 15 mins to change the compiler, adding compiler warnings and producing a warning instead of an error on unused imports and vars.

Re: I Love Go; I Hate Go

#304

Post by devishard »

scott_s wrote: post #198
devishard wrote: post #190

Earlier quoted context omitted.

> Sometimes I like to have a fully statically typechecked program. Wait, I thought we were talking about situations where Go was appropriate. What do you use when you want a fully statically typechecked program?

Please don't do this. You obviously disagree that Go is a language which provides full static typechecking. Please instead just state that disagreement, rather than feign confusion. It leads to much better discussions.

We would have a lot better discussions if people bothered to educate themselves about static typechecking before making claims about it on Hacker News.

Re: I Love Go; I Hate Go

#305

Post by devishard »

jsmith0295 wrote: post #292
devishard wrote: post #267

Earlier quoted context omitted.

Or literally any statically-typed language I know of after C. I suppose it's possible there's some language I'm unaware of that has managed to somehow provide less type-checking than Go, but it's certainly not a commonly-used one.

It's not really a matter of less or more in my opinion. Java has more type checking, but it doesn't give you much more safety than Go, and it's a lot more cumbersome. In general I find Go's type system to be better than Java's because of this.

I think that Java can definitely provide significantly more protection than Go, but I do agree that Java's horrible namespacing conventions and lack of type inference makes it cumbersome.

So what, you're on par with a 20 year old language? C# for example learned from Java's mistakes; why couldn't Go?

Re: I Love Go; I Hate Go

#306

Post by devishard »

jsmith0295 wrote: post #291
spion wrote: post #207

Earlier quoted context omitted.

But also ML, Scala, C++, C#, Java, TypeScript, Hack, Dart, Swift, Objective C (as of late), Visual Basic... and COBOL snobs.

I was referring more to the "joke" part of this. Just because a type system offers slightly more safety doesn't make it better. I'm primarily a Java developer, and I would prefer Go's type system over Java's the vast majority of the time. It does a much better job at staying out of the way.

I can definitely see the tradeoffs of choosing between Java's bad namespacing conventions and lack of type inference, but keep in mind you're comparing to a 20 year old language. Other languages (i.e. C#, Nim) have learned from Java's mistakes. Go hasn't; they've just gone back to making most of C's mistakes (in type systems).

I've no particular love for Java's type system, but I can't criticize it as much because it was a lot more reasonable when it was released (1996). In 2016 there's no excuse for having a type system as broken as Go's.

Re: I Love Go; I Hate Go

#307

Post by garfij »

dpc_pw wrote: post #288
themihai wrote: post #130

Earlier quoted context omitted.

Do you find using pub/extern keywords more elegant than a simple capitalization? To me rust is verbose in many cases like java with a lot keywords heading towards C++ complexity which is exactly what Go tries to avoid. I understand that now crago becomes somehow part of the language as the extern declarations will become "optional"/deprecated. So yeah, I hope Go won't adopt any of these fancy/XXI century features.

Let me see... instead of having to capitalize every single usage of a given symbol, I can just prefix it's defintion once with `pub`? Yeap, I rather do that. Instead of replacing all instances to lower case, I can just remove the `pub`. It's obviously better. Rust is noisy in other parts, for other reasons (trying to explain to compiler how to write super fast and data-race free code). But visibility qualifiers are n…

Just for contrast, when I'm exporting something in Go, using gorename makes it very easy to fix all the references within the package. It works the same when I'm un-exporting something as well. However, when un-exporting I have to go though all other packages that use that identifier and fix the code that used it. Presumably you need to do something similar when you remove the `pub` (i.e. It's not just a simple removing of the pub unless nothing used it to begin with).

Ultimately in the end, for this example it really seems like the same amount of work. You add one word, I run one command.

Re: I Love Go; I Hate Go

#308

Post by mcphage »

junke wrote: post #153
mcphage wrote: post #143

Earlier quoted context omitted.

> if someone cannot handle unused things, that someone is screwed. So what you're saying is, there are two kinds of people—those who don't need the feature, and those for whom the feature isn't sufficient?

User laumars was apparently misinterpreting part of a comment by saying that "unused" errors (not warnings, but errors) would in fact save the hypothetical "someone" that was claimed to be not disciplined enough to remove unused imports at release time. But the parent comment was in fact saying that the disability to handle something as simple as unused imports would prevent said programmer to accomplish the less tri…

> My personal view on this is that warning the user should be enough. The compiler designer is basically saying: I can't trust developers to fix warnings and it is my duty to protect them from their own laziness by enforcing a certain way of working. This apparently attracts a certain kind of people. I prefer to be the one telling the compiler what to do, instead of the reverse.

I'm with you there, I just was making a snarky comment :-)

Re: I Love Go; I Hate Go

#309

Post by garfij »

fauigerzigerk wrote: post #159

My favorite little annoyance with Go is the way the := operator behaves with multiple assignment. It declares a new variable if there is no variable of that name in the current scope. But it refuses to do that if there are struct fields involved. var t int t, err := someFunc() // that's fine but this doesn't compile: var s struct{ x int } s.x, err := someFunc() // doesn't compile

I've run into that as well, but I've since come to favor avoiding that pattern entirely as a code smell.

In your example, you end up modifying the struct value x, even if there was an error. Maybe there are cases where that is the correct behavior, but even then I would advocate for explicitly setting the struct value after handling the error, to make it very clear that it was your intention to do so, rather than doing it be accident.

Re: I Love Go; I Hate Go

#310

Post by scott_s »

devishard wrote: post #304
scott_s wrote: post #198

Earlier quoted context omitted.

Please don't do this. You obviously disagree that Go is a language which provides full static typechecking. Please instead just state that disagreement, rather than feign confusion. It leads to much better discussions.

We would have a lot better discussions if people bothered to educate themselves about static typechecking before making claims about it on Hacker News.

HN advocates the principle of charity - assuming the best possible intentions of the people you're talking to. In this case, that would mean assuming this person means something different when they use the phrase "fully statically typechecked", stating what you mean when you say it, and possibly linking to some source material to help further explain. It's quite possible they have the same understanding you do, they just are using the terms differently.
Post reply on HN