In my experience, almost all overhead in Go programs will result from being bitten by memmove, alloc and GC. Profiling any program that uses interface{} and byte buffers will quickly expose you to how much the runtime loves to reallocate and copy objects. In one instance I got 10x throughput improvement by switching from a generic interface (take an interface{} and detect the type) to using typed methods and hand-rolling a shim that called the appropriate methods.
Do people actually use `interface{}` so liberally? I've never encountered it in the wild (except by newbies or as an example of what not to do) and I've always been under the impression that it's been heavily discouraged for a very long time.
interface{} is heavily used in many of the Go std libraries. Particularly for what I call "convenience methods" where you want to be able to pass in various types and it will do a type switch for you and then determine what to do.
Part of what I was discovering in this blog post is that if you look under the hood at these convenience methods, and you know in advance what type are passing (i.e., you are not using interface{}), you can often find the "direct" call to use that uses a concrete type and likely get better performance out of it.
Seriously, MS doesn't do everything great, but Powershell has typed pipes (typed everything, actually, it's not just stringly like *sh) which are seriously awesome.
French in Quebec is kind of similar - to avoid being assimilated into English Canadian culture, it's very resistant to change. French speakers from Europe tend to find it kind of quaint because it's been developing independently since the 1700s.
I'm pretty sure this is a rephrasing of a much older, well known principle in psychology (they cover it in undergrad), that work satisfaction is a function of: autonomy, feedback and variety.
In other words: people want to control how they do work, and feel they have some flexibility. They want to recieve prompt feedback so they understand when they're doing well or badly. And they want to encounter a variety of challenges.
Gamification is just building a tight feedback loop and providing sufficient variety. Autonomy is much harder to automate, because it seems to be the opposite of building an 'on-rails' experience guaranteed to please someone.
At least for the running example, running marathons is extreme. A lot of people run 6-10 mile distances, precisely because it doesn't take over your life. You might be surprised at how many people you know run and don't talk about it ;)
More broadly, I think you're falling into the trap of assuming the loudest/most prominent people represent the average. Just like there are a lot of people who run and also do other things, there are lots of people who are quietly religious.
I don't even get where being fat comes into this? There are a lot of factors that go into Americans being fatter on average than Europeans, but your list devolved into the typical one-dimensional "I hate North Americans because I moved to Europe and I'm so continental now" rant.
> Aim to be more well-rounded
Good advice for everyone, regardless of where they live.
All major corporate open source projects have a contributor license agreement (CLA) which contributors must sign. Regardless of whether they intend to close the source in the future or not. See the VLC license change fiasco for why CLAs are very good: http://www.jbkempf.com/blog/post/2012/How-to-properly-relice...
Catching unused variables is pretty essential, it's easy to shoot yourself in the foot by redeclaring a variable with := inside a block.
>> which means you have to need separate storage for the actual RaceCar and GetawayCar values, either on the stack with a temporary variable or on the heap with calls to new
Maybe I miss his point here, but in Go it's totally valid to just create a new *GetawayCar with &GetawayCar{} in any scope. You can return that pointer from your current method. It's not necessary to explicitly put your GetawayCar on the heap with new(), Go will decide for you with escape analysis.
Just to clarify, in your view women: don't work, can't be engineers, always want to be in a relationship, and are terribly unfaithful and will leave you for somebody with more money? Also, maybe stop calling adult women "girls".
There's a big difference, calling someone "boy" or "girl" instead of "man" or "woman" is demeaning. How often do you honestly refer to male engineers as "boys"?
> don't care enough to pay attention
Surprisingly, it doesn't matter how much you care.
> If Leap schedules things correctly, in part because they are a private company and have incentive to do so
I don't know what you think the TTC does all day, but it's not sit around and say "if only we had competition, we'd make the busses better". It may not be possible to schedule to avoid busses bunching up during peak times, if that's how traffic behaves. The only way to fix it might be to run an excess of under-utilized busses, which cuts into profit margins. Which is something a private company with higher rates might be able to do, but the TTC is limited because service has to be accessible to everyone.
The risk of a private company like this showing up is that it'll decide to focus intensively on the 20% of routes that yield 80% of profit. This bleeds the public transit service of funds needed to run less profitable services at off times that are used by people without 9-5 jobs, or people in less privileged areas. So the rich get better bus service, and no longer subsidize the service for the poor.
