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

261–270 of 329 posts

Re: I Love Go; I Hate Go

#261

Post by pjmlp »

AnimalMuppet wrote: post #256
pjmlp wrote: post #170

Earlier quoted context omitted.

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

Define "feature". Go thinks fast compile time is a feature. How fast is your Algol 68 compiler on a ten million line code base?

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

Re: I Love Go; I Hate Go

#262

Post by junke »

dmoy wrote: post #247
junke wrote: post #62

Earlier quoted context omitted.

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…

My reaction to "differing use cases lend to different tools" was that tools and especially languages often accommodate multiple, sometimes contradictory use cases.

I am not writing code that thousands of other engineers are going to depend on. A company that requires this can enforce methodological rules. Go is supposed to be used in different contexts, not just Google, right?

Re: I Love Go; I Hate Go

#263

Post by junke »

AnimalMuppet wrote: post #253
junke wrote: post #62

Earlier quoted context omitted.

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?

> > Differing use cases lend cause to different tooling. > What? Different needs, different languages. I write 100-line scripts in Perl that rip apart text files and extract the bits I want. I don't write 100,000 line embedded systems in Perl.

What about different needs among the users of a same language?

Re: I Love Go; I Hate Go

#265

Post by devishard »

_ph_ wrote: post #238
devishard wrote: post #189

Earlier quoted context omitted.

This post is yet another reinforcement of my assertion that the people who like Go only like it because they have no idea what has happened in programming languages for the last few decades. Case in point: > It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. Strict type checking? Have you used any other languages besides C ? Go'…

Sorry, your posting is unnecessarily abrasive. I am well aware about more advanced type systems. I have never claimed that Go has the most advanced type system. But indeed, compared to C/C++ which still are the most commonly used languages in industry, it has a strict type system. It could possibly have a more advanced one, but strict it is. And it gets work done.

> Sorry, your posting is unnecessarily abrasive.

Go is a much bigger problem in our industry than the tone of my post.

> I have never claimed that Go has the most advanced type system.

You claimed it had "strict type checking", when it has the least strict type system of any statically-typed language in common usage except C.

> But indeed, compared to C/C++ which still are the most commonly used languages in industry, it has a strict type system.

With template types, you can definitely get more strict type-checking out of C++ than out of Go.

So basically, Go has a more modern type system than C. And that's arguably not true. None of which disproves what I said: I said, "people who like Go only like it because they have no idea what has happened in programming languages for the last few decades."

> And it gets work done.

You can make that claim about any language. The question is, does it get work done as efficiently as other languages? And the answer is pretty clearly no.

Re: I Love Go; I Hate Go

#267

Post by devishard »

jsmith0295 wrote: post #194
devishard wrote: post #189

Earlier quoted context omitted.

This post is yet another reinforcement of my assertion that the people who like Go only like it because they have no idea what has happened in programming languages for the last few decades. Case in point: > It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. Strict type checking? Have you used any other languages besides C ? Go'…

Maybe if by "people who know about types languages" you mean "Haskell snobs"

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.

Re: I Love Go; I Hate Go

#268

Post by ahl »

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 author (me) isn't a Rust expert, but has played with it a bit. Rust, I think, suffers from a lack of empathy with a novice audience. I'm a big fan of Rust and I think it introduces some novel, valuable, and fascinating new concepts. It should be taught in every CS program alongside procedural, OOP, and functional programming.

Once you understand the paradigms, Rust error messages make sense. It's like the folks who describe git by starting with a exposition on merkel trees: technically precise, but incomprehensible if you only know cvs.

Re: I Love Go; I Hate Go

#269

Post by hehheh »

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.

If a library is so popular that "everyone" uses the flag so they can use it, surely someone can be convinced to remove the unused import statement. If the ecosystem makes that difficult then we're talking about a totally different problem.

Re: I Love Go; I Hate Go

#270

Post by devishard »

AnimalMuppet wrote: post #256
pjmlp wrote: post #170

Earlier quoted context omitted.

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

Define "feature". Go thinks fast compile time is a feature. How fast is your Algol 68 compiler on a ten million line code base?

1. How many people have 10 million line code bases?

2. How many of those people would have much smaller codebases if they used a more expressive language?

3. Of the people who have 10 million line codebases and would still have 10 million line codebases in a more expressive language, how many of those could actually compile their programs faster if they used a language that allowed partial compilation of only the parts of the code that were changed?

Very few people have Google's problems, and I'm not even completely convinced that Go is the best way to solve Google's problems.

Post reply on HN