I wasn't sure whether to agree with this or not, so I finally took a slightly closer look at Mojo just now.
This depends on how they license it going forward, and whether they make it open, or use being a superset as a way to capture then trap python users in their ecosystem, and I don't think we have a certain answer which path they'll take yet.
The way they let you mix python compatible code with their similar but more performant code [1] looks interesting and provides a nice path for gradual migration and performance improvements. It looks like one of the ways they do this is by letting you define functions that only use typed variables which is something I would like to see make its way back to CPython someday (that is optionally enforcing typing in modules and getting some performance gains out of it).
> It looks like one of the ways they do this is by letting you define functions that only use typed variables which is something I would like to see make its way back to CPython someday (that is optionally enforcing typing in modules and getting some performance gains out of it).
This is already how Cython and MYPYC work. You add standard PEP-484 type annotations, and they use that to infer where code can be compiled to native instructions.
The typing thing is really unnecessary and a step backwards, IMO. Added typing is maybe great for managing a code base, but it isn’t necessary for performance with a compiler that can do type inference.
Stuff like this is why I can not switch to Apple, I would not expect or even think to look up which Macbooks can support at least 2 displays if they otherwise had decent enough specs for them. Who knows what else I am failing to consider?
I don't want to waste time migrating to a new system, only to find out I need to return/resell it, or later down the road find out another arbitrary/artificial limitation Apple has set that I either have to find a work around for or suck up until I can switch machines again if none exist.
This is unfortunate since there are some features that have made it very tempting to switch.
> Economies of scale. In particular, often total costs are a combination of fixed and variable costs. The more output, the more the fixed costs can be amortized, lowering average cost.
Except that after a certain point total costs increase again as the raw inputs become more scarce and expensive to obtain.
Yep, and if they want to end distribution altogether or start fresh and still keep copyright, they could distribute DRM free copies for some minimum time frame.
If the provider made it available for purchase (not subscription), the liability should go to them first to make DRM free copies available for those who purchased it before shutting down the service. If they are unable to do so, e.g. a sudden bankruptcy, then the liability could go to the copyright holder to find another provider to continue the service and transfer purchases, or provide DRM free copies (either should not be a problem if they are still making money from the given IP). In the event they are no longer making enough money from that IP and wish to just rid their hands of it, it becomes public domain.
> then the liability could go to the copyright holder to find another provider
And they'll choose the crappiest provider they possibly can whose website (no app, presumably) only works in some ancient browser and is "down for maintenance" 50% of the time because that provider has the lowest costs and is thus willing to charge the least for it...
Yep, there would definitely need to be some regulations to prevent that sort of thing as well. I could see this becoming a business where companies are paid to take on this liability of distribution for copyright holders that meets some minimum defined threshold. Ideally it would be as seamless as the prior service if locked, or just reasonable download speeds if DRM free.
Then they can be blocked from selling the rights without the liability of maintaining the service being attached. In order to end the obligation of maintaining the service, DRM free copies must be provided to everyone who purchased the content for some minimum time frame. Failure to do so puts the work in the public domain.
At the very least I would also accept a DRM free copy being provided to everyone who had purchased it (e.g. at least one year or so to download it), and in failure to do that it becomes public domain. Anything less and we basically just end up with the classic xkcd situation https://xkcd.com/488/
> After 151 years ... needs to “evolve” beyond its
I can't be the only one who noticed "151" and it definitely sounds like the author was alluding to it (pokemon) as well. Coincidentally Popsci and Nintendo Power were the only magazines I ever read and owned physical copies of.
pokemon 1st gen had 151 pokemon, making it a pretty recognizable number for pokemon fans, and nothing else of comparable notoriety for 151, and the word choice of "evolve" plus the added emphasis of the quotes in the article, I admit it was subtle and may not have been intended, but my mind instantly made that connection, but on second thought I guess they could have also simply intended "evolve" as a subtle science pun as well
This depends on how they license it going forward, and whether they make it open, or use being a superset as a way to capture then trap python users in their ecosystem, and I don't think we have a certain answer which path they'll take yet.
The way they let you mix python compatible code with their similar but more performant code [1] looks interesting and provides a nice path for gradual migration and performance improvements. It looks like one of the ways they do this is by letting you define functions that only use typed variables which is something I would like to see make its way back to CPython someday (that is optionally enforcing typing in modules and getting some performance gains out of it).
[1] https://en.wikipedia.org/wiki/Mojo_(programming_language)#Pr...