Hacker News new | past | comments | ask | show | jobs | submit | page 2 login
I Love Go; I Hate Go (dtrace.org)
279 points by tominous on Aug 2, 2016 | hide | past | web | favorite | 316 comments



GOEXPERIMENT=framepointer will be the default in 1.7, due out in a few days (see https://golang.org/issue/15840), so using tools like perf (and presumably dtrace) will be somewhat improved out of the box.

Edit: and the author mentions that at the end of the post. That's what I get for commenting before I've read the whole thing.


I'm a little confused by the author's belief Go needs to be more pragmatic. All the points made in the "I Love Go" section (gofmt, the toolchain, interfaces) display strong qualities of pragmatism to me. The article literally describe interfaces as 'no-nonsense and pragmatic'. And, even if they do not personally like the opinionated nature, it is a prime example of solving questions in a practical way.

No language can be everything to everyone. One thing that encourages me to keep writing Go is the team has done a very good job at communicating their intentions for the language.

It's very clear to me when to write Go and when not to. That's a sign of strength to me, as it shows the language has the confidence to tell you "perhaps I'm not the best choice for this particular problem".


>It's very clear to me when to write Go and when not to.

Would you care to elaborate on this? :)


My main two use cases so far have been services and command line tools where it's not worth taking the effort to manage memory. The former I would have previously written in Java or C# (yeah, tie me to the cross right now language hipsters, I don't care, I already said I'm a pragmatist), and the latter in Ruby or Python.

I actually enjoyed going from dynamic to static typing for command line tools, the compiler saves me a lot of time tracking down bone-headed errors, which are typos in variables 95% of the time.


My favorite little annoyance with Go is the way the := operator behaves with multiple assignment. It declares a new variable if there is no variable of that name in the current scope. But it refuses to do that if there are struct fields involved.

  var t int
  t, err := someFunc() // that's fine
but this doesn't compile:

  var s struct{ x int }
  s.x, err := someFunc() // doesn't compile


I've run into that as well, but I've since come to favor avoiding that pattern entirely as a code smell.

In your example, you end up modifying the struct value x, even if there was an error. Maybe there are cases where that is the correct behavior, but even then I would advocate for explicitly setting the struct value after handling the error, to make it very clear that it was your intention to do so, rather than doing it be accident.


Weak opinions are what turn languages into unreadable mishmashes of overlapping mechanism.

Go's opinions were, for me, especially helpful while learning the language.


I don't know, I found debugging with IntelliJ's Go plugin intuitive and well-working. Pretty sure it uses Delve under the hood.

I think strong opinions are helping Go not being "yet another language". So that's good. Like most things, it isn't for everyone.


I have great hopes for D since Andrei Alexandrescu joined to work on it.

When you see all those new system languages, (go, rust, swift), D was there before them, and did not pretend to be a new cool thing with good ideas, it just tries to be a nicer C++ to work with.

I don't need to do things the right way, I just need a language that is usable and doesn't try to do the job for me.




My take on Go: http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-in...

I still use it but I also have a love, hate relationship with it.


Here's a way to love go, write a language in it https://github.com/grubby/grubby


I would really like to see some mruby bindings for Go. It would be simpler than re-implementing ruby in Go.


https://github.com/mitchellh/go-mruby There are others, but that one looks complete.


whatevs...


Why wouldn't it be? Instead of rolling out your own, bad GC, you can rely on the tested built-in. Of course you would be careful to write the interpreter loop so that it does not allocate memory just for interpreting, but that should be easy in a decent language.


Yeah what were/are Xerox PARC, ETHZ, Microsoft, Apple, Google thinking in their language departments!


What interpreters did these orgs write in GCed languages?


A few examples from Oracle/Sun using the Graal VM engine, written in Java:

https://github.com/graalvm

From Microsoft:

http://ironpython.net/

http://ironruby.net/

