Power is a measure of... power, not energy. MW/year is a silly unit. In the US energy production on an annual basis is given in BTUs, or Joules (usually quadrillions of BTUs, depending on the scale). Perhaps the article meant 10.7 GW of installed production capacity. Regardless, that's about 0.3 quadrillion BTUs per year, which is a blip compared to the world's energy consumption.
> Perhaps the article meant 10.7 GW of installed production capacity.
The original report does indeed, the article misquoted (and possibly misunderstood) it. Here is the exact quote and its surrounding paragraph:
> In 2005, there were 8,933 MW of installed power capacity in 24 countries, generating 55,709 GWh per year of green power, according to the International Geothermal Association. IGA reports in 2010 that 10,715 MW is on line generating 67,246 GWh. This represents a 20% increase in geothermal power on line between 2005 and 2010. IGA projects this will grow to 18,500 MW by 2015, which based upon the large number of projects under consideration appears reasonable if not conservative.
> Regardless, that's about 0.3 quadrillion BTUs per year, which is a blip compared to the world's energy consumption.
note that the quote is about electricity generation, not power consumption in general.
Still a blip though, in 2008 global electricity generation was estimated at 20261 TWh, geothermal production thus accounting for ~0.3% of global production.
A few select countries have fairly high geo ratios though: Iceland's at 30% geothermal, the Philippines at 27%, El Salvador 25%, Costa Rica at 14% and Kenya at 11.2% (2010 numbers).
The US are the biggest producer of geothermal electricity (29% of global production, #2 is the philippines at 18%) but the ratio matches global, geothermal is 0.3% of the US's electricity production.
ATS is meant to be a general purpose programming language. The fact that you have a theorem proving subsystem is to aid in the programming/verification. Idris is another dependently typed prog. lang. that is intended for general purpose programming.
"Can't imagine/understand" is a figure of speech, not literal statement to be taken by its exact meaning.
Personally, I can imagine how someone could live without $conceptname at all. It's as trivial as just never introducing that concept to to the extent they learn it. Or, maybe, that someone knows the concept but unable to use it due to insuperable force, like a lack of necessary tools for target platform(s) or corporate standard dictating what's permitted and what's not.
The point is, this is an unpleasant imagination one don't want to accept. Or something like that. But this is really getting off-topic...
I'm fully aware that it's a figure of speech. I'm calling out the hyperbole because it doesn't enlighten, and lacks self-reflection.
A much more useful comment would have been to describe how crucial $concept is to his programming practice, and how he tried working without $concept but found it a dreadful experience because of $x, $y and $z.
>A much more useful comment would have been to describe how crucial $concept is to his programming practice, and how he tried working without $concept but found it a dreadful experience because of $x, $y and $z.
Why, does anyone needs convincing of how useful Generics are?
Thanks for the feedback, I was being quite dismissive. In this case, at least to me, it seems quite clear that parametric polymorphism would be a win - that the addition of parametric polymorphism would allow the library to be expressed and used in a more eloquent manner.
The purpose of my comment was to draw attention to this.
Are you referring to the ping/pong message frames in the WebSocket transport protocol, or just a general heartbeating protocol layered on top of WebSockets?
The latter requires a custom protocol built on top of the user's WebSocket messages. This would require additional code on the server to process the messages. Libraries would have to be created for the various server side WebSocket implementations. It's a much messier abstraction, and I'd prefer this library to stick to one thing and do it well.
> no mention of what happens to messages in
> transit when the connection drops
In this regard it behaves exactly like a regular WebSocket connection - the message is lost. All this library care of is ensuring that a new connection is opened.