21 ms·
I Love Go; I Hate Go
- simplehuman 10y agoHonest 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.
- anilgulecha 10y agoProbably because the author is a renowned engineer (dtrace, etc)
- simplehuman 10y agoSo the whole voting system is artificially skewed by HN admins?
- nzjrs 10y agoYou must be new here
- joe_the_user 10y agoI'm not new here and I'm somewhat taken aback
- nzjrs 10y agoOh. 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!
- scrollaway 10y agoIt'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.
- mrmagooey 10y agoThere'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.
- Eutow 10y agoIsn'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.
- jdoliner 10y agoHN 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.
- paradite 10y agoThe 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.
- Tomte 10y agoThat'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.
- simplehuman 10y agoWhen I saw it on the front page, it had only 4 votes. How can that count for anything?
- Tomte 10y agoFour upvotes in the first minutes are absolutely a strong signal.
- reactor 10y agoBesides 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.
- simplehuman 10y agoSure, but it had only 4 votes and it was second on front page
- dang 10y agoAs 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.
- Sylos 10y agoThat 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.
- dang 10y agoSure, 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.
- jefozabuss 10y agoCached version in case of 503: http://webcache.googleusercontent.com/search?q=cache:VcehlYQXduwJ:dtrace.org/blogs/ahl/2016/08/02/i-love-go-i-hate-go/+&cd=1&hl=en&ct=clnk&gl=de http://webcache.googleusercontent.com/search?q=cache:VcehlYQ...
- iso-8859-1 10y agoarchive.is: https://archive.is/BdvtP https://archive.is/BdvtP
- bubersson 10y agoI agree and disagree with the post title.
- deleted 10y ago[deleted]
- andrewfromx 10y agoHere's a way to love go, write a language in it https://github.com/grubby/grubby https://github.com/grubby/grubby
- the_duke 10y agowhatevs...
- pjmlp 10y agoYeah what were/are Xerox PARC, ETHZ, Microsoft, Apple, Google thinking in their language departments!
- millstone 10y agoWhat interpreters did these orgs write in GCed languages?
- pjmlp 10y agoA few examples from Oracle/Sun using the Graal VM engine, written in Java: https://github.com/graalvm https://github.com/graalvm From Microsoft: http://ironpython.net/ http://ironpython.net/ http://ironruby.net/ http://ironruby.net/ https://msdn.microsoft.com/en-us/library/dd233052%28v=vs.110%29.aspx https://msdn.microsoft.com/en-us/library/dd233052%28v=vs.110... https://msdn.microsoft.com/powershell 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 http://dl.acm.org/citation.cfm?id=17919.806844
- millstone 10y agoThese 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.
- twblalock 10y agoThe most frustrating thing for me, by far, is that Go won't let you import unused packages. When you are commenting stuff out to debug a program, or adding debug statements and removing them later, it constantly requires you to go back to the top of the file and comment out the unused libraries, only to uncomment them later when you've solved your problem. The fact that there is not a compiler flag to disable this behavior, and that the core team is opposed to adding such a flag (https://golang.org/doc/faq#unused_variables_and_imports https://golang.org/doc/faq#unused_variables_and_imports), is simply ridiculous and makes programming in Go a real pain in the ass. I can't think of any other language that does this.
- Sean1708 10y agoI think that's the thing that really gets me about Go. I really like that it's opinionated and forces you to write good code, but I just can't understand why they refuse to allow you to turn them off when you need it. Also doesn't that workaround completely nullify all the arguments they made in that section? And it puts the programmer in a worse position than if they could just turn it off temporarily.
- jerf 10y ago"I just can't understand why they refuse to allow you to turn them off when you need it." The answer to this and a lot of similar such questions about Go is "scale". Things that were sorta kinda convenient for you in a couple hundred lines become nightmares when several dozen developers on several hundred thousands lines of codes had differing ideas of what was convenient for them at the time. Just as you can't understand Erlang until you understand its emphasis on reliability, you can't understand Go until you understand its emphasis on coding at scale. Almost (but not quite) everything people can't understand about Go are things that people want to do because they work well locally, but things that have become serious problems in source code bases at scale. You also can't understand Go until you realize that the problems weren't merely hypothesized, but extracted from real already-existing source code bases. That said, I still feel they missed some steps. I'd like non-nil-able pointers. (Optional, like C#, because the way Go methods work means that if you're careful nil pointers of a certain type are perfectly legal and can have sensible methods on them, but that's not always the case.) Packaging is another obvious case where Google had an answer that worked for them so they didn't see a problem, though that's being worked on. (I'm struggling through this because I consider it a non-negotiable feature that my packaging solution allows me to locally mirror everything I use, which all packaging systems (not just Go!) seem to consider some bizarre use case. Strange, I consider it a basic requirement for truly professional development.) So bear in mind I don't mean this necessarily as a defense of Go, I'm talking about what it takes to understand it. (Edit: also, yes, I consider it a bit sad that Go doesn't have iterator support, per my comment at https://news.ycombinator.com/item?id=12210351 https://news.ycombinator.com/item?id=12210351 You can sort of bash some stuff together, and io.Writer and io.Reader cover a common case for Go programs and can be composed, but it's still a bummer.) It is completely the case that some people will come to a greater understanding of Go, and realize it's the wrong choice for their problems. But perhaps it will, at the very least, be less threatening that other people do consider it a good choice for their problems.
- cespare 10y agoGOEXPERIMENT=framepointer will be the default in 1.7, due out in a few days (see https://golang.org/issue/15840 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.
- crench 10y agoWeak opinions are what turn languages into unreadable mishmashes of overlapping mechanism. Go's opinions were, for me, especially helpful while learning the language.
- fuzzy2 10y agoI 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.
- dcw303 10y agoI'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".
- tuxt 10y ago>It's very clear to me when to write Go and when not to. Would you care to elaborate on this? :)
- dcw303 10y agoMy 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.
- deleted 10y ago[deleted]
- dpc_pw 10y agoOh. Go love-hate relationship post. My turn. So I really like channels and coroutines built into language and used everywhere: it makes some patterns compose nicely and language very productive. But just as in the article - some of Golang choices are opinionated and IMO just stupid. Lack of assertions is one: Sure programmers are prone to ignoring errors, but Go is not helping at all. Just bans assertions and provides no improvements. No `try!`&`Result` like Rust, not even warning by default if you ignored returned error (IIRC, go lint or go vet checks it) . So what's the point? How do you decrement an atomic in Go? AddUint32(&x, ^uint32(c-1)) That's how. Easy to read, and self-explaining. https://golang.org/pkg/sync/atomic/ https://golang.org/pkg/sync/atomic/ . I mean... come on. Unused errors being an error is super annoying, and changing variable capitalization everywhere, because you want to change symbol visibility is another daily frustration source. Oh, and all my contacts with the community were very unpleasant (maybe it's just me, or bad luck). Any questions ended with some form of "you must do it one true way, otherwise you're stupid". Eg. once I was looking for a way to terminate unit test in case of error, instead of writing `if err != nil { t.Errorf(...) }` over and over again after every line, as in test, every error is just terminating condition. In Rust I would just `.unwrap()` or `.expect()`, which would fail the test, report backtrace, etc if anything unexpected went wrong. All the help that I got was just snarky comments for being lazy. I will continue to use Go in some projects, as it gets the job done, performance is OK, has some userbase, and ecosystem is quite vital, but overall, it seems to me that it's rooted in same form of stubborn crudeness that has no good reason in XXI century, ignoring years of research and good ideas. For anything more demanding, or fun I would always go with Rust.
- biztos 10y agoFor your unit-testing problem, I highly recommend `testify/assert`: https://godoc.org/github.com/stretchr/testify/assert https://godoc.org/github.com/stretchr/testify/assert
- kasey_junk 10y agoThe fact that golang ships with a unit test library that does not contain equality assertions is aggravating. Their political stance on it is just one of many places the language designers come off less as opinionated and more as that they know my problem sets better than me.
- deleted 10y ago[deleted]
- EugeneOZ 10y ago> 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 are trying to use it. Panicking messages - another story, but it's not compiler's error messages, it's runtime. In example of code Adam using as proof, author is using 'panic' and 'unwrap' - reasons to don't expect gentle behavior. If you can't write code in idiomatic way, try to catch your panics and give more descriptive runtime error message in your code - other users of language shouldn't pay for it.
- valarauca1 10y agoThis 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 borrow checker.
- masklinn 10y ago> 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.github.io/My-First-Steps-In-Rust/ http://dbeck.github.io/My-First-Steps-In-Rust/ note two issues: * the error message is busy as all hell which is a common issue in Rust, before you've built the habit and learned how they're structured Rust error messages often look daunting. 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. * the suggestion it provides is just plain wrong, it suggests implementing Debug for T, but T is always a standard number which already implement Debug, what's missing is a trait bound. To a beginner that was not a helpful suggestion as it would only send them on a wild goose chase (of trying to implement Debug on either T or i32/f32, and good luck with those). > The blog explaining the author's disdain for Rust mostly just seems to whining about the borrow checker. So? Just like monads in haskell, the borrow checker is hard until it "clicks" (and then it fundamentally shifts your understanding and it becomes hard to understand not getting it). [0] and experience/understanding for the various possible sources of the most common ones, but that you can build for any compiler, even G++'s pages of template expansion garbage from the early aughts
- jokoon 10y agoI 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.
- kalekold 10y agoMy take on Go: http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/ 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.
- jbeja 10y agoWhy not just use Java? Is faster, have better tooling.
- fauigerzigerk 10y agoMy 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
- garfij 10y agoI'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.
- _ph_ 10y agoI like Go quite a lot. Mainly I am a Lisp programmer, so I am not looking for the next most high level programming language. I am looking for a language which gets things done, where Lisp doesn't quite fit. For jobs, which traditionally would have been done in C. Programs that run fast and have a reasonable complexity. It brings back the virtues of the Wirth computer language family back into modern times, as with strict type checking and the module system. On top of that it adds memory safetey due to the presence of GC. Go it easy to learn, as its a moderately sized language, but it has just enough abstractions, that your programs are not held back by the lack of those, without opening the traps too "powerful" languages bring with themselves, namely complexety. On top of all, the whole infrastructure is very well thought out and a pleasure to use. A very fast compiler which produces static executables, a good module system without header files, a rich standard library, many things. There are quite a few quirks, especially for the beginner, but the more I gain insight, the more I agree with the choices made - with some I don't, but the agree to disagree ratio is surprisingly high. And most of them don't get into the way of writing good programs, which is what counts.
- junke 10y agoI am really curious about the kind of tasks that are easily done in Go but for which Lisp doesn't quite fit.
- _ph_ 10y agoSometimes I like to have a fully statically typechecked program. You can do that in Lisp, its easier in Go. Also, it directly produces statically linked executables. You can do a lot of this in SBCL, it also produces executables, has type checking etc. But for some of this, you have to wrestle a bit with the Lisp system. The Common Lisp numeric tower is great - until you want to write low level programs where you just want to have machine word sized integers which may wrap around. I once even submitted an abstract to a Lisp conference addressing some of these issues, but as it was not accepted, this side-project was postponed (but I plan to revive it some day). And of course, there is always the question of the environment. The Go universe has tons of libraries, actively developed.
- donatj 10y agoI 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.
- devishard 10y agoIt'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.
- ahl 10y agoFWIW this is the project that pulled me down this golang rabbit hole: https://news.ycombinator.com/item?id=12211754 https://news.ycombinator.com/item?id=12211754
- zzzcpan 10y agoThose 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-http-timeouts/ https://blog.cloudflare.com/the-complete-guide-to-golang-net... [2] https://github.com/golang/go/issues/16100 https://github.com/golang/go/issues/16100