https://msdn.microsoft.com/en-us/library/dd233052%28v=vs.110...

https://msdn.microsoft.com/powershell

Xerox PARC used Cedar for the software implemented on Xerox 1132 (Dorado) and Xerox 1108 (Dandelion) systems, including interpreters delivered on the system:

http://dl.acm.org/citation.cfm?id=17919.806844


These are just experiments on the margins. In each case, the flagship languages are not implemented on top of GC'd runtimes or interpreters. Apple's Objective-C and Swift runtimes are both C++. Microsoft's C# CoreCLR is C++. Google's V8 and Dart have runtimes written in C++. Oracle's HotSpot is C++. Go's core runtime is in a Go-minus-GC subset.

It didn't have to be this way - Swift could have been written atop the JVM, v8 could have been implemented via Boehm, etc. For whatever reason, when it counts, the stuff under the hood doesn't use garbage collection.


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 runtime is in a Go-minus-GC subset.

Of course, there needs to exist a Genesis for the GC, but once it is there, 99% of the remaining infrastructure makes use of it.

If you take Nashorn engine running on Jikes, it is an 100% Java stack running a JavaScript interpreter.

> For whatever reason, when it counts, the stuff under the hood doesn't use garbage collection.

Most of the time it is just building on top of whatever already exists instead of starting from scratch.

Taking Swift as an example bootstraping the language would increase the burden designing it, as they are still far from fully stable design.

If they would throw away in man years invested into the LLVM, which happens to be written in C++, it would take ages before pure Swift compilers would ever manage to catch up.

However these shortcuts open the door for those not savvy in compiler design to use as ammunition against secure languages.


> 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's not competitive with any of the major JS engines, all of which have C++ runtimes.

> Taking Swift as an example bootstraping the language would increase the burden designing it, as they are still far from fully stable design. If they would throw away in man years invested into the LLVM, which happens to be written in C++,

This still confuses the compiler with the runtime. The Swift compiler is indeed written in C++ using LLVM, but it could have easily been written in a GCed language without affecting much of anything.

But the runtime is separate, and it also happens to be written in C++. It's possible to imagine the Swift runtime written in a GCed language, but that is not what Apple chose to do.


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


Which interpreters are you thinking about that are written in a GC'd language?



Do you even know Go's GC guarantees?


I don't! What are they?


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.


Well, the latency is capped at 10 ms, the STW phases will stop at that limit. So that guarantee can be kept as long as your memory allocation throughput is low enough so as not to trigger a GC run more than 20 times a second. Which is pretty good. There aren't that many GC implementations in production that will give you a guarantee of the same or similar quality.


Can you point me to an authoritative source that explains what exactly is guaranteed under what assumptions and what is done on a best effort basis only?


The authoritative source is the Go source code. Read it, it's relatively easy to understand, and fairly obvious that the STW mark termination phase goroutine (like any other goroutine) will be preempted after forcePreemptNS (which is 10ms), and if that happens even though it hasn't finished its work, it transitions to a concurrent task, and resumes later.

If you're interested in the finer details, I'm sure the GC talk at golangUK later this month will discuss them all, and the slides and/or videos will eventually land here on Hacker News.


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


I think a persons opinion on Go really depends on where you're coming from and what tooling they are used to. As a PHP/Node/Ruby dev I find Go does everything PHP/Node/Ruby does, faster, and more reliably due to static typing. Often more verbosely though.

I've simply never wanted for the things he asks as I've never had them. It's all in the expectations is my point.


It's telling that the most sophisticated type system you've dealt with is Ruby, though. I think that if you spent some time working in OCaml/Nim/Rust/D/C# you'd learn a lot which would cause you to be a lot less impressed with Go.


Those are really small annoyances compared to everything else in Go. I don't mind Go being opinionated, everything is like that anyway and it's kind of nice in some ways. But don't mistake opinionatedness with misdesigned poor quality libraries and experimental ideas.

