4 ms·

Well, technologies don't battle (except in the marketplace, which often shows the success of both), but some engineers battle over them. Meanwhile, wiser engine

Well, technologies don't battle (except in the marketplace, which often shows the success of both), but some engineers battle over them. Meanwhile, wiser engineers are calmly choosing their technologies based on their suitability to the task at hand, instead of starting arguments over an all-or-nothing mentality.

bunderbunder 11y ago
There's the rub, I think. Historically the big managed platforms have offered some real advantages. JIT compilation has been a part of that, since it helps to some of the reflective features that have in turn supported some useful tools for increasing developer productivity such as aspect-oriented programming, object-relational mapping and mocking. These gains may have come at the cost of raw execution times, but most of the core consumers of the technology measure their success in terms of dollars, and are in the privileged position of being able to offset the performance losses by upgrading their servers. For them this is a perfectly sensible decision. Developers are much more expensive than computers, so they were simply being pound wise and penny foolish. In other environments the calculus has been different. Console games have always had constrained resources, a homogeneous target environment, and high performance demands. Correspondingly, AOT's always been how things are done int hat domain. Sometimes it's even changed over time. Bytecode made a lot of sense for mobile development a decade ago, back when there were relatively many competing hardware platforms and people interacted with their phones differently. Nowadays there are fewer more homogeneous platforms and do more task switching, so the cost of AOT compilation has gone down and the potential benefits have gone up. Hence this shift in .NET, which perhaps seems even more sudden since .NET itself was primarily targeted at enterprise development until relatively recently.
- fyolnish 11y ago
  Console games use interpreted (not even JITed) Lua quite a lot for the areas where iteration time is of most importance. As the parent said, wiser engineers just choose the best tech for the task.

bunderbunder 11y ago

There's the rub, I think. Historically the big managed platforms have offered some real advantages. JIT compilation has been a part of that, since it helps to some of the reflective features that have in turn supported some useful tools for increasing developer productivity such as aspect-oriented programming, object-relational mapping and mocking. These gains may have come at the cost of raw execution times, but most of the core consumers of the technology measure their success in terms of dollars, and are in the privileged position of being able to offset the performance losses by upgrading their servers. For them this is a perfectly sensible decision. Developers are much more expensive than computers, so they were simply being pound wise and penny foolish. In other environments the calculus has been different. Console games have always had constrained resources, a homogeneous target environment, and high performance demands. Correspondingly, AOT's always been how things are done int hat domain. Sometimes it's even changed over time. Bytecode made a lot of sense for mobile development a decade ago, back when there were relatively many competing hardware platforms and people interacted with their phones differently. Nowadays there are fewer more homogeneous platforms and do more task switching, so the cost of AOT compilation has gone down and the potential benefits have gone up. Hence this shift in .NET, which perhaps seems even more sudden since .NET itself was primarily targeted at enterprise development until relatively recently.

fyolnish 11y ago
Console games use interpreted (not even JITed) Lua quite a lot for the areas where iteration time is of most importance. As the parent said, wiser engineers just choose the best tech for the task.