Anyone claiming these systems are for the "democratization of software engineering (or any knowledge field)" are simply not grasping the reality at hand.
It's not like our corporate leadership is being subtle in any way about their openly stated end goals here. We are simply instructed to continuously burn our enormous piles of "thought tokens" for their machines. The same machines only made possible by the theft of humanity's collective works at unimaginable scales. We must hold up these statistical facsimiles of human work, now rendered by machine, as the inevitable future output of humanity. To do otherwise is the way of the luddites.
The gods of unbounded growth, efficiency and productivity have come to demand our sacrifice. Who are we to stand in their way when countless skilled laborers before us have fallen to automation? Our number has been called as it were, and to reject what they demand is to reject "progress" itself. The march continues as it has since before the dawn of industrialization, relentless and indifferent to any and all that are crushed beneath it.
I don't know when the last bastion of "inefficiency" will fall, but at some point humanity may collectively grow to regret some forms of automation. Time will tell.
There's a certain simplicity and beauty in honing and stewarding a craft towards mastery that automation doesn't provide. I feel this is an innately human desire. Many cultures in the past used to place a great emphasis in this very personal endeavor. Sadly it seems each decade we slowly suppress these basic human needs, too tantalized by Western values of having ever "more" of everything, much to our detriment.
I am not a game developer (I've made a few in the past but didn't use any frameworks besides direct libsdl calls), but if this article rings true for anyone in that field I'm a bit surprised things as basic as properties, structs and tuples are "not used" by unity devs, this is some basic stuff that has been supported even by Mono for decades. Just basic syntactic sugar though, so not a big deal either way. Just surprising to me at least.
Iirc Godot is taking the approach from both sides however and also working on a libgodot which will allow a "bring your own runtime" which I'm much more interested in than the integrated "environments" that are Unity and Godot today. I'm likely in the minority though as they only started making a library export after the all in one environment was stable enough...
Mono was in a usable state on Linux for literal decades before becoming official and integrated into what is core today, that is unless you needed windows forms, which much like MSFT UI frameworks today had multiple failed attempts spanning those same decades...
We attempted a move to mono for backend web services maybe 3 years before .NET Core released, and it was a complete no-go. 10x reduction in performance on the same hardware.
This wasn't specific to our workload either. I was big into the game Terraria at the time, and I saw similarly poor performance when running it's game server under mono vs .NET 4.x
While some of the mono toolchain was integrated into .NET Core, CoreCLR was a rewrite and immediately solved this problem.
Great context, thanks! I knew it worked (I closely followed mono development at the time) but I didn't have a windows license/windows machines at the time it was ongoing to compare it to. 4x is pretty bad, any ideas what went wrong? Lack of jit maybe? I forget the exact architecture of mono at that time, being like 20 years ago...
It did have a JIT, it just wasn't a very performant one. I recall the GC implementation also being quite slow. GC is an area where .NET is still making strides.. we got a new collector in .NET 10.
Iirc the lineage of their c# came from Mono, then diverged a bit over time. Hopefully they can leave that baggage behind and just use the newer .net core, if they're not already that is... Disclaimer: I haven't looked in half a decade
Languages that seem to indefinitely grow more features over time (like c++, c#, rust, etc) evitably become bucketed by epochs unless the consuming application code also operate across the same time scales. Feature deprecations tend to go hand in hand with newer features, leaving you with basically "multiple sublanguages" in a supposed single language, exacerbating fragmentation of the community. I don't want to have the mental load of contextually understanding "which" sublanguages I need to care about depending on the year a consuming application was written. This is why I tend not to reach for new fangled features and stay with the core runtime stuff in evergreen langs.
Zero allocation impl? very cool! Arguably, the original runtime should have done this in the first place given the limitations/tradeoffs aren't so bad, but I guess that ship sailed 20 years ago (man that hurts)
Most .NET projects that Linq originally targeted ran in so called "Server" and/or "Workstation" GCs (.NET has had very generic public names for its GCs for a long time which were also somewhat misnomers because even some Desktop apps would run in "Server" GC and it was possible for vice versa [0]) where allocations were cheap, garbage collection was relatively cheap (because both GCs were multi-generational, had strong [but different] tuning for their generations, etc).
Unity inherited a much simpler Boehm GC from Mono. Under a (single generation) Boehm GC allocations are a bit more expensive and garbage collection sometimes a lot more expensive. (A Boehm GC was much easier for C++ engine code to understand/interact with, which is also part of why the .NET modernization project for Unity got so complicated and still has such a ways to go left.)
[0] Fun aside: in fact, modern docker advice for .NET is to switch "server applications" to use "Workstation GC" if you need to stack multiple containers on the same host because of differences in expected memory usage.
The modern .NET runtime can get devirtualize interface calls and eliminate temporary object allocations in some scenarios. It's a bit of a black box - who knows when it actually works? - but still, it's a nice boost here and there.
I assume it's not a black box anymore, but maybe that's a non-free lang extension? I had assumed linq was part of .net core these days, but I haven't gotten around to checking (10+ years since I've had a serious .net project)
I wonder what, if anything significant, has changed architecturally from osx to modern macos and how this post could be used as a guide for future porting efforts (aside from the obvious 2 CPU isa changes over the last 20 years)
I'd argue there's easily more folks lacking said "scruples" in tech's private sector than the typical on the ground government employee or contractor.
Half of what actually makes money in tech these days involves active spying on consumers or manipulation of base human desires at scale. Not exactly the paragon of morality.
It's stupid, but it mostly works because they also own the sat deployment side of the equation as well.
Dropping the cost to launch (replacement sats etc) by continuing to take greater piece of all total space launches along with large step function capacity refinements with each new rocket generation, means they will continue to push the economics in their favor. $300k/sat might not be worth it, but unless there's a number of back to back unmitigated disasters with their new rockets (totally possible given the cost of getting it wrong) launch costs will continue to drop as they iterate. Even in the worst case where starship never works, they can still salvage and continually refine their current proven designs.
That said, I do not trust their IPO valuations at all. I have enormous respect for what SpaceX has accomplished in such a short time span. When the US government deprioritized further space R&D for all launch vehicles and relied entirely on Russian launch vehicles, I honestly thought it was the end of an era of innovation in space in my (current) country. I'm glad I was wrong to some extent, even if it means an over reliance on the private sector to make further progress.
You may point out that private space ventures sadly have similar problems to ceding to foreign nations, and you wouldn't be wrong. The only silver lining for me is getting to see continued progress in my lifetime. It doesn't take all the sting out of government funding drying up for space launch vehicles, especially when our other budgets like defense are so insane, but I'll take it at face value as a victory for humanity to continually improve space capabilities at scale in any form.
To be absolutely clear, as I make no allusions: we operate in a brutal, broken system from the current financial systems under capitalism in its current form. I'd likewise argue that a billionaire "with character" vs a billionaire with none is still highly problematic. The very existence of billionaires is the root of enough social ills that they should not exist as a class of people at all. Many in that class would even claim to be "doing what's best" in all honesty, when nothing could be further from the truth. Sadly that doesn't mean the ruling class simply ceases to exist because of our collective desires. Nothing short of massive societal change through collective action, something humans have been proven to be really, really bad at time and again, would make any other system possible. I digress..
That said, SpaceX engineers managing to perform impressive feats in manned and unmanned space travel still stands as something to be lauded in my book, even if their leadership deserves none of it. These feats are made _more impressive_ given the poor, child-like behavior found in their particular brand of leadership rather than less.
The employees of SpaceX have made their views about leadership very well known several times now, often with real consequences to themselves and their families. We live in unfortunate times. I'll take my slivers of hope for humanities continued advancement in space travel where I can however, even as it seems the fabric of society further unravels.
It's not like our corporate leadership is being subtle in any way about their openly stated end goals here. We are simply instructed to continuously burn our enormous piles of "thought tokens" for their machines. The same machines only made possible by the theft of humanity's collective works at unimaginable scales. We must hold up these statistical facsimiles of human work, now rendered by machine, as the inevitable future output of humanity. To do otherwise is the way of the luddites.
The gods of unbounded growth, efficiency and productivity have come to demand our sacrifice. Who are we to stand in their way when countless skilled laborers before us have fallen to automation? Our number has been called as it were, and to reject what they demand is to reject "progress" itself. The march continues as it has since before the dawn of industrialization, relentless and indifferent to any and all that are crushed beneath it.
I don't know when the last bastion of "inefficiency" will fall, but at some point humanity may collectively grow to regret some forms of automation. Time will tell.
There's a certain simplicity and beauty in honing and stewarding a craft towards mastery that automation doesn't provide. I feel this is an innately human desire. Many cultures in the past used to place a great emphasis in this very personal endeavor. Sadly it seems each decade we slowly suppress these basic human needs, too tantalized by Western values of having ever "more" of everything, much to our detriment.
reply