Take net package for example, it's not opinionated, it's just completely broken and misdesigned. There is so much mess with even the most basic things, like timeouts and cancellations [1][2] that it's almost impossible not to fuck up somewhere.

This is because the whole net library is synchronous and pushed onto experimental ideas of goroutines and channels. Instead of having an actual event loop underneath with timers, signals and everything and use asynchronous writers and readers they just poll fds and wake goroutines when fds are ready, forcing themselves to deal with typical multithreaded concurrency hell.

[1] https://blog.cloudflare.com/the-complete-guide-to-golang-net... [2] https://github.com/golang/go/issues/16100


FWIW this is the project that pulled me down this golang rabbit hole: https://news.ycombinator.com/item?id=12211754


Honest question: How does a post with just 4 points and posted 11 minutes ago get to be on the front page? Even amazing it is number 2 right now.


As Tomte and jdoliner pointed out, 4 points in 11 minutes would get you on the front page at any time, let alone a slow time like this one. As for why the post would get rapid votes, that's easy: moth-to-flame subject matter.

It's not great to post comments like this taking a thread so badly off topic, let alone jumping to conclusions that the admins are manipulating what is obviously (once you're familiar with it) baseline HN behavior. Love-hate-Go posts are a drug here; and so are all things Rust, which is why those stories are currently #1 and #2. If we did anything to posts like that it would be to downweight them, but I'm tired, and a good pro-and-con language vent seems like a fairly innocuous thing for HN to do overnight (with apologies for our Pacific-timezone-centricity), so have at it.


That seems like a dangerous system, though. Just a few coordinated upvotes can get a post to the front page. And if it's so easy, you'll almost certainly have people/companies abusing that to promote their content.


Sure, but this problem has been around for years, and HN has developed many mechanisms to deal with it. Some are obvious—if a post gets to the front page without community interest, it will quickly attract flags, and probably a lot of ornery comments too—and many more run silently beneath the surface. I think the proof is in the pudding: we don't see a lot of this. Anybody getting away with it regularly is probably being so devilishly clever as to deserve their ill-gotten gains.


The rate of growth of the upvotes w.r.t time is extremely high for this submission. 0.5(just now) to 1(now) upvote per minute.


That's normal.

I'm a nobody (to answer the accusation below) and my submissions of articles that are years old and not recognizably "hot" make it to the front page with only three to five upvotes all the time.

Quick upvotes or comments count for a lot.


When I saw it on the front page, it had only 4 votes. How can that count for anything?


Four upvotes in the first minutes are absolutely a strong signal.


Probably because the author is a renowned engineer (dtrace, etc)


So the whole voting system is artificially skewed by HN admins?


HN has always had some editorial oversight from admins. That being said I'm not sure why you were initially surprised at this being on the front page with 4 upvotes in 11 minutes. That's a lot by hn standards. Check new, this and 1 other post are the only ones above 4.


You must be new here


I'm not new here and I'm somewhat taken aback


Isn't 4 upvotes in 11 minutes a lot for Hackernews? I don't think there's anything untoward going on here but I may be naive.


Oh. Ranking here has always been mysterious and corrupt.

Do You think all those ycombinator company posts get to the front page on their own merit? Ha!


There's several hundred Y Combinator companies, but I don't think I've seen a commensurate number of posts to HN. You'd know if it was open slather on Y Combinator companies posting self-promotion material to HN because this post would not be at the top, it would be some launch page for a company ending in 'ly'.

I typically only notice YC companies mentioned here when it is a Techcrunch (or similar) article about them.


It's as if a community of programmers and engineers can't understand the various weights a ranking algorithm can take into account outside of plain "2 > 1".

Stunning.


Besides other points mentioned, I think HN crowd has a love/hate relationship with Go (the other one I noticed is Python), so it's natural to go up quite fast.


Sure, but it had only 4 votes and it was second on front page


I agree and disagree with the post title.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: