Or, like one of the companies I worked for, you could exercise your options, wait for a large Fortune 500 to buy them up, but then get told that your bylaws have a special provision that if the sale doesn't clear a certain amount, everyone's common shares are liquidated.
As in we got zero. Nothing. And this software is still in use in a major product.
So no, please don't trust options or exercised shares at any private company to be worth anything.
You want to get paid? Negotiate salary and laugh in their faces when they offer you options.
Everyone wants to believe it won't happen to them and that their company must be special since they work there. But sadly this happens to brilliant people all the time.
Cash is king. Realize you don't understand finance much less finance in an opaque, illiquid company.
Say it 3 times: "Cash. Is. King.".
Max out your 401K and negotiate a company 100% match if you can. Start a private investment account and a savings account and distribute to them every check. Keep doing this. Maximize all this before you become Johnny Wall St. with your illiquid stock options. They're as useful as a penny stock as not as liquid.
Buy some of them if things look bright but classify the investment as your "highly speculative" class of investments and thus ensure they are a small part of your portfolio.
I have considered it deeply. Many of our enterprise systems are Java-based, so JRuby's ability to call Java methods directly without implanting services would be a huge pragmatic boon. But every time I consider that I have to balance it against being able to use a constellation of gems in Rails. For example, nokogiri (libxml) is used in a ton of stuff. Sure there are Java equivalents, but that isn't the issue. Rather I would have to reimplement or find replacements for everything we use that depends on that without introducing side-effects. In my experience that's really hard unless it's a toy application without many dependencies. (Read: opposite of most enterprise Ruby apps)
Also, as a gem author I've tried to support jruby along with MRI, but it requires jumping through a lot more hoops. Of course any cross-platform code requires more work to support, but it's a pressure on small devs. If no one needs it, no one helps support it, so then it becomes another gem that is effectively MRI-only. Kind of a viscous cycle.
Rubygems forms an ecosystem of libraries on top of Ruby. Most gems are dev/tested within MRI, some work across other Rubies, some do not. It's difficult to tell which is which. This means most teams choose MRI in much the same way that most Ruby teams choose some form of unix -- compatibility.
Ruby also suffers from the lack of a formal VM, so other implementations are merely similar rather than being guaranteed to run all programs. This is not the same with JVM vendors, where choice of IBM vs Oracle is largely based on extrinsic features rather than intrinsic compatibility. (Or at least you have to get in really deep to find differences-- in Rails you usually find incompatibilities that stop you from even starting the app).
The Ruby community is always likely to prefer MRI because that's the core that the majority of gems support.
So, yes, on the surface of it, this particular Ruby build might appeal to people looking for performance.
But from a language research position it is interesting to decouple concepts like GC from the language so that they can be studied and optimized as a pattern and then be potentially reapplied to any language runtime.
I agree that some concepts might be pulled into MRI Ruby 3, but OMR may be a powerful testbed for language researchers to debate GC strategies and measure effects in various languages before committing to a single language integration.
Thanks! That's definitely the exact hope we have for OMR as well.
Similarly, improvements in OMR can be shared among all languages using it; ie, because we build both IBM's Java JDK and Ruby on top of OMR, Ruby can benefit from investment in Java, and Java can benefit from improvements in the Ruby community.
> The Ruby community is always likely to prefer MRI because that's the core that the majority of gems support.
It may be worth rembering that today's (1.9 and later) "MRI" started life as an alternative to MRI called "YARV". For a while there was a lot of talk about Rubinius as potentially being the basis of a similar replacement and becoming the "MRI" of the future. While there is less talk recently about Rubinius in that role, its absolutely not impossible that a competing core engine could be adopted as the mainline implementation of Ruby again.
1. It is mostly compatible with Gems.
2. It is faster and accepted by the Core Team.
3. Most importantly, license. Both MRI and YARV, the two CRuby implmentation are all MIT. It is highly unlikely JRuby or OMR could be used as mainline.
Is the Open really open, as in acceptable license that won't hold it back from gaining adoption in OSS and Enterprise community - or - are there licensing, patents or other proprietary strings attached?
Consider part of the reason work takes so long is the constant stream of updates. Updates have killed more than one conference presentation.
Yet, when companies are faced with evidence that people don't like updates, they force more, bigger, faster. Why don't they invest in fewer, more meaningful, careful updates?
Treasure the customer's device as you would their home.
Yes, but the software may be based on symbolic reasoning, in which case the computer can 'use' a description of process symbolically and unexhaustively just as a human would.
Unlike other environments where everything is an integration with yet another library or tool chain, DarkBasic is refreshingly monolithic. Everything is simply in the language.
This makes it really easy for beginners to get started. Take a look!
In my mind, refactoring public policy is going to be like refactoring business processes in enterprise code.
The perception is that all these "horrible" duplications and inefficiencies exist.
The reality is that the duplications are actually slightly different business cases that are are difficult or impossible to generalize (it was easier to copy/mutate) and that seemingly irrelevant code has potentially far reaching and damaging consequences (oh, that was important?)
The essential problem is that we look at these individual lines of code instead of realizing that they grew as part of a dynamic system.
Refactoring code isn't a good analogy.
Try refactoring DNA.
It becomes quite tragic (or hilarious) when teams try to simplify such systems and instead end up breaking lots of business process that was ugly, but worked.
DNA/evolution is orders of magnitude more messy than that, but it gets things done more safely and efficiently than some refactoring efforts I've seen.
As in we got zero. Nothing. And this software is still in use in a major product.
So no, please don't trust options or exercised shares at any private company to be worth anything.
You want to get paid? Negotiate salary and laugh in their faces when they offer you options.