8 ms·
Oh. 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 ni
by dpc_pw 10y ago
Oh. 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.
- millstone 10y ago> How do you decrement an atomic in Go? Ooh. How do you delete from a slice in Go? With append() of course! http://stackoverflow.com/questions/25025409/delete-element-in-a-slice http://stackoverflow.com/questions/25025409/delete-element-i...
- nneonneo 10y agoThat solution (append(a[:0], a[1:]...)) doesn't look remotely performant. I don't have a copy of go handy to test, but exploding most of the list into individual arguments and passing them to a variadic function, just to pack them all back into an array, seems quite circuitous to me. Is that really the _best_ way to delete from a slice in Go?
- thwd 10y agoA slice is a view over a continguous array. deleting an index in a continguous array is inherently O(n). Go doesn't obscure this. The pain of writing it out reflects the complexity of the operation.
- deleted 10y ago[deleted]
- coldtea 10y ago>The pain of writing it out reflects the complexity of the operation. And why would one even remotely want that? Unless they seriously think that if the syntax is painful, people will avoid doing it and get better performance...
- masklinn 10y ago> 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 https://github.com/golang/go/wiki/SliceTricks
- thewhitetulip 10y ago>and all my contacts with the community were very unpleasant I can testify to this! I even got banned from the golang subreddit :-D EDIT: I didn't bully anyone or anything, just told them that they can't call the language as golang, because when I had asked feedback on my work an year ago, the only feedback I got from a certain person and that too very rudely was "to not call the language Golang and call it Go, ruby is called ruby and not rubylang"
- nindalf 10y ago> > all my contacts with the community were very unpleasant > I can testify to this Even though you showed up on the golang subreddit, asked a question about javascript [1], got two answers (one without jquery, one with), you can attest to the unpleasantness of that subreddit? Even when you posted your todo manager written in Go, the majority of the feedback you got was positive. I find your reaction a little surprising. [1] - https://www.reddit.com/r/golang/comments/44g3ln/help_required_am_struggling_in_using_ajax_with_go/ https://www.reddit.com/r/golang/comments/44g3ln/help_require...
- thewhitetulip 10y agoYou are right, by "community" I meant the core team and not the reddit community. they have been awesome (except the core team). I got a lot of positive feedback about the todo manager and the book. My apologies for the unclear comment. When you look at the Go ecosystem there are two classes: 1. core team (the elites) 2. others (us plebeians) The parent post has a brilliant line, which made me laugh for half hour: >I wanted to check an invariant; how does Go do assertions? Fuck you, you’re a bad programmer. That’s how. the others are awesome, my interaction with the core team was far from pleasant. They are rude and outright snarky. They focused on the book title more than the content and didn't even bother to read the content. I mean they did take a cursory glance, but the others on reddit were amazing: https://www.reddit.com/r/golang/comments/3zle8c/i_am_writing_a_book_about_writing_web_apps_with/ https://www.reddit.com/r/golang/comments/3zle8c/i_am_writing... https://groups.google.com/forum/#!searchin/golang-nuts/suraj$20patil%7Csort:relevance/golang-nuts/F4LJwyYZcXU/nKEL9hHOEAAJ https://groups.google.com/forum/#!searchin/golang-nuts/suraj... This is how I got banned from the subreddit. Anyways Good for me, I stopped browsing reddit that much. https://www.reddit.com/r/golang/comments/4lj0yn/congrats_brad_fitzpatrick/d3ots59 https://www.reddit.com/r/golang/comments/4lj0yn/congrats_bra... On the last link, click the downvoted comments, I deleted few comments, but yeah, that's about it, I got banned because I questioned the elites, it is called bullying! Later I spoke with that guy himself, turns out he wasn't being rude :-D
- superswordfish 10y ago> ignoring years of research and good ideas And people are falling over themselves to use Go in places that seem inappropriate. Most of Go's strengths shine in a large team of mediocre developers: Low build times, low abstraction, quick ramp-up, etc. So why do startups choose Go? You're just shooting yourself in the foot. Use OCaml, use C++, use Clojure, hell, use Swift or Rust, just use something that at least pretends to care about expressiveness and abstraction. I actively avoid working for shops that use Go heavily, it's an indicator of cargo-culting.
- biztos 10y ago> Most of Go's strengths shine in a large team of mediocre developers: Low build times, low abstraction, quick ramp-up, etc. I find some of those strengths and others shine in a small team of strong developers too, if they "get" Go. But to your point: some people expect their startups to eventually employ a large number of programmers, at which point they will inevitably have some mediocre ones, that being a side effect of "hiring only the best." Planning for that day is not shooting yourself in the foot.
- nutheracc 10y agoYou've hit the nail on the head for me at my current place of work. The only alternative I have here is Scala, which I wouldn't choose, but higher quality ecosystem and community, and closer to Rust which I'm enjoying at home, so am thinking of doing the switch.
- runT1ME 10y agoI cannot imagine a scenario where Go would be a better fit for a team of skilled engineers (compared to scala). Maybe ramp up time would be the only thing, but even still the dividends you can reap from scala's more complex abstraction are worth the initial investment as they are applicable to multiple projects (as opposed to learning a complex framework or whatnot).
- jsmith0295 10y agoI think it really depends on what kind of software you're writing. At my startup (around 30 engineers) most of what we do is web based, and our backends are mostly written with Java and Spring Boot now. Go is simpler, more productive, has better concurrency, and still has good static analysis. The benefits mostly seem to come from the removal of bullshit rather than the addition of nice abstractions.
- vertex-four 10y agoI think that a lot of people who like Go for its channels/coroutines would like one of the BEAM VM languages - Erlang or Elixir - with its OTP. It's a bit more heavyweight, and the community is a bit smaller than Go's, but it works nicely for lots of sorts of problems. I'd keep using Go for one-off scripts (grab SSH keys from LDAP for sshd, that sort of thing) and system integration stuff, though.
- clessg 10y ago> the community is a bit smaller than Go's For now! Phoenix [0] will hopefully help turn the tide. I switched from Go to Elixir/Phoenix a year ago and I couldn't be happier. I've used a lot of web frameworks over my decade as an engineer, and Phoenix is the first one that has remained fun to use, fast (!), and productive. Crucially, its community has remained accepting and helpful under Jose's leadership - in contrast to the unfixably toxic Go community. [0] http://www.phoenixframework.org/ http://www.phoenixframework.org/
- themihai 10y agowhat about the lack of static typing?
- vertex-four 10y agoElixir and Erlang both actually have static typing in the style of Facebook's Flow - type annotations can be added to your functions[0] and there's a tool, Dialyzer[1], which can be run via Mix[2] to type-check your programs. It's not perfect - among other things, it can't type-check certain things that can and do happen in Erlang/Elixir programs, and won't complain about some errors - but it's better than being purely dynamic at not a whole lot more effort. [0] http://elixir-lang.org/getting-started/typespecs-and-behaviours.html http://elixir-lang.org/getting-started/typespecs-and-behavio... [1] http://erlang.org/doc/apps/dialyzer/dialyzer_chapter.html http://erlang.org/doc/apps/dialyzer/dialyzer_chapter.html [2] https://github.com/jeremyjh/dialyxir https://github.com/jeremyjh/dialyxir
- themihai 10y agoDo you find using pub/extern keywords more elegant than a simple capitalization? To me rust is verbose in many cases like java with a lot keywords heading towards C++ complexity which is exactly what Go tries to avoid. I understand that now crago becomes somehow part of the language as the extern declarations will become "optional"/deprecated. So yeah, I hope Go won't adopt any of these fancy/XXI century features.
- dpc_pw 10y agoLet me see... instead of having to capitalize every single usage of a given symbol, I can just prefix it's defintion once with `pub`? Yeap, I rather do that. Instead of replacing all instances to lower case, I can just remove the `pub`. It's obviously better. Rust is noisy in other parts, for other reasons (trying to explain to compiler how to write super fast and data-race free code). But visibility qualifiers are not a problem. `extern` is only for importing crates, which is like 10 lines at in whole package/crate. Irrelevant.
- garfij 10y agoJust for contrast, when I'm exporting something in Go, using gorename makes it very easy to fix all the references within the package. It works the same when I'm un-exporting something as well. However, when un-exporting I have to go though all other packages that use that identifier and fix the code that used it. Presumably you need to do something similar when you remove the `pub` (i.e. It's not just a simple removing of the pub unless nothing used it to begin with). Ultimately in the end, for this example it really seems like the same amount of work. You add one word, I run one command.
- tatterdemalion 10y ago> I understand that now crago becomes somehow part of the language as the extern declarations will become "optional"/deprecated. You are incorrect on multiple fronts - 1) there is not even an active proposal to this effect, its just an idea that was passed around and not even really discussed, 2) the idea did not involve making rustc depend on cargo at all. It would be shocking to me for the Rust community to ever accept a proposal which required rustc to depend on cargo. In general, please try to avoid contributing to the spread of misinformation by not stating as facts things you are not very confident are true.