Tell HN: Ask Golang is my vacation project
askgolang.com
askgolang.com
(aside: how is GoF "high-level/architecture/design"? it is just a collection of tricks for overcoming language inexpressiveness)
Referring to it as 'a set of tricks' would suggest to me that you've only given it a cursory glance and assumed that it's just about copying out example blocks of code, or that you've not worked in a wide enough set of languages to realize that every language has commonly used patterns for doing particular things, no matter how expressive the language is. Having a way to discuss the architecture of a piece of software without having to explain every implementation detail because there's already a shorthand refer to various parts of it is invaluable when working on larger projects. Being able to call a block of code as a flywheel is no more a trick than being able to refer to an options pricing equation as a 'modified black-scholes' - the important part is that other person knows from that what you're talking about and so you can get to the important part of the conversation.
I think it philosphically comes in part from that place, but the particular choice of constructs it addresses are a a commonly needed set that a particular language family's lack of expressiveness in certain dimensions required to be reimplemented using basically boilerplate code each time they were used, so it spends a lot of time documenting the set of tricks necessary to implement those constructs in that language family.
> you've not worked in a wide enough set of languages to realize that every language has commonly used patterns for doing particular things, no matter how expressive the language is
The more expressive a language is, the more the "commonly used patterns" can be turned into libraries rather than templates you have to apply with substitution each time you want to use them, and the less need there is for a book documenting the justification with sample code, as you just need the actual implementing code with documentation as to its interface.
OTOH, presentationally, its possible to document constructs is a pattern language for software without as much attention to implementation in a particular language as GoF provides. GoF particular choice of constructs and its choice of how to present them, I think, are very much shaped by desire to serve as an implementation cookbook -- a set of tricks -- for a particularly industrially-popular programming language family as well as providing a common pattern language for software constructs that transcends particular programming language choices (and its success and popularity are in no small part due to its utility as a set of tricks.)
Hardly. The Go philosophy is "our language is designed to not need such architecture-astronauts' high-brow fanciness". Other than that, whatever architecture/design patterns you're used to should mostly carry-over to Go.
Maybe it wasn't exactly relaxing, but it has been fun!
> this is how people get burned out...
This is how I re-energize when taking a break from medicine :-)
Thanks for sharing, BTW!
> There's nothing wrong with providing getters and setters yourself, and it's often appropriate to do so, but it's neither idiomatic nor necessary to put Get into the getter's name.
Since I view "is/has" as derivatives of "get", I opted to omit the "is" from Guest(). But I'm open to hearing other opinions.
There is probably plenty that is un-idiomatic all over this code and one of the reasons I put it out there is to get feedback.
return u.Id == 0
Load average is negligible despite the HN load:
Load average: 0.04 0.06 0.06
I don't know about the architecture of Heroku, GAE, or AWS w/ ELB in terms of supporting the HTTP 1.1 Upgrade request to websockets. Perhaps they all use a reverse proxy that doesn't pass along the Upgrade request? Even nginx didn't support this before ~1.3.13.
can you please try some variations in type size and weight? this would go a long way for legibility between questions, answers, comments, meta info like "submitted at", etc.