From what I've seen though, most of these projects are executable applications, often with a small code base and written by at most a handful of people. I don't think this is the type of code that really benefits from generics.
As a Scala developer I heavily use generics, but generally only when writing libraries. Application code, code that becomes the final executable and isn't mean to be reused, is usually very light on generics and many other fancier aspects of the type system. Perhaps it goes without saying, but it's only when writing generic code do generics really become important.
To me, Go seems good for one-off projects like this. The code is straightforward and it's small enough that it's not a big deal to hand-write functions that could have been generic. But for large projects or for writing highly reusable code, Go seems really unfit for the job, and I think it's those kinds of projects people have in mind when they criticize Go for not having more powerful features like generics.
As far as I can tell, the JVM GC is (not surprisingly) significantly more mature. The JVM has a concurrent mark-sweep algorithm that works similarly to what's described in this document, but more importantly IMO the JVM's GC is generational, and it appears Go's GC is not.
In the JVM, the CMS only occurs on the oldest generation which contains objects that were in use for a while, whereas objects that are created and discarded quickly are cleaned up in younger generations with a copying collector, which avoids memory compaction by switching back and forth between 2 equally sized memory blocks. This means much of the time the JVM can avoid doing a full CMS and keep the time spent in GC only a few ms per second.
I guess it depends on what your use case is. If you're writing low-latency server applications that don't have loads of long-lived internal state and you have memory to spare, the JVM's CMS GC is going to be way more efficient than Go's. But if you're constrained for memory then avoiding copying collectors and generational heaps is your best bet, but you'll pay for it in GC time. Of course the JVM has other GC algorithms like G1, but I don't have much experience with those.
A few weeks ago I started playing with some AVR (arduino) chips and a box of electronics parts, and it's been way more fun than I thought it would be. There's a certain satisfaction of actually building something tangible that is missing in my professional high-level coding, for example flipping a bit in a register and watching an led turn on or a motor start turning. It's also fun to see what I can get out of 8KB of storage and 512 bytes of RAM, something I'm not used to with the 96GB servers I normally write code for. I've also learned a ton about digital and analog electronics.
If you have any programming experience (which on this site you more than likely do), you can get up and running with an Arduino starter kit in like 10 minutes. It has a very active community and there's tons of articles covering all the basics.
Crickets are one of the worst insects to breed. It's hard to keep a stable colony, they smell awful, make noise, and constantly jump out and escape.
I breed Guyana roaches to feed my pet tarantulas. They are hardy and easy to breed, plus they don't smell or make noise and they can't climb walls. They give live birth and don't infest homes. I keep them in a large storage bin with a screen lid filled with egg crates, and feed them fresh fruit and dry cat food once a week. I live in a small apartment and guests don't even know they're there unless I point them out.
This is already happening. Litecoin is now trading at about $4 per LTC. It is slightly different in that average block generation occurs every 2.5 minutes instead of 10 and the limit is 84M coins, but otherwise it's basically the same idea as Bitcoin.
There are numerous others -- TRC, PPC, NMC, DVC, etc -- that all are slightly different from bitcoin and are actively trading, although their exchange rates are much lower and extremely volatile. Namecoin is actually pretty interesting (embedding a domain service in the protocol), but the others are mostly copycats.
This is exactly what watching The Hobbit in HFR felt like to me. It was something of a cross between a play and a video game. There were some scene that felt more cinematic, but especially scenes without much camera movement felt like watching actors on a set.
Like the author, this pretty much ruined the movie for me, but I'm not prepared to totally write off HFR. I think directors will just need to learn how to properly adjust filming techniques to keep HFR feeling like a movie, similarly to how they had to learn to incorporate green screens without having an obvious separation between the actors and the CGI (which a lot of directors still get wrong).
How could you possibly claim his post was sexist? There is literally nothing about what he said that is even remotely sexist.
Perhaps he's pinning the blame on Mayer because the announcement was written and signed by her! It's the role of the CEO to represent his or her company in this manner and serve as the lightning rod for any feedback. The fact that Mayer is a woman is completely irrelevant. Both Jobs and Gates (and many other male and female CEO's) took on that role, and there is absolutely no shortage of rants and raves over the years directly addressed at them.
In fact, I would say that you are the one being sexist, since you are apparently accusing jpdoctor of sexism based solely on the gender of Yahoo's CEO.
I'm just reading the series for the first time, and the time jumps in the first book really threw me off too. However you should be aware that it mostly stops after the first book. The second book (Foundation and Empire) has two stories, but most of it focuses on the second one (The Mule), and the books after that are more like regular novels with no jumps.
For me the first book was by far the worst and I consider it more of a background filler than an actual story. I enjoyed the rest of the series far more, especially Foundation's Edge.
As a Scala developer I heavily use generics, but generally only when writing libraries. Application code, code that becomes the final executable and isn't mean to be reused, is usually very light on generics and many other fancier aspects of the type system. Perhaps it goes without saying, but it's only when writing generic code do generics really become important.
To me, Go seems good for one-off projects like this. The code is straightforward and it's small enough that it's not a big deal to hand-write functions that could have been generic. But for large projects or for writing highly reusable code, Go seems really unfit for the job, and I think it's those kinds of projects people have in mind when they criticize Go for not having more powerful features like generics.