The dig at Kernel is kind of depressing. It's probably an evolutionary dead end, but god damn it, the world is better when people try things. Dismissing them doesn't make you cool.
I had Windows and Mac laptops back then, and the HN snobbishness around the superiority of the Mac was genuinely baffling.
My i9 2019 MBP with discrete graphics was probably the worst laptop purchase I ever made. Docking it to an external monitor would enable the GPU, so even when idling it would run the fans and drain the battery.
I’d read cautionary tales about Windows laptops being pulled out of backpacks scorching hot as they failed to shut down. But that happened to my Mac all the time, too.
The M series though is incredible. I can’t imagine buying a Windows laptop now.
This was a laptop, so cooling was very constrained. The fans can only be so big & you can only shift so much air in & out of a MacBook.
I presume Apple knew perfectly well but wanted the halo product to sell to those people who will always pay extra for the perceived “top of the line” product. Once Intel branding had created an i9 that was a bigger number than an i7, then Apple was going to sell it.
It was faster than the i7 after all: just not for very long!
My entirely speculative theory is that the poor thermal characteristics of that era of Intel CPUs didn’t really become apparent until quite late in the development process & by that point Apple had probably committed to buying a fair chunk of Intel’s output.
> Intel really made themselves unpopular with Apple during that period.
Intel just reenacted IBM's history with Apple, particularly the G5 era. That CPU was instantly a no-go for anything mobile. In workstations it was cranked ever higher with very poor power-frequency scaling, needing water cooling for the beastly 200W idle power consumption and close to 1kW full throttle.
That went well so was a perfect role model for Intel's i9.
I had (and still have) a 4k external monitor. Naturally I wanted the MBP to drive the monitor with a resolution that took advantage of all the pixels. Unfortunately with most monitor settings the GPU power consumption would produce enough heat to run the fans even if the rest of the system was completely idle! If I set the output to full HD the GPU would cool down and the fans would turn off. But full HD on a 4k monitor is a waste.
It was very strange. I could drive the monitor at 4k but with the image upside down, and the power consumption would be low. But flip the image right side up and it would run hot and turn on the fans.
It took a couple weeks of fiddling, but I finally found a combination of refresh rate, resolution, image orientation (right side up!), and cabling that let me drive the monitor at high resolution without running the fans. What a pain.
(I used iStat menus to monitor GPU power consumption. At “good” settings it consumed about 5w. At “bad” settings it would consume 17w. At a bad setting you could immediately see the various temperatures go up and the fans spinning up to compensate.)
I don't know, but I did observe differences in power consumption caused by all sorts of unexpected things.
At some point during all my fiddling with this stuff, I discovered a correlation between GPU power consumption (as indicated by iStat Menus) and fan speed. For example, if I switched to high resolution, the power would increase, and at low resolution, power would decrease. And of course more power means more heat, which causes the fans to run. That kind of made sense: moving more pixels consumes more power.
But I also observed an effect caused by refresh rate. Oddly, I seem to recall 30Hz would cause increased power draw but 60Hz the power draw was reduced. Yes, this seems counterintuitive. Since I didn't have a good model for what caused the increased power draw, I decided to try all combinations of the settings. On a lark I tried inverting the image and it actually affected the power draw! Probably has something to do with the access order of memory, but I don't really know. And indeed it seems odd that running the image upside down actually pulled less power than right side up.
The cabling issue was a bit more complicated. My initial configuration was to run the video through a dock, with the dock's video output going to the monitor. That always resulted in high power draw. Connecting the computer directly to the monitor did have the effect of reducing power draw... but only in certain configurations.
It was a truly ridiculous idea to put an i9 in any laptop. That generation of i9 is difficult to cool even with liquid cooler systems in big ATX cases.
Just to remind, the mobile + desktop lines are not the same thing even if they both get the same branding.
The top end chip in the 2019 MBP was the i9-9980HK, which had a TDP of 45W.
Would have been reasonable in a chunkier workstation/gaming type of laptop with the kinds of cooling solutions those usually get, it's not something that needed an actual desktop liquid cooling solution to run well.
But obviously the 2019 MBP design/cooling was not up to that task.
Bun in its current state absolutely has issues like segfaults. As nice as it is, I moved off of it back to node for production.
Folks generally tolerate issues if they believe they’ll get better with time. I know I did for a while. If that confidence collapses, that’s not politics.
But there's no evidence of that in the post. If they had said something like "Bun had bugs X, Y and Z - this Rust thing is the last straw, it's over" -- that would be a reasonable decision, and no one could really complain. But they didn't say that. They just said it "seems like a future headache".
- A single bug about EJS, which was fixed almost a year ago and has never regressed.
- Frustration that Bun was rewritten in Rust, which "seems like a future headache" - i.e. no evidence of current issues, just something which they suspect might have issues in the future.
If you see more evidence of more bugs that weren't fixed almost a year ago I'd be curious to see it.
From my experience, a tiny alarm sounds, a voice says cyclist approaching and the door clicks to locked. At least I believe it did, I heard a sound. I didn't check the handle.
I don't believe the car was specifically in a bike lane at this time but I'm new to the city and may have missed the markings.
Elektrek went from insufferably pro Tesla to insufferably anti Tesla. If you liked it before and not now, your quarrel is with the direction of the propaganda.
We support thread-pausing via instrumentation. This can cause threads to observe different interleavings, which can help uncover bugs in concurrent algorithms. At this time, we don't perform specific memory model fault injection or fuzzing.
I wrote a library called Temper, which simulates the Rust/C++ memory model with atomics in a similar way to Loom. But it goes much deeper on that narrow domain, and to my knowledge it's the most accurate library of its kind with the largest set of test cases.
If you simulate using mock CPU instructions like memfence or LL/CS there's no guarantee your model fits your ultimately executed program.
Unless of course, you do something like antithesis and directly test what compiled. It's an interesting alternative world.
I've taken the liberty of adding you to LinkedIn - would love to grab a drink next time you're in the SF Bay area.
There's not a lot of churn in Unity, but that's more because they mostly fail to ship anything of significance than due to excellence in backwards compatibility.
I was in the audience when DOTS was announced, and a decade later Cities Skylines II showed how ill equipped for prime time it remains (not that the developers were blameless).
Deprecating entire languages (probably the right call long term, oddly enough Godot is keeping GDScript around).
Render pipelines (URP and HDRP to be merged, built in likewise being deprecated).
Most of the things around DOTS.
Most of the things around networking.
The whole package management system (I mean, it’s a nice idea, still counts as churn).
Also multiple approaches to UI and input.
I would say that a lot of the new stuff is built on good ideas but I sometimes wish they’d slow down a bit and ship actually thought out and finished features.
And most of the above already had alternatives previously, this isn’t even getting into wholly new things like Sentis, if you are working on an old project thankfully it will mostly keep working, but if you need to keep up to date with the current mechanisms and practices, there’s a lot of churn.
Maybe not as much as in Godot, but to be honest that other engine is going through a lot of evolution so instability and a feature explosion is to be expected (despite terrain still being a plugin, while Unity’s own terrain implementation is oddly dated and abandoned, while their water system felt like a tech demo and more often than not the asset store is expected to do the heavy lifting), while Unity tries to appeal to everyone and capture headlines it seems. Just look at the marketing around DOTS (and how long it took for it to be usable).
A lot of the things you mention there have been in development for the better part of 10 years already, and still haven't reach a stable, mature and production-ready state yet. Unity have also kept deprecated stuff around for much longer than they should have, which sounds great on paper for backward compatibility, but it just means they're lugging years of technical debt with them and it's slowed them down immensely.
Looking at the past year of Unity updates, since 6.1 or so, it seems that most of the focus is now going to refactoring major parts of the engine to facilitate backporting HDRP's feature set to URP. It's all good work and high time they did some cleanup and committed to a single standardized render pipeline, but it's not exactly moving the needle forward very much yet.
> (probably the right call long term, oddly enough Godot is keeping GDScript around).
Even in Unity 4, it was like "You can write scripts in C#, or you can also write them in Unityscript or Boo, I suppose..."
In comparison for Godot, GDScript is very often the happy path. Things like web publishing work more seamlessly with GDScript than with C# (and miles more than GDNative/GDExtension). So I don't think it's nearly as likely to get deprecated as Unity's scripting languages.
The obvious additional good from this approach is that you no longer couple everything so tightly with just one scripting language, so in some ways it's a bit easier to introduce bindings for other languages. The downside, however, is that it leads to fragmentation in the community, duplication of effort (suddenly you need the double amount of docs), more difficulty and friction in development with new mechanisms demanding that you take the limitations of both languages in mind, oh and if you dare to write your own language then suddenly you have to support both it, as well as any dev tools for it. For what was and still is a communtiy project without strong financial backing (just look at how much money Unity burns on useless stuff, and how much more the people behind Godot could do with that money), that's quite the gamble.
Maybe if they focused on the core engine more, then deltaV: Rings of Saturn wouldn't have odd performance issues for a 2D game and wouldn't get confused with multi-monitor setups. Maybe Road To Vostok wouldn't crash when loading into the Village map on an Intel Arc GPU, and also start on the wrong monitor same as deltaV. Maybe even demos like "Realistic Jungle Demo" on itch.io wouldn't have all white textures on said Intel Arc GPU. Maybe we'd be two or three whole releases of features ahead by now, if all of the hours spent on GDScript to date would have been spent elsewhere.
On the other hand, there's no guarantee that any of those devs would fix the other issues if their efforts were to be redirected. Similarly, if they didn't try with GDScript, the community would be smaller, due to its ease of prototyping, and being simpler and more approachable for the folks who don't know C# yet, even if it's also unnecessary to the folks who like tools like Rider/Visual Studio or are coming from Unity or engines with scripting in C# or just C++. I'm pretty split on it overall.
> Or maybe without GDScript the engine would not get the traction it has and would not have the resources to do anything at all.
Or the developers might not find C# to be as interesting to work on and some people that stick around in part due to getting to iterate on GDScript wouldn’t contribute at all! All of those are possibilities, that’s for sure, Godot definitely has a lot of appeal due to fast prototyping too!
> Intel Arc GPU rendering issues have nothing to do with Godot’s choice of high-level scripting language.
The GitHub repo for Godot has 83'164 commits. Let me pull an arbitrary unimportant number out of my ass, which is 6 hours of work per commit on average (lots of small ones, some that take weeks, doesn't matter) and we get 498'984 hours which we can round to 500k for our napkin maths.
There's around 52k LoC for the gdscript module, about 1'380 files. Around 5% of the overall commits in the repo are in that module, we can up that to like 7% to account for docs and editor and other parts, but we don't have to assume higher. That gives us about 35k hours spent on GDScript.
Remove GDScript and you get 35k hours to put elsewhere, including Intel Arc support. It's the exact same principle of Linux distros having like a dozen desktop environments and the efforts being so fragmented that it's impossible to make a single really good one (though there are different goals for the projects, for example KDE vs something lightweight like LXQt).
Of course, I addressed the possibility that people working on GDScript just wouldn't be able to work on the other stuff, so one should argue that redistributing work would be quite complex and since it's a lot of volunteer work, people might just not care to work on X instead of Y, that was addressed here:
> On the other hand, there's no guarantee that any of those devs would fix the other issues if their efforts were to be redirected.
That said, the above is more or less why Unity benefitted in regards to development velocity from saying goodbye to ECMAScript and Boo (or maybe they shot themselves in the foot, cause prototyping is slower compared to GDScript).
reply