101–110 of 187 posts
Great article. However, I would not assume that us (good programmers) vs them (bad ones) is how the go folks see the world. If a couple decades of programming have taught me anything, it's that "them" is usually "me" or "past me" or "500 of us".
In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers,…
"Opinionated" frameworks/tools/languages are becoming pretty common these says. I would say programmers are becoming quite fond of authors who just make some damned decisions.
Earlier quoted context omitted.
Goto's create unreadable code and are unnecessary. They're there to encourage the writing of bad code. You can pass a pointer over a goroutine channel. That's my main issue with them, beside the fact that we should be past this needless complication of our code. Again, they're unnecessary and encourage bad code.
Goto's are used extensively in the Linux kernel for clean exits from functions (typically system calls) that must validate parameters, allocating resources as they go, but then abort if there are any errors in the parameters. For example: http://lxr.free-electrons.com/source/kernel/fork.c?v=3.3#L42...
Earlier quoted context omitted.
> To me, the core Go authors are more of engineers than artists I thought the same thing. They are like the anti-Larry Wall.
I guess that makes Go the inverse of Perl. I assume if a Perl programmer shakes hands with a Go programmer, they cancel each other out.
Note: Said without any bias towards either Go or Perl.
Also, I'm not a language lawyer, and this was a joke, so I'm not replying to any comments about Go not being "purely" or "strictly" strongly typed or whatever.
In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers,…
Personally, I think people dislike Go because they try using it for tasks where it makes their life miserable. Mainly for web programming. (unless of course you're a masochist and enjoy not having a repl and want static typing and a compilation step when recursively parsing unknown json data structures). In my experience, Go is a tool thats really good for a certain set of programming tasks and like all other languag…
I am currently using the massive PHP + Node.js ecosystem for most of the application and Go for the critical communication parts.
Earlier quoted context omitted.
> Go makes coordinating with them a lot easier. What I like about strongly opinionated languages in general is that most of the strong opinions are around trivial features of the languages relative to the complexity of a decently interesting programming problem. Features like formatting, no unused imports, etc. These are typically areas in a project where Parkinson's Law of Triviality rears its ugly head in project p…
I agree with a lot of these (and would be interested in adopting a language that followed them - but one with a decent type system), but I don't think that's the Go innovation. Python had opinions about whitespace and never attracted the same level of hate.
edit
More to your point, though. I would never choose a language for a project because it is strongly opinionated on such things. However, when choices lead to an opinionated language I find the feature a positive rather than negative edition....even if I find a particular decision annoying at first.
Earlier quoted context omitted.
Go is developed inside Google where all dependencies are checked into their global version control repository. There are literally no versions inside the Google codebase - everything is compiled at head. If you want to upgrade a third party library then you are expected to globally upgrade every user of it .... simply bumping the version of a widely used library can thus turn into a multi-month promotion worthy proje…
> If you want to upgrade a third party library then you are expected to globally upgrade every user of it .... simply bumping the version of a widely used library can thus turn into a multi-month promotion worthy project! The alternative is of course supporting dozens or hundreds of copies of a library and every possible commit hash of said library. I contracted at a python shop that had 81 versions of a single libra…
"One version per org" means "upgrades are harder, but patches are easier and you don't need to deal with different quirks of different versions at the same time and you don't get problems using 2 components that need 2 different versions of some other thing in one process etc."
"Latest version, always" means you have no way to even build the latest version of your thing that was tested and is known to compile and work. Kinda sucks, I think.
Earlier quoted context omitted.
Personally, I think people dislike Go because they try using it for tasks where it makes their life miserable. Mainly for web programming. (unless of course you're a masochist and enjoy not having a repl and want static typing and a compilation step when recursively parsing unknown json data structures). In my experience, Go is a tool thats really good for a certain set of programming tasks and like all other languag…
"Web Applications" are often made up of parts now. So while php/ruby/python are faster to develop for most things - writing the websocket handler or AJAX polling API in Go makes a LOT more sense given the performance of these crucial parts of the application. I am currently using the massive PHP + Node.js ecosystem for most of the application and Go for the critical communication parts.
My current company's web API is built using Django, which may come as a surprise since we also do realtime stuff, but that's the benefit of mixing the best tools for each job.
Earlier quoted context omitted.
I don't even get the vitriol against generics - the designers have only taken a "not now" approach to the subject and everyone acts as if Go is a social experiment to get everyone mad about generics. Then people bring Rust, which has only had a stable grammar for last couple months and a standard library nowhere near Gos. Would it be wise to complain that the Rust stdlib doesn't contain a HTTP server implementation?
It's not just the "not now" approach. It's the rhetoric that often goes along with it. The author of this piece picks up on it when he talks about the "we've already thought about this and we're tired of talking about it" vibe, though I might characterize a lot of the discussion around generics from the Go community at large more specifically as "you think you want/need this, but trust us, you don't, and the inconven…
It's pretty easy. You just add this line to your Cargo.toml:
hyper = "0.3.14"
This is one reason we've chosen minimalism for the standard library: It's really easy to use external libraries, and once things land in the standard library, they often don't improve much. The versions become tied to the compiler versions, contributors now need to build the entire compiler rather than just working on a single library, and everything else. We've already seen three distinct major HTTP implementations happen, had we put rust-http right in the standard library, we'd have frozen something the author has already deprecated!
Choosing non-minimalism has advantages too: in this scenario, you need to know that hyper is currently the best library, for example. Engineering is all about trade-offs.
(Solely chiming in on the HTTP in Rust thing here. I found the part of the article about the Gopher... lacking, and it distracted me from the rest of the author's points.)
I thought the same, so I built a stats library[1] of my own. It also only works on float64's at the moment.