My Go Resolutions for 2017
<p><pre><code>    > Part of the intended contract for error reporting in Go
    > is that functions include relevant available context,
    > including the operation being attempted (such as the
    > function name and its arguments).
</code></pre>
I know the Go folks don't like exceptions, but this is an example of them learning the hard way that about one useful thing they lost by deciding to not do exceptions.<p>Exceptions give you stack traces automatically. All of that context (and more) is there without library authors having to manually weave it in at every level of calls.<p><pre><code>    > Today, there are newer attempts to learn from as well,
    > including Dart, Midori, Rust, and Swift.
</code></pre>
For what it's worth, we are making significant changes to Dart's generics story and type system in general [1]. We added generic methods, which probably should have been there the entire time.<p>Generics are still always covariant, which has some plusses but also some real minuses. It's not clear if the current behavior is sufficient.<p>Our ahead-of-time compilation story for generics is still not fully proven either. We don't do any specialization, so we may be sacrificing more performance than we'd like, though we don't have a lot of benchmark numbers yet to measure it. This also interacts with a lot of other language features in deep ways, like nullability, whether primitive types are objects, how lists are implemented, etc.<p>[1]: <a href="https://github.com/dart-lang/dev_compiler/blob/master/STRONG_MODE.md" rel="nofollow">https://github.com/dart-lang/dev_compiler/blob/master/STRONG...</a>