Hacker Newsnew | past | comments | ask | show | jobs | submit | sad's commentslogin

And just over there in the ocean is his ship, Loki.


I created a sample app using Puma and Celluloid to work through similar troubles I was having with Sinatra's streams and Puma. If it helps, it's here: https://github.com/sdeming/cellfun. This does not use EventMachine, depending instead on Celluloid. I work primarily in JRuby and EventMachine has always tripped me up.


These are fun.

In C++, make the compiler do your recursion:

  #include <iostream>

  template <int N>
  void pr(const std::string &msg)
  {
      std::cout << msg << std::endl;
      pr<N-1>(msg);
  }

  template <>
  void pr<0>(const std::string &msg)
  {
  }

  int main(int argc, char *argv[])
  {
      pr<100>("Hello World");
      return 0;
  }


It is threadsafe in jruby (as of 1.6.6)[1]. It is a decent feature, and it would be great if matz would reconsider.

[1] http://jira.codehaus.org/browse/JRUBY-3194


2/29 is a good date. 3/14 would have been much more in tune with the Raspberry Pi name.


That would be pretty damn cool.

If it weren't for the army of geeks with internet pitchforks :-)


I'll go out a limb here. It seems like it was too easy and too valuable. Smells like a Trojan Horse. Who knows what Iran will be getting themselves into when they move the thing to some "secure" location. Oh, I do likes a good conspiracy...


As interesting as that possibility might sound, I am reminded of Hanlon's Razor: "Never attribute to malice that which is adequately explained by stupidity."

A drone with improper (or beaten) failsafes and countermeasures seems far more likely than a planted trojan.

And if modern history -- especially 21st century modern history -- is any guide, we can bet on two things: 1) The US's overestimation of its own technological advantages; 2) The US's underestimation of its enemies' technological capabilities.


> 1) The US's overestimation of its own technological advantages; 2) The US's underestimation of its enemies' technological capabilities.

Doesn't the cold war disprove both of those points?

The United States dramatically overestimated the USSR's military capabilities. For example, there may not have been any real "Missile Gap" http://www.thecrimson.com/article/2011/9/27/gap-missile-cia-...

I can't find a link at the moment, but the CIA grossly overestimated Russia's long-range bomber fleet from what it saw during a military parade - it turns out the Soviets had the same aircraft fly the parade route in a continuous loop.

Perhaps the real problem is our Military will often overestimate what technology is capable of, and is blind to some of its downsides.


We've massively underestimated China on a consistent basis -- and, while it's true that they are probably running similar Potemkin-village-style games as the Russians played in the Cold War, some of their technological leaps are well established. Especially in the domains of cyber warfare, ballistics, and supercomputing.

We've underestimated Iran, Hezbollah, insurgent forces, etc., pretty routinely -- in terms of their technological capabilities, adaptability, and organizational sophistication.

I do agree with you, though, that we tend to overestimate what technology is capable of. I'd expand that point, however, and say that we overestimate what big, expensive hardware is capable of. And we underestimate low-tech, low-cost, jury-rigged, creative uses of technology.

Additionally, we tend to underestimate the diffusion -- be it through theft, connectivity, sale, espionage, or what have you -- of cutting edge technological know-how in today's world.


Don't be sad. Competition and innovation are good things. XMPP and IRC aren't perfect solutions. I haven't seen this app in action so I can't comment on the "doing it poorly" part, but can you elaborate on that? What is poor about the implementation?


Indeed, if you haven't tried it yet then you absolutely should. I highly recommend Just Cause 2, it's a huge game and it plays perfectly. You can play any game for 30 minutes without spending a penny.

Disclaimer: I wish I was an investor.


YES. I'm actually really sad that I'm unable to invest money in the huge expansion that's happening in the software industry right now. Due to Sarbanes-Oxley, this entire industrial development is completely off-limits to regular Joe investors. It sucks to be aware of this and not be able to do anything about it.

There are many reasons why this is bad, first and foremost that this is where a lot of the action is right now and those of us with less than 10 million available to invest are stuck investing in only the rest of the economy. Which, from what I gather from the news, is pretty mismanaged in the US.

After trying out OnLive for 5 minutes even without playing, it is obvious that this is the future for most gamers.


Thirded. If I could put money in any company today, it'd be OnLive.


Isn't GC pause good enough reason for anything of this kind? I'm perhaps not up to date in the latest JVM GC performance profiles, but if shaving even a few usec is important then I'd think avoiding it altogether is paramount.


If I were programming something like this in C++, I would preallocate as much memory as needed and reuse that in memory pools. I would do this for managing the memory (preventing memory leaks, making sure my program doesn't crash when memory runs out etc) and for performance (same sized items allocated from simple block pools, temporary "stacks" of objects which can be cleared by simply resetting the stack pointer etc). Following this logic, I don't see why I wouldn't do something similar in Java, so the garbage collector would only need to collect temporary objects as most would stay in memory and be reused. This should eliminate the bulk of unacceptible GC pauses.

Having said that, as far as I know (I haven't worked in Java in about a year and a half, so I don't know how this is now), garbage collection is pretty fast nowadays. It may also be possible to speed up if using something like Excelsior JET, though I've never used it, so may be wrong on that.

I'd personally be interested in looking at using a C++/LuaJIT hybrid for something like this though - the bulk of the code would be in Lua with common tasks that require very high performance and don't need to be too dynamic being done in C++.


I agree, avoiding GC is paramount. You can do this in Java by discarding less objects. http://vanillajava.blogspot.com/2011/06/how-to-avoid-garbage...


I'd say forward for sure. This breaks down the barriers to entry for a lot of folks, especially in enterprise land. Definitely looking forward to how this develops.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: