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

281–290 of 329 posts

Re: I Love Go; I Hate Go

#281

Post by zzzcpan »

tptacek wrote: post #280
junke wrote: post #260

Earlier quoted context omitted.

That's why unused variables should be reported. What people are arguing about is errors vs. warnings. > things that can really cause bugs "can" means that they don't always cause bugs: other compilers treat such uncertainties as warnings because the human looking at the screen is the one who is in charge. Go allows you to compile code which does not respect "go fmt", why? aren't you afraid of committing working code…

As someone else pointed across the thread, the error eliminates these bugs, not only in your code but, effectively, in all the libraries you import. It takes effort to retain those bugs. That has significant value, and is why I've conclude Go's choice here was the right one, despite the annoyances it causes. I like gofmt, but I don't really care whether the compiler enforces it. It's unlikely to catch bugs.

Actually, that's a huge speculation. Breaking someone's train of thought with an error that needs fixing right that second could just as well cause some bugs.

Re: I Love Go; I Hate Go

#282

Post by pjmlp »

AnimalMuppet wrote: post #278
pjmlp wrote: post #261

Earlier quoted context omitted.

Fast enough for a 60's computer, imagine nowadays. But if you want numbers, Turbo Pascal 5.5 was doing 34,000 lines/minute[1] on MS-DOS back in 1989. [1] http://edn.embarcadero.com/article/20803

Turbo Pascal isn't Algol 68. A PC in 1989 isn't a B5000. But even accepting the example, 34,000 lines/minute gets you a compile that takes 294 minutes, or just under 5 hours. That's... not very good. Of course faster hardware is part of the answer, but I suspect that it doesn't cover nearly all the ground between Turbo Pascal's compile time and Go's.

I gave Turbo Pascal as an example, because even when compared against it, there are many features that Go lacks and Turbo Pascal had.

Besides I am comparing an 8086 with 640 KB against a i7 with 16 GB and three level caches.

Go being fast isn't that much of an achievement in 2016.

If Go compiles faster than Turbo Pascal with an 8086 CPU and 640 KB RAM, that is an achievement.

Re: I Love Go; I Hate Go

#283

Post by nomel »

junke wrote: post #71
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…

Define unused imports/variables as warnings but produce an executable that first prints "This program is for debugging purposes only, it built with 133 warnings." and beeps loudly.

Nothing like a little public shaming to keep your code in check.

Re: I Love Go; I Hate Go

#284

Post by fishnchips »

kmiroslav wrote: post #236
fishnchips wrote: post #176

Earlier quoted context omitted.

This statement is probably true but that's kind of irrelevant. IMO it is actually a virtue of the language if it is perfectly usable without a modern IDE. Contrast that with Java and you'll see what I mean. Go follows the Unix philosophy where things like imports or formatting can be supplied by any external tool. If you wish to bundle all these small tools into a single IDE you can do it, too.

Everything is perfectly usable without an IDE, you are just more productive with one than without one. Regardless of the language. In this particular case, the IDE could automatically remove the imports when you remove the corresponding symbol from your source, or automatically add the import when you introduce a new symbol. The "can be supplied by any external tool" is a cop out that was acceptable in the 20th centu…

Nothing about the language or its tooling prevents you from building such an IDE or a plugin to one of the existing IDEs. And there is absolutely nothing in Java that makes IntelliJ so awesome. These things are totally orthogonal. What I like about Go's tooling is that it allows good plugins for various text editors (eg. Sublime or Atom) to be implemented with relatively little effort.

Re: I Love Go; I Hate Go

#285

Post by Ygg2 »

masklinn wrote: post #259
Ygg2 wrote: post #245

Earlier quoted context omitted.

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

> Yeah, but you need that kind of repetition to get text editor jumping to correct line number. Not really, what you need is a regular and parseable structure.

Depends. There was a long discussion what new format would be. I am pretty sure text editor compatibility demanded filenane:row:col format, and it repeated for each displayed line.

Though to be fair I am not huge fan of Elm's one error per build either.

Re: I Love Go; I Hate Go

#286

Post by AnimalMuppet »

pjmlp wrote: post #282
AnimalMuppet wrote: post #278

Earlier quoted context omitted.

Turbo Pascal isn't Algol 68. A PC in 1989 isn't a B5000. But even accepting the example, 34,000 lines/minute gets you a compile that takes 294 minutes, or just under 5 hours. That's... not very good. Of course faster hardware is part of the answer, but I suspect that it doesn't cover nearly all the ground between Turbo Pascal's compile time and Go's.

I gave Turbo Pascal as an example, because even when compared against it, there are many features that Go lacks and Turbo Pascal had. Besides I am comparing an 8086 with 640 KB against a i7 with 16 GB and three level caches. Go being fast isn't that much of an achievement in 2016. If Go compiles faster than Turbo Pascal with an 8086 CPU and 640 KB RAM, that is an achievement.

I am going to guess that Go compiles at least 10 times faster than Turbo Pascal. From the numbers you gave, I think at least a factor of ten is left even after you account for the difference in hardware speeds.

Re: I Love Go; I Hate Go

#288

Post by dpc_pw »

themihai wrote: post #130
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…

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 not a problem.

`extern` is only for importing crates, which is like 10 lines at in whole package/crate. Irrelevant.

Re: I Love Go; I Hate Go

#289

Post by wruza »

zaphar wrote: post #233
hehheh wrote: post #185

Earlier quoted context omitted.

This is an easy problem to solve. The Go compiler could simply include a bit in the resulting binary/library that indicates whether or not it was built with the "disable-unused-variable-error" flag. If you're using a library that was built with that flag the compiler can simply refuse to compile your code without that flag, forcing you to acknowledge the problem head-on.

This doesn't solve the problem. It just makes you aware it might be there. It doesn't keep the ecosystem clean. The result will be that everyone compiles with that flag on so they can use the libraries they want/need. It's in fact actively worse than just allowing warnings. At least if you allow warnings that way you aren't forced to lower your own codes protection just because one of your dependencies does.

Complaining about unused import doesn't solve anything IRL, if we talking about solving something. Problems in code are complex diseases, and cleaning unused entities is like washing your hands, not like taking a cure. And hand cleanliness checks is too idiotic measure to cure brain cancer. Of course all our problems are still here in both cases, but at least with Go we will die clean for sure.

Re: I Love Go; I Hate Go

#290

Post by twic »

millstone wrote: post #68
patates wrote: post #52

Earlier quoted context omitted.

Why on earth would the language hinder you from iterating fast with a flag, and then convert all the warnings to errors when you run the full tests? For example, most JS linters do that check and as a general rule, the build servers would reject the commit when the linter complains. I actually have a (very hacky) plugin to ESLint that automatically removes unused variables before `hg push`. It's totally not optimal,…

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…

You set things up so you can't disable -Werror on the build server, and all this is moot.

The point about alternative implementations is interesting. Java has a comparable situation with unreachable code; the language specification has a simplistic definition of what unreachable code is, and makes it a compile-time error. A smart compiler can find more cases of unreachable code, but isn't allowed to make them errors. So it makes them warnings. It doesn't seem to be a big impediment to alternative implementations in practice.

Post reply on HN