You make some great points here. Here’s one of the places I’m coming from that seems to be aligned with the author of this.
I find macOS to be a superior OS for doing computer work to all the alternatives. It still sucks for a lot of reasons, but to my taste it generally sucks less. I’m a web dev, so I host a lot of crap in Linux, and I’m pretty confident in using it as a desktop. But the general day to day experience I find macOS superior.
There’s plenty of people in similar boats, and this is the
most affordable machine (new, not used) that lets someone get to use macOS.
For a lot of people with budget limits I’d point them to used MacBook Air models rather than the Neo, but having this as a new model is a really nice option for some people.
Also you can call the Neo CPU slow but its benchmarks run circles around anything you find at its price range. Those machines have more RAM and storage, but the Neo will likely provide a more responsive experience than anything in its price range.
I do agree on refurb/used rather than the Neo. The best low-ish cost computer Apple is selling right now is probably their refurbished $750 MacBook Air M4 with 16GB RAM/256GB storage.
The only way I'll push back on this is the Ryzen 5 AI 340 is faster at multicore than the A18 Pro. Slower single core by a slight amount, and much slower iGPU.
However, that means to compete with the MacBook Neo more completely including integrated GPU, all you have to do is go up one CPU SKU to the Ryzen 7 AI 350 and you're further increasing your multi-core performance lead as well as completely closing the iGPU gap by doubling your GPU performance.
That same Yoga laptop is offered in this configuration including extra storage (16GB RAM/1TB SSD/Ryzen 5 AI 350) for $800
That...really is only $100 more than the 512GB configuration of the MacBook Neo if we aren't tossing in the education store pricing.
Perhaps it's more of a MacBook Air competitor at that price range. Stretching up to $800 is a lot...but you do also get a lot for that stretch.
Asahi only supports M1 and M2 series Macs currently. The Neo uses an A18 Pro, which was only ever in an iPhone before. I wouldn’t count on Asahi coming to these soon.
Maybe some of these agentic AI superstars can point their 100x engineering chops at this. This would impress me but not going to hold my breath for that.
Reverse engineered documentation is very often preferable to the internal kind, which is not necessarily accurate. So either way, the Asahi folks are doing valuable work.
My first, and primary, programming language was C# which includes probably too large a standard library. It was definitely a surprise to see how minimal/simple other standard libraries are!
But they're there. I would much rather have a stdlib option which isn't as good as the most popular third party solution, than not have an stdlib option at all. You can't always count on being able to install stuff from pypi, but you can always count on the stdlib being present.
Broadly speaking, maintaining a big std lib is a huge amount of work, so it makes sense that a language team is conservative about adding new surface to a stb lib which they will then have to maintain for a long time.
The work involved in maintaining a standard library is things like bug fixes. A larger standard library (or multi versions) means there's more likely to be bugs. You also have performance improvements, and when new versions of the language come out which has features to improve performance, you will most likely want to go back through and refactor some code to take advantage of it. You will also want to go through and refactor to make code easier to maintain. All of this just gets harder with a larger surface.
And the more stuff you pack into the standard library the more expertise you need on the maintenance team for all these new libraries. And you don't want a standard library that is bad, because then people won't use it. And then you're stuck with the maintenance burden of code that no one uses. It's a big commitment to add something to a standard library.
Every library is a liability especially in terms of api. There are many example where the first take on a problem within a std lib was a bad choice and required a major overhaul. Once something is in standard library it’s literally impossible to take it back without breaking the world if you don’t control api consumers
Yes, in python they break something at every release now. It's terrible. It mostly is because they remove modules from their standard library for no good reasons.
For example they've removed asyncore, their original loop-based module before the async/await syntax existed. All the software from that era needs a total rewrite. Luckily in debian for now the module is provided as a .deb package so I didn't have to do the total rewrite.
edit: as usual on ycombinator, dowvotes for saying something factually true that can be easily verified :D
The code is under the open-source PSF license. You can vendor or repackage it as you wish rather than rewriting your dependents. The removal is mostly about ensuring that nobody will try to hold them responsible for any more maintenance (plus they can, for example, drop tests and have a faster running test suite).
The thread is about the code in the std lib being a huge amount of work because the code in the std lib needs to be kept working with new language releases.
And then you answered about downstream code breakage totally outside the std lib.
What would that entail, just a package whitelist? A few renamed packages? In the python 3 transition they renamed urllib2 to just urllib, but now it's almost a dead battery too and you want to use requests.
Honestly the problem was they did not go far enough. They hoped to have a minimal churn switch to avoid getting locked into bikeshedding for the rest of time. However, there was so little user user facing improvements that the required change hardly seemed worth porting. They also failed to initially offer any automatic porting tooling which could have increased adoption.
I will be forever mad that they did not use that as a breaking opportunity to namespace the standard library. Something like: `import std.io` so that other libraries can never conflict.
For a camera exposing onto Kodak 5254, probably the fastest available in 1975, blazing ISO 100 film stock. Yeah it’s dim for that. To your eyes as I understand it’s pretty well lit.
The photo nerd hacking tweak of note here was the pushing of the stock to 200 and using uniquely crafted NASA lenses built to photograph the dark side of the moon with not seen before aparture.
Arguably a youtube rending of a compressed digital source viewed on a computer screen falls short of a 1970s full cinema via film live viweing.
> Alternatively, users can also choose to purchase the Mac versions of Final Cut Pro, Pixelmator Pro, Logic Pro, Motion, Compressor, and MainStage individually as a one-time purchase on the Mac App Store.
Magnetic induction damping compasses have traditionally used a flat plate under the needle in order to arrest the motion of the needle. This component is not transparent. By removing the plate and adding the ring, you can see through the face, providing the benefits of a liquid damped compass without the possibility of a bubble forming.
Interesting, maybe new for pocket compasses. I had a marine plotting compass that used a massive copper cylindrical housing, with a sapphire glass bottom and window. It was very well damped. It was made in the 1940s, presumably when yachts were mostly wooden. (More modern boats would usually need significant compensation) or maybe it wasn’t for marine use? But anyway, it was a great plotting compass that I used extensively on my little fiberglass weekender sloop. Better than the westmarine garbage mounted on the cabin bulkhead by a long shot.
Lots of liquid damped compasses do not have a transparent base. The liquid is very good at protecting the needle (induction compasses often use a lock), prevents condensation, stabilises temperature, and is noncompressible for diving. Induction compasses tend to be used for fast reading whilst off-level, so tend only be useful for sighting compasses. TBH I am not sure even map compasses grain a lot from transparent dials, it is more that they are making the baseplate and top from transparent plastic and have no need to make the bottom from something else.
That's because the magnetic needle's orientation will only induce meaningful flux in a cross section large enough for it to have any damping effect. That braking effect is more or less proportional to the number of fieldlines cut and diminishes (from memory) to the cube of the size of the air gap.
It offers native x86, Windows on ARM, and Apple Silicon versions.
I think this is incorrect. Specifically the Windows ARM support. Official hardware support page indicates that the Windows version requires x64. I unfortunately don’t have the hardware to confirm for myself. But Blizzard is the kind of company that would have made a blog post about that.
This is neat, and exciting that Windows emulation tooling is progressing! It seems like there’s a lot of work hardware vendors would need to do in order to make Win/Arm viable for game devs. I really wonder if that’s ever going to happen.
> I think this is incorrect. Specifically the Windows ARM support. Official hardware support page indicates that the Windows version requires x64. I unfortunately don’t have the hardware to confirm for myself. But Blizzard is the kind of company that would have made a blog post about that.
It has been around for a while, circa 2021. They made a forum post when they released it.
You specified working with web and .NET Core (now just called .NET). Given the scope of modern .NET I don't think I can recommend a single book, but I've tried to order this in how I see them as most to least impactful for a dev.
For web dev specific guidance it's hard to beat ASP.NET Core in Action by Andrew Lock. Check out Lock's blog too at https://andrewlock.net, it's a great source of new features happening in ASP.NET. He does go into publishing an app on both Windows and Linux, with a decent guide to both. But you'll probably want to read through MSDN docs on that as well, I don't think there's a book that goes in very deep on that.
For generally writing modern C# using .NET, I like Code like a Pro in C# by Jort Rodenburg.
For a quick tour of modern C# features C# 12 in a Nutshell by Albahari is basically the reference guide. 12 is the latest, grab any of them from probably 7 up for a decently modern take.
I find macOS to be a superior OS for doing computer work to all the alternatives. It still sucks for a lot of reasons, but to my taste it generally sucks less. I’m a web dev, so I host a lot of crap in Linux, and I’m pretty confident in using it as a desktop. But the general day to day experience I find macOS superior.
There’s plenty of people in similar boats, and this is the most affordable machine (new, not used) that lets someone get to use macOS.
For a lot of people with budget limits I’d point them to used MacBook Air models rather than the Neo, but having this as a new model is a really nice option for some people.
Also you can call the Neo CPU slow but its benchmarks run circles around anything you find at its price range. Those machines have more RAM and storage, but the Neo will likely provide a more responsive experience than anything in its price range.