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

311–320 of 329 posts

Re: I Love Go; I Hate Go

#311

Post by Someone »

jerf wrote: post #302
Someone wrote: post #276

Earlier quoted context omitted.

"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 probabl…

Rust and C++ came to mind when I wrote that. That's why I didn't write modern languages _must_, but only called it a minus if they didn't.

And thanks for the relativism in that remark about the most highly polished language from the 1980s. I fear you are right in that (example: today, a colleague said this was the first time he created a thread. He has had a job as a developer for a few years, and, given his age, likely never wrote for a CPU that isn't multi-core. Luckily, he isn't dumb, as he asked what would happen if that thread threw an exception)

Re: I Love Go; I Hate Go

#312

Post by steveklabnik »

ahl wrote: post #268
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 (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 w…

  > Rust, I think, suffers from a lack of empathy with a novice audience.
I'd be interested in hearing more about this. Do you mean a novice to Rust, a novice to low-level programming, a novice to programming in general?

We're actively working on fixing up errors to be even better, so hearing about specifics here would be quite valuable!

Re: I Love Go; I Hate Go

#313

Post by kmiroslav »

fishnchips wrote: post #300
kmiroslav wrote: post #296

Earlier quoted context omitted.

> 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. No, they're not. There are a few necessary conditions for this kind of symbiosis to work well: - The language has to be statically typed. Without type information, the IDE is completely b…

> The language has to be statically typed Go is statically typed. > the simple action of selecting the the surrounding expression simply doesn't exist anywhere How so? It's trivial with the `go/ast` package.

Does any Go editor support that?

Re: I Love Go; I Hate Go

#314

Post by jsmith0295 »

devishard wrote: post #305
jsmith0295 wrote: post #292

Earlier quoted context omitted.

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?

I think I just don't come across situations where I find myself needing generics in the software that I typically write. I can imagine it would suck in those situations. There is a workaround for it, though. Basically you write a template and do code generation off of that to sort of approximate generics. I've never done it myself, though.

Re: I Love Go; I Hate Go

#315

Post by junke »

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.

And so the compiler, who has no way to make informed decisions, is there to tell you which stylistic issues is more likely to introduce bugs or not, while being needlessly stubborn.

A sufficiently bureaucratic compiler.

Re: I Love Go; I Hate Go

#316

Post by devishard »

scott_s wrote: post #310
devishard wrote: post #304

Earlier quoted context omitted.

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…

Okay, why don't you assume in everything I'm talking about fluffy rainbow butterflies or something nice like that? Principle of charity, right? That way we can both go our separate ways happily.

If someone doesn't mean "fully statically typechecked" then they shouldn't say "fully statically typechecked". It's not an ambiguous phrase.

Re: I Love Go; I Hate Go

#317

Post by pcwalton »

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…

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

The amount of development time I save by allowing warnings temporarily when testing easily outweighs any benefit to the ecosystem derived from making that warning abort compilation. I was partially responsible for making this a warning instead of a hard error in Rust and this wasn't even close to a tough call. I would be surprised if a single project in the ecosystem has ever benefited from this: projects that care about software quality pay attention to warnings, and those that don't care about this minimum standard of quality are going to be full of so many other bugs that the unused variable/import warning will make no difference.

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

Go's philosophy is not about eliminating bugs above all else. If it were, then for example zero values wouldn't exist, reading from a nil map would panic, constants would have stronger types, all fields would have to be supplied when initializing structs, init ordering wouldn't be undefined, overflow would trap, errors would be required to be handled, and that's just off the top of my head.

Re: I Love Go; I Hate Go

#318

Post by [deleted] »

zaphar wrote: post #222
gnuvince wrote: post #192

Earlier quoted context omitted.

> 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? Different phases of the development process call for different priorities: in early dev, you want reduced friction and quick turn-around time (something that the unsed imports and variables errors in Go infringe upon). Later on, you want maintainability and ensure…

(By the way, why is it okay for a function to have unused input parameters?) That's caused by Go's interfaces and function type signatures. It may be necessary for a method or function to accept certain arguments to satisfy an interface or type signature even when those arguments don't get used. It's a bit of a wort I agree.

[deleted]

Re: I Love Go; I Hate Go

#319

Post by pcwalton »

jerf wrote: post #302
Someone wrote: post #276

Earlier quoted context omitted.

"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 probabl…

> Go is probably the most highly polished language from the 1980s.

I think ML pretty objectively takes that crown, semantically speaking. For simplicity and elegance it's pretty difficult to beat.

Re: I Love Go; I Hate Go

#320

Post by scott_s »

devishard wrote: post #316
scott_s wrote: post #310

Earlier quoted context omitted.

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…

Okay, why don't you assume in everything I'm talking about fluffy rainbow butterflies or something nice like that? Principle of charity, right? That way we can both go our separate ways happily. If someone doesn't mean "fully statically typechecked" then they shouldn't say "fully statically typechecked". It's not an ambiguous phrase.

That is not what it means: http://philosophy.lander.edu/oriental/charity.html

People have different backgrounds and and experiences. It's reasonable for a person to think "fully statically typechecked" to mean "a program which is statically typechecked, and it does so to the entire program". That would apply to languages such as C, C++ and Go, which are statically typed, but give ways to subvert the type system. You probably mean something closer to "a program which has fully sound static typing", more along the lines of the MLs or Haskell, which have a richer type system which you cannot subvert.

We're here for interesting discussion. Derision is not a part of interesting discussion. You're relatively new here, so I figure it's worth explaining this explicitly.

Post reply on HN