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

321–329 of 329 posts

Re: I Love Go; I Hate Go

#321

Post by jerf »

pcwalton wrote: post #319
jerf wrote: post #302

Earlier quoted context omitted.

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

I should have said mainstream 1980s. Obviously you can find any number of more sophisticated lanugages in the 1980s by features, give or take the multicore support which, depending on context, was less relevant back then, but not in the mainstream. By that metric ML is still probably "ahead of its time".

Re: I Love Go; I Hate Go

#322

Post by valarauca1 »

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.

The borrow checker is the simplest thing once you internalize it's rules. Just the road to breaking all the bad habits C/C++ teach you are fine over the years takes a while. And most these rules are mostly excessive and unnecessary coming from a C perspective. The borrow checker is kind of like type systems. It prevents a whole class of errors, but you lose the ability to express some perfectly valid code.

It is really a kind of mental-quantum-leap. Once you internalize it's rules you really lose the ability to understand how other people can't.

Also to deflect some blame from The Rust-Community. I'm just kind of a horrible person on the internet. I'm working on improving :\ Sorry for the coarse comment.

Re: I Love Go; I Hate Go

#323

Post by themihai »

coldtea wrote: post #301
themihai wrote: post #235

Earlier quoted context omitted.

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

>>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 don't say that you should never use C++. Sometimes it's a necessary evil but that doesn't make it a great/pleasant choice(at least for me).

>> Great ecosystem and tooling

I think it could be considered GREAT 20 years ago but now it is miserable compared with the new languages. For example it has no kind of distribution model(i.e package manager). Cross platform compiling is no fun... C++ parsing is no fun either so you could say that its syntax is quite important if you were to develop new tools.

Re: I Love Go; I Hate Go

#324

Post by devishard »

scott_s wrote: post #320
devishard wrote: post #316

Earlier quoted context omitted.

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…

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

I'm aware of what it means--I'm saying that the principle of charity doesn't apply. The principle of charity doesn't mean you get to actually change what the person is saying, it means you assume the best when there's ambiguity.

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

But in the cases of C and Go, it's not just that--you can't use generics or templates, so you're stuck writing generic-like code with void* or object, respectively. That's not subverting the type system intentionally, it's just not type checked and there's no alternative. So these languages are not fully type checked, even if you don't subvert the type system. So even by your charitable definition, it's not fully statically type checked.

The word "fully" has a meaning that's not ambiguous. There's not an interpretation of "fully statically typechecked" that includes Go, even being charitable. Every nontrivial Go codebase has sections that are not statically typechecked and can't be modified to be statically typechecked.

> We're here for interesting discussion. Derision is not a part of interesting discussion.

I'm here for interesting discussion, and I don't think that an interesting discussion starts from obvious falsehoods like "Go is a fully statically-typed language". Derision discourages making such statements and increases the average interesting-ness of discussion because people are afraid to say dumb things. People should think before they make claims.

> You're relatively new here, so I figure it's worth explaining this explicitly.

I'm not new here, I just delete my accounts every so often.

Re: I Love Go; I Hate Go

#325

Post by scott_s »

devishard wrote: post #324
scott_s wrote: post #320

Earlier quoted context omitted.

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…

> That is not what it means: http://philosophy.lander.edu/oriental/charity.html I'm aware of what it means--I'm saying that the principle of charity doesn't apply. The principle of charity doesn't mean you get to actually change what the person is saying, it means you assume the best when there's ambiguity. > People have different backgrounds and and experiences. It's reasonable for a person to think "fully staticall…

Derision is not civil, and explicitly discouraged.

Re: I Love Go; I Hate Go

#326

Post by devishard »

scott_s wrote: post #325
devishard wrote: post #324

Earlier quoted context omitted.

> That is not what it means: http://philosophy.lander.edu/oriental/charity.html I'm aware of what it means--I'm saying that the principle of charity doesn't apply. The principle of charity doesn't mean you get to actually change what the person is saying, it means you assume the best when there's ambiguity. > People have different backgrounds and and experiences. It's reasonable for a person to think "fully staticall…

Derision is not civil, and explicitly discouraged.

True, but given the entire point here is to have interesting conversations, I think that's a higher priority than civility.

Re: I Love Go; I Hate Go

#327

Post by devishard »

jsmith0295 wrote: post #314
devishard wrote: post #305

Earlier quoted context omitted.

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.

> I think I just don't come across situations where I find myself needing generics in the software that I typically write.

You don't need generics, sure. You can write working code in assembly, too. But abstractions catch more of your mistakes for you.

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

So, basically slightly more powerful macros, like in C, with most of the pitfalls and dangers associated with them.

There are better approaches to these problems.

Re: I Love Go; I Hate Go

#328

Post by scott_s »

devishard wrote: post #326
scott_s wrote: post #325

Earlier quoted context omitted.

Derision is not civil, and explicitly discouraged.

True, but given the entire point here is to have interesting conversations, I think that's a higher priority than civility.

They are considered the same thing here. There is a reason it comes first in the guidelines on comments.

Re: I Love Go; I Hate Go

#329

Post by fishnchips »

kmiroslav wrote: post #313
fishnchips wrote: post #300

Earlier quoted context omitted.

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

Is it relevant to the question at hand? Languages != their IDEs.
Post reply on HN