3 ms·

> we take the responsibility of fixing it so you don't have to Surely you must say no to some people... I can't take the risk that person might be me and then

> we take the responsibility of fixing it so you don't have to Surely you must say no to some people... I can't take the risk that person might be me and then be left up the creek without a paddle. Do you have an SLA? What if I have an issue in production and the core contributors are all sleeping? Can I wake you up? Can I pay you for the right to wake you up? Even if you are awake and willing to help on my schedule, can you do so reliably without breaking everybody else? As your complexity (and popularity!) grows, your ability to take responsibility shrinks. EDIT: A quick Googling suggests that you do offer commercial support. Take my comments above more generally for the wider array of open source projects out there that real businesses depend on.

FooBarWidget 13y ago
It is exactly as you say. It is a double edged sword, with both benefits and drawbacks. RVM is one example. Another example is Python. Why does Python still have a global interpreter lock after all these years, and why does it not have a JIT? One of the reasons is because it makes development easy, keeps the architecture simple and makes contributions easy. Writing a language implementation without a GIL, and with the latest state-of-the-art garbage collector and JIT, makes the code and architecture more complex also. The drawback of this is... that Python has a GIL and has no JIT.
- brandonbloom 13y ago
  Huh? I don't understand the relationship between this and what we're talking about at all. There are so many distinct issues to sort out here, it's almost not even worth trying. rvm is complex both in implementation and in interface. The interface complexity comes from the shear number of things it tries to do automatically for you: interpreter versioning, gemsets, shell integration, plugins/extensions, devops functionality, and a bunch more! All of that is tangled together in one tool and you can't get any piece of it a la carte. Each of those things has its own plumbing commands and conceptual surface area. rbenv just fucking puts some shit on your path. That's totally separate from an interpreter having inherent complexity in sophistication of algorithms and data structures. Personally, I think (as do the PyPy folks) that Python's design has some substantial complexities that make JIT-ing much more difficult than Lua, for example. If you choose a simpler language, you can get a simpler JIT; hence LuaJIT's success. Similarly, if you choose an even simpler language, with less mutability in core data structures, you can get a simple lock-free, multi-threaded interpreter.

FooBarWidget 13y ago

It is exactly as you say. It is a double edged sword, with both benefits and drawbacks. RVM is one example. Another example is Python. Why does Python still have a global interpreter lock after all these years, and why does it not have a JIT? One of the reasons is because it makes development easy, keeps the architecture simple and makes contributions easy. Writing a language implementation without a GIL, and with the latest state-of-the-art garbage collector and JIT, makes the code and architecture more complex also. The drawback of this is... that Python has a GIL and has no JIT.

brandonbloom 13y ago
Huh? I don't understand the relationship between this and what we're talking about at all. There are so many distinct issues to sort out here, it's almost not even worth trying. rvm is complex both in implementation and in interface. The interface complexity comes from the shear number of things it tries to do automatically for you: interpreter versioning, gemsets, shell integration, plugins/extensions, devops functionality, and a bunch more! All of that is tangled together in one tool and you can't get any piece of it a la carte. Each of those things has its own plumbing commands and conceptual surface area. rbenv just fucking puts some shit on your path. That's totally separate from an interpreter having inherent complexity in sophistication of algorithms and data structures. Personally, I think (as do the PyPy folks) that Python's design has some substantial complexities that make JIT-ing much more difficult than Lua, for example. If you choose a simpler language, you can get a simpler JIT; hence LuaJIT's success. Similarly, if you choose an even simpler language, with less mutability in core data structures, you can get a simple lock-free, multi-threaded interpreter.