1,891 karma · joined October 12, 2016
A scene graph needs 2 mutable references, and has nothing to do with ownership. Same issue exists with GUI's. The pattern that Rust forces is to always request a reference, which incurs a performance penalty while retrieving the same reference again and again and again.
A couple of decades ago, we didnt trust compilers, we did assembly manually. Today is same barrier, some developers will explode with productivity while others will be left behind.
A Nobel in 2026 doesnt carry the same weight as a Nobel in 1955.
If they addressed this, the Doom experience would have run better on Amiga.
To work around this, all window messages in ported apps are marshalled to execute sequentially. Small additional overhead, and the system doesnt spread available threads, so noticably slower.
Compare a native Haiku app with a ported app, one is smooth as ice while the other isnt. Users notice it. This is on many core systems.
For everyone its a different App. For me, Visual Studio 2022 and its world class visual debugger that inspects my complex vectors. Sadly, nothing similar (Xcode slow, QtCreator slow, etc).
I do enjoy Haiku the most, but cannot be as effecient when developing embedded libraries. I professionally develop cross platform libs, developed on Win11 but deployed on Linux embedded. Irony.
Reverse the logic and make a “sudo_h” script which hides the password entry for those rare times you need it.
Any program that has at least one concurrent task that runs on a thread (naturally they’ll be more than one) is a perfect reason to switch to Actor programming model.
Even a simple print() function can see performance boost from running on a 2nd core. There is a lot of backround work to print text (parsing font metrics, indexing screen buffers, preparing scene graphs etc) and its really inefficient to block your main application while doing all this work while background cores sit idle. Yet most programmers dont know about this performance boost. Sad state of our education and the industry.
I guess what you’re trying to say is that it will kill Windows. But that wont happen since enormous percentage of businesses run Windows ecosystem.
Lets face it, Windows is in maintenance mode, pointless for MS to invest heavily in it since there is no threat for businesses switching to Linux or something else. MS devs primary maintenance job these days should just be scrabling MS Office API every 6 months or so to break Wine and other Linux non-emulators. Wine devs in constand rearrange deck chairs mode, while Win32+Office devs just add a new parameter to an API interface in their 6 month cyclic undocumented API breaking scheme.
You need a better Office than MS Office to break the cycle, and this will be a Web based office / collaboration tool. And guess where MS Azure and Web services fit in this brand new world.
Microsoft dominance aint going away in our lifetimes. Only non US government pressure may force other countries to switch to a flavour of Linux due to US sanctions. Only then can you see a visible migration from Windows. This is a decades long process.
On the plus side, as a dev with 30+ years of experience, I am commanding a very good contract salary these days. Revolving door companies stuck in process hell and product rot, and cannot deliver new value, so they’re scrambling to find experienced devs that cost a premium. My salary today makes up for peanuts at the start of my career.
There was a brief period when I discovered BeOS 4.5 which brought the wonder back in September 1999. That was short lived. I occassionally get the bug with Haiku but sadly dont have the spare time during this last decade.
Enthusiast on small platforms still chase the bug, in these smaller communities you can actually make a difference, and there is still passion to be found there. There is also some innovation since experimental concepts can be tried out.
Leaks are trapped with tooling, and all you need is one dev in the team to be diligant to run valgrind or visual leak detector or similar.
- unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning.
- aliasing pointers being restricted by default (ie an alias keyword should have been added). Performance matters. All these benchmarks which show something beating C or C++ are mostly due to dealing with aliasing pointers. C++26 still doesnt have standardised restrict keyword.
There are more but I understand the logic/usability/history behind them. The above points should have been addressed in the 80’s.