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

161–170 of 329 posts

Re: I Love Go; I Hate Go

#161

Post by EugeneOZ »

masklinn wrote: post #146
EugeneOZ wrote: post #141

Earlier quoted context omitted.

So you are trying to add some negative moment about borrow-checker, when my comment is not about borrow-checker, but you need something negative. Cheap trick.

> So you are trying to add some negative moment about borrow-checker, when my comment is not about borrow-checker, but you need something negative. Cheap trick. Now what the hell are you talking about? I didn't reply to your comment I replied to valarauca1, they're the one who mentioned the borrow checker, if you're unhappy about that whine to them don't include me in your pity party.

Are you drunk? You are responding to the branch my comment started, comment was about error messages and your response contain words:

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

So you will still try to pretend we are not talking about error messages here?

Re: I Love Go; I Hate Go

#162

Post by gnuvince »

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…

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.

Re: I Love Go; I Hate Go

#163

Post by junke »

_ph_ wrote: post #160

I like Go quite a lot. Mainly I am a Lisp programmer, so I am not looking for the next most high level programming language. I am looking for a language which gets things done, where Lisp doesn't quite fit. For jobs, which traditionally would have been done in C. Programs that run fast and have a reasonable complexity. It brings back the virtues of the Wirth computer language family back into modern times, as with st…

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

Re: I Love Go; I Hate Go

#164

Post by pjmlp »

_ph_ wrote: post #160

I like Go quite a lot. Mainly I am a Lisp programmer, so I am not looking for the next most high level programming language. I am looking for a language which gets things done, where Lisp doesn't quite fit. For jobs, which traditionally would have been done in C. Programs that run fast and have a reasonable complexity. It brings back the virtues of the Wirth computer language family back into modern times, as with st…

> It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. On top of that it adds memory safetey due to the presence of GC.

Wirth's work also includes languages with GC. :)

Re: I Love Go; I Hate Go

#165

Post by gnuvince »

valarauca1 wrote: post #98
EugeneOZ wrote: post #96

> Contrast this with Rust whose errors read like mind-bindingly inscrutable tax forms. It was "lol what?" for me. Rust's compiler error messages are very informative and sometimes contains tips what to change in your code to make it work (not just general words, but code you can use right now, with your variables/functions etc.). Borrow checker explains step-by-step where ownership starts, where it ends and where you…

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 blog explaining the author's disdain for Rust mostly just seems to whining about the borrow checker.

Most (negative) discussions about Rust are about the borrow checker. I sometimes wonder if people dislike it because it makes them feel the same way they felt the first time they learned to program and the compiler would never accept their code.

Re: I Love Go; I Hate Go

#166

Post by zaphar »

gnuvince wrote: post #162
tptacek wrote: post #29

Earlier quoted context omitted.

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…

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 likely. It eliminates them. If you don't care about eliminating them then Go's philosophy isn't for you.

But I for one am sold on that philosophy. I'm disciplined enough that in my rust code I ensure all warnings are fixed before I release. But I don't know if everyone else is just as disciplined. For Go code I do. Every library I use in Go has an entire class of bugs that are impossible. That's a useful guarantee in my book.

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? Optimizing writing you code over reading and maintaining that code long term seems like a case of premature optimization to me. Allowing something like warnings is one of those things that adds overhead to writing code but eliminates overhead over the life of maintaining that code. The gains are higher longer term at the expense of a shorter term pain. And a pain that tooling like goimports can almost completely eliminate in almost all cases.

Re: I Love Go; I Hate Go

#167

Post by coldtea »

pjmlp wrote: post #164
_ph_ wrote: post #160

I like Go quite a lot. Mainly I am a Lisp programmer, so I am not looking for the next most high level programming language. I am looking for a language which gets things done, where Lisp doesn't quite fit. For jobs, which traditionally would have been done in C. Programs that run fast and have a reasonable complexity. It brings back the virtues of the Wirth computer language family back into modern times, as with st…

> It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. On top of that it adds memory safetey due to the presence of GC. Wirth's work also includes languages with GC. :)

And more modern features than Go, even if designed in the 90s...

Re: I Love Go; I Hate Go

#168

Post by patates »

laumars wrote: post #158
patates wrote: post #70

Earlier quoted context omitted.

> 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. I already mentioned that case. To be more clear: Let it not build with default options. Make it not `go get`able. Let me develop first, and not force me to optimize prematurely.

> Let me develop first, and not force me to optimize prematurely. I'd argue that cleaning unused code as you work isn't optimisation. It's a part of the refactoring process of development which is something that must happen during the main development phase. But arguments for and against aside, most developers don't see these kinds of compiler errors that often as you'd generally be commenting out unwanted code while…

> It's a part of the refactoring process of development which is something that must happen during the main development phase

How is it refactoring if my code never builds in the first place?

> pragmatically that still takes up such an insignificant amount of effort when compared with the overall time spent writing code in any particular language. Which is why many Go advocates are willing to put up with it.

It's not a time problem. It's a focus problem. I'm working on something and then out of nowhere, receive compilation errors, which aren't urgent at all, but they distract me anyway. Even if this were indeed a very small problem, I still don't see why something most people see as a problem is pushed down the developers throat with false, dogmatic reasoning. Don't get me wrong: I have huge respect to the people who created go. I just don't like when people defend all the choices they made as "one true way".

Re: I Love Go; I Hate Go

#169

Post by coldtea »

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…

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

Isn't it implied that programmers are adults?

Re: I Love Go; I Hate Go

#170

Post by pjmlp »

TurboHaskal wrote: post #132
superswordfish wrote: post #88

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…

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…

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

Except that even Algol 68 is more feature rich than Go, assuming a 60's powerful computer, like the Burroughs B5000. :)

But I do appreciate that every line of written Go code is one less of written C code.

Post reply on HN