I Love Go; I Hate Go • Hacker News Board

Re: I Love Go; I Hate Go

#251

Post by AnimalMuppet » Tue, Aug 02, 2016, 4:46 PM UTC

wruza wrote: post #35

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…

Stockholm syndrome in action. There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. If someone is not disciplined enough to throw out unused variables/imports/whatever from release, Go will not save him from hell.

> Stockholm syndrome in action.

So here's a language feature that you don't like. Other people don't like it and then, after they get more experience, decide they like it after all. And you call it Stockholm syndrome? By saying that, you're asserting that there is no possibility that the feature could possibly be anything other than harmful. That's... pretty arrogant, actually. Both the language designers and the users who like it are objectively wrong, and you're right?

Look, you don't like it. That's fine. It doesn't work with the way you like to develop. That's fine, too. But your assertion is that it is worse than useless for all users, and that's a bit more than you have the knowledge to assert.

Re: I Love Go; I Hate Go

#252

Post by masklinn » Tue, Aug 02, 2016, 4:48 PM UTC

bbatha wrote: post #230

masklinn wrote: post #86

Earlier quoted context omitted.

> Is that really the _best_ way to delete from a slice in Go? Yep[0], and it needs a special case to remove the last element of the slice (if the index is user-provided). If you don't care about the slice order you can also swap the element you want to delete with the last element of the slice and shrink the slice by one element. Also fun, it can leak memory. [0] https://github.com/golang/go/wiki/SliceTricks

That article is a concession speech on why generics are useful. Every single "trick" in the article is titled with the name of the equivalent method in more powerful languages. I don't think its possible to look at that list of tricks or the amount of boiler plate to get simple methods like `sort` or `keys` and assert the language is "simple" and better off for it.

Not even that, Go does have generics for its special magical builtin types (map, slice, channels, … are generic) or functions (close, delete or the aforementioned append are generic)

Re: I Love Go; I Hate Go

#253

Post by AnimalMuppet » Tue, Aug 02, 2016, 4:53 PM UTC

junke wrote: post #62

dmoy wrote: post #15

Earlier quoted context omitted.

I think it depends on what you're using it for. On my day-to-day I'm working with absolutely massive pieces of software that have dependency trees that would literally make me cry if I stopped and thought about it too hard. In that world, this sort of thing enforced strongly makes me much happier. For random one-off hacking, yea, it'd be a pain. Differing use cases lend cause to different tooling.

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.

Re: I Love Go; I Hate Go

#254

Post by steveklabnik » Tue, Aug 02, 2016, 4:53 PM UTC

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…

It's worth noting that the Rust project itself doesn't consider our current error setup as good as it could be. Set "RUST_NEW_ERROR_FORMAT" to get a preview of what we've been working on.

I do like the current errors, but that's no reason to rest on our laurels! There's a lot of ways in which they're not great.

Re: I Love Go; I Hate Go

#255

Post by pjmlp » Tue, Aug 02, 2016, 4:56 PM UTC

millstone wrote: post #85

pjmlp wrote: post #79

Earlier quoted context omitted.

The question was "What interpreters did these orgs write in GCed languages?". It doesn't matter where those interpreters are being used, the fact is that they exist. > Microsoft's C# CoreCLR is C++. Yes, but they have moved their compilers to C# with the Rosylin project with MDIL and .NET Native moving more code to C# side. Also check the Phoenix compiler framework, a LLVM like project from MSR using C#. > Go's core…

> Yes, but they have moved their compilers to C# A compiler is a different matter. GCed languages are very compelling for static compilers. Even gcc uses GC internally. The claim is that GCed languages make for poor interpreters - and also poor JIT compilers and runtimes. > If you take Nashorn engine running on Jikes, it is an 100% Java stack running a JavaScript interpreter Nashorn gets participation points, but it'…

> The claim is that GCed languages make for poor interpreters - and also poor JIT compilers and runtimes.

Have you ever spent time with Graal, Truffle, PyPy?

30 years ago I used to take the flak for arguing about C++'s suitability for writing programming language tools in comp.compilers instead of C.

Yet here we are praising C++ virtues over other languages for writing interpreters and JITs.

One thing I learned in all those years reading compiler related papers, is that many times the main issues are actually human and not technical.

The majority just want to have something running, and take the shortcut of using whatever works to achieve their goals, instead of taking the effort that might bring the technology forward but would delay getting everything to work.

Re: I Love Go; I Hate Go

#256

Post by AnimalMuppet » Tue, Aug 02, 2016, 4:59 PM UTC

pjmlp wrote: post #170

TurboHaskal wrote: post #132

Earlier quoted context omitted.

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.

Define "feature".

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

Re: I Love Go; I Hate Go

#257

Post by tptacek » Tue, Aug 02, 2016, 5:08 PM UTC

unscaled wrote: post #241

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…

I'm using goimports too, and it works like magic 95% of the time, while I can manually take care of the rest. But it only solves the unused imports issue. During development (especially when playing with code) I often need to temporarily comment out a section of code. I go build, and the situation usually unfolds like this: - ERROR! Yes, now, I have an unused variable dangling around, because this code was using it.…

The unused variables are the things that can really cause bugs in your code. It's annoying, and I share your annoyance, but I have also sighed to myself and said "shit, I'm glad Go caught that" after noticing really bad bugs that the error flagged.

Re: I Love Go; I Hate Go

#258

Post by madgar » Tue, Aug 02, 2016, 5:11 PM UTC

fauigerzigerk wrote: post #150

_ak wrote: post #110

Earlier quoted context omitted.

40 ms mutator time per 50 ms time window. That means that your program will never be interrupted for longer than 10 ms within 50 ms. In practice, the STW mark and sweep phases are in the sub-millisecond range, and the GC runs not nearly as often as 20 times a second, so 10 ms of interruptions per 50 ms is the absolute worst case.

I think these are goals, not guarantees, and the numbers are predicated on assumptions about extra free memory available to the GC. There is an inherent tradeoff between pauses, throughput and extra memory requirements.

The goals are also predicated on your OS configuration and having a zero load average.

Re: I Love Go; I Hate Go

#259

Post by masklinn » Tue, Aug 02, 2016, 5:15 PM UTC

Ygg2 wrote: post #245

masklinn wrote: post #105

Earlier quoted context omitted.

> The author clearly hasn't worked with Rust. The author links to a previous post on the subject, from mid-2015, so they clearly have at least tried Rust in the past. 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). Here's a clearer example (fixed since): http://dbeck.githu…

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

Re: I Love Go; I Hate Go

#260

Post by junke » Tue, Aug 02, 2016, 5:32 PM UTC

tptacek wrote: post #257

unscaled wrote: post #241

Earlier quoted context omitted.

I'm using goimports too, and it works like magic 95% of the time, while I can manually take care of the rest. But it only solves the unused imports issue. During development (especially when playing with code) I often need to temporarily comment out a section of code. I go build, and the situation usually unfolds like this: - ERROR! Yes, now, I have an unused variable dangling around, because this code was using it.…

The unused variables are the things that can really cause bugs in your code. It's annoying, and I share your annoyance, but I have also sighed to myself and said "shit, I'm glad Go caught that" after noticing really bad bugs that the error flagged.

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 that does not abide to the proper style? Improper formatting can lead to confusion, bugs and maintenance problems too, after all.