"one more tool to update status" in is not something I'd be looking towards in my team.
"What the team is currently working on" is an important question, but definitely to be covered by a functionality of a full-blown issue tracker. Because there's also questions "is this the right priority?", "what's next", "what's been done yesterday". You need more detailed info inside your team, while for the other team you probably need just a high-level overview of the whole team's goals.
I don't see how this could replace something like good old Jira scrum board.
I tried to click around the tool and it definitely feels unpolished. Rather, poor quality in general (message for password-too-short popped up in alert() with JSON in it).
..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.
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.
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".