Earlier quoted context omitted.
Rust's stdlib not containing a HTTP server is a deliberate act.
Go not including generics is a deliberate act.
A web server can easily be implemented as a library, generics are a language feature.
Four days of Go
111–120 of 187 posts
Re: Four days of Go
#112Earlier quoted context omitted.
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…
> I suspect will get resolved much more quickly and cleanly It's pretty easy. You just add this line to your Cargo.toml: hyper = "0.3.14" And the next time you build, Cargo handles everything. You can now use hyper like any other library that's included with Rust, no biggie. 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 sta…
> Engineering is all about trade-offs.
What a wonderful sentence about a simple, but often forgotten truth!
Re: Four days of Go
#113Go is not a perfect language, but I've been hard-pressed to find one and so I've stopped looking. Here's what I like about Go.
Go is crazy boring. You type things. You hit return. You type the next thing. Error not nil? Type more.
There's something very sequential, linear, methodical about it all. I suppose in part it's gofmt. It may also be a byproduct of any strongly typed language, but unlike many of those languages, Go feels simple and reasonable.
I actually think this is how programming serious applications should be. A little boring. Nothing too fancy or cute. No refactors to fit some new great abstraction pattern.
Not to wax nostalgic — in fact, I can't, because I wasn't even born — it reminds me of paper tape in old computers. The card gets punched, it feeds in, and the computer considers and executes your instructions. We're still doing that, really. Programming should be simpler. Sometimes I think we go out of our way to make it more complicated because we are experienced and bored. :)
Re: Four days of Go
#114Earlier quoted context omitted.
I think this is part of it, some of the hate comes from people that "know better" (possibly true for some, obviously the Go authors aren't omnipotent) than the Go language designers and are baffled that the language design ideas they know about aren't in the language. But I can tell you in my experience that this type of forceful "everything is a error, no warnings" and "it is done this way (formatting for instance)"…
> 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…
> features like formatting, no unused imports, etc.
I personally think these should be configurables turned on by default so you kind of push the new comer to write good code and build better habits but there should be an option to disable it, make it hard to find but it should be there, especially for the people like OP and other small over-the-weekend projects.
Re: Four days of Go
#115Earlier quoted context omitted.
> unless of course you're a masochist and ... want static typing Some people say to prototype in a dynamically-typed language and then switch to a static language later. Dynamic typing might save keystrokes, but typecasting and type-checking do require lots of typing, and who cares that much about a few hundred extra keystrokes anyway? Some people say to create whole, large apps in dynamically-typed languages, but th…
I think you left off the key part of his point, namely "when recursively parsing unknown json data structures". json parsing in Go uses reflection, which not only means it is slow, but if your input is not consistent (like say.. a log file with 20 different possible formats), it can be quite painful and very verbose.
If only the language had algebraic data types.
Re: Four days of Go
#116I must said, I've never heard of this guy, I think I have a new favorite blogger now.
That's because Evan usually write about Erlang. I love his article on Erlang.
Re: Four days of Go
#117Earlier 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…
> features like formatting, no unused imports, etc. I personally think these should be configurables turned on by default so you kind of push the new comer to write good code and build better habits but there should be an option to disable it, make it hard to find but it should be there, especially for the people like OP and other small over-the-weekend projects.
The goimports tool can be used to automagically add and remove imports to your .go source files as you work. This streamlines the casual weekend hacking use case without compromising on the benefits of disallowing unused imports.
Re: Four days of Go
#118That was quite fun to read. The point about Go being too pedantic and thus hindering exploration is something I've felt too. Some of that pain was mitigated by the Sublime Text Go plugin that has shortcuts to add/remove imports.
This is generally a tradeoff you have to make in programming language design. Should the checker enforce good code or should it let all but the most broken code through in the name of exploratory programming? I would recommend using Python or possibly Clojure to experiment with and then translate the code to a language that will help you catch bugs (Ada/a functional one) when you know exactly how the problem is solve…
Maybe there could be an --experimentation-mode compiler flag that would be less strict.
Re: Four days of Go
#119> If I had to guess, I’d say the Go gopher suffers from a mild form of autism. > I get the same feeling about the Go language. It feels like it is designed by an obsessive personality — obsessed with build times in particular, but also having an obsession with detail, someone who rarely makes mistakes when writing code, who generally will not run code until it appears to be complete and correct. WTF? Not only is it i…
As a high school teacher, I work with kids on the autism spectrum all the time, and I don't find his comments offensive. They seem relatively accurate, too.
Re: Four days of Go
#120> If I had to guess, I’d say the Go gopher suffers from a mild form of autism. > I get the same feeling about the Go language. It feels like it is designed by an obsessive personality — obsessed with build times in particular, but also having an obsession with detail, someone who rarely makes mistakes when writing code, who generally will not run code until it appears to be complete and correct. WTF? Not only is it i…
He need to try run Rust code :)