ViktorasM

Not a security topic, but POST is not necessarily "create" and PUT is not necessarily "update".

What a clickbait title. I'd welcome "free speech restriction" that forbids misleading titlea.

Neat and simple implementation. Consider docstrings for describing methods, this tends to integrate with IDEs a lot better than comments.

That might be true in this context, but otherwise a rather flawed generalization:)

Not readable on a phone. How can any tech company afford this in 2016...

congratulations to the only comment in the whole comments section that mentions kids or children.

like always, there's an XKCD for that: http://xkcd.com/946/

..and like someone mentioned their 200$ food budget, try spending twice that amount on kindergarden a month that your kid is not attending for now because he's home sick and you're spending extra on treatment.

When you've exhausted your saving options, making more is still the best option for saving money:) Simple math, if you spend 3000/month of your favourite currency, then you'll have twice more money by earning 4000 vs 3500.

so frustrating when the answer is obvious but where to click is not.

e.g. in "if a.length != a.length" the "correct" token is the first "a". Should really be anything in the whole expression.

Ah, the days when I typed "begin" and "end" at the speed of puting a curly brace.

Don't actually feeling the need to go back though. It's not about language properties anymore, but the library ecosystem. I hated when anything useful in Delphi was a C dll port. You're never a first class citizen.

Stopped reading at "Place models, views and controllers in their own folders". No worse way to organize your code than classify by behavior type. "Here are all the daos", "here is all business logic", "here are all the controllers". You add a feature as small as resource CRUD and scatter it's pieces across the whole code base.

No.

but having all those things go would become another C++ with a different syntax.

I like the direction Go is going of "there are no options to choose", like unconfigurable fmt, or the fact that there is no way to create "exotic" implementations.

However, generics would be my number #1 on the list of "maybe let's add that". Would be nice to have less "interface {}" in reusable libraries.

Exceptions would be probably second, but that would come with some sort of runtime cost. With them Go would start to drift towards "generic programming language".