This looks like slop? The README is full of emojis and kind of incoherent, there are no implementation details, there claims to be a Metal backend that doesn't seem to exist, etc.
This is definitely not worth using. It doesn't even say what hypervisor its using. Is it using QEMU? Docker? Podman? Lima? Colima?
And also this chart is super weird:
Solution Latency HiDPI Native Integration Setup Complexity
Cocoa-Way Low Yes Native windows Easy
XQuartz High Partial X11 quirks Medium
VNC High No Full screen Medium
VM GUI High Partial Separate window Complex
A standard VM will always be the easiest to set up by far. And latency should be the same across all 4. I mean after all it's a VM running on your local machine. Honestly I don't even know what it means when it says "Latency".
I also looked at some of the code and it's using OpenGL 3.3 Core which is... super old. But it makes sense in the context of this being LLM-generated since most of its training data is probably OpenGL 3.3 Core code....
Overall this project is very strange. It makes me feel more confident in my skills, AI isn't all that great. It's all hype. You can get to the frontpage of HN. And if you're
Peter Steinberger you can get acquired by OpenAI for a billion dollars. But that's about it. The code isn't getting any better.
This reminds me of that C-compiler-in-Rust publicity stunt by Anthropic. There's no substance. It's just a headline.
Gotcha thanks for that info. Yeah that's insane. You have to read the description of a YouTube video to understand what a project on Github is doing. There is no architecture here.
When I was 12, I watched a redneck in a pickup truck try to race the light rail downtown and cut across the road in front of it, only to get T-boned by the railcar against a nearby station. It was the middle of the day and the guy was definitely sober.
People in the U.S. are simply constructed differently, and as a result I think are unfortunately immune to a lot of the subtle forces that generally help to improve safety in other civilized societies.
People? You mentioned one person (who won a Darwin Award--hopefully he hadn't already bred).
P.S.
As for the absurd response, the assertion was
> People in the U.S. are simply constructed differently
and a handwaving reference to an intercity train system from someone who can't even be bothered to make any sort of argument does not establish the point.
This is pretty great stuff, I knew about the raw interop features but had no idea what API Notes offered. Quite cool.
I can't help but feel that Swift will ultimately be the "slow and steady wins the race" safe language of the future. Swift steadily working "first" on both tooling and cohabitability with existing ecosystems is a huge boon for adoption. It understands what an ABI is! If I were doing a greenfield cross platform application I think Swift would be the first thing I reach for now.
The qualms I have with Swift are mostly some of the more recent complex language features that can make Swift code much harder to understand and read, as well as the brainpower required to use Swift concurrency. That and some performance concerns, though many of those seem like they may be solvable with optimizations in LLVM.
> ... some of the more recent complex language features
This isn't recent. The approach that Swift took had this path locked in from the start, the (d)evolution towards ever more spiraling complexity was inevitable from the initial choices.
And this is not 20/20 hindsight, a lot of people, including yours truly, were saying that fron the very start. As an example, take initialization:
The swift book has 16 rules and 14 pages just on object initialization. Chris replied in the comments: "the complexity is necessary for <feature we want> and thus simplicity must give way". My reply: "the <feature you want> is incompatible with simplicity and thus must give way".
→ Swift included all of Smalltalk's keyword message syntax as a special case of a special case of the method call syntax.
---
Rob Rix:
“Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.e. bugs), and complexity in use (i.e. workarounds).”
> I was excited and optimistic about transitioning to Swift in the Swift 3 days. By Swift 5 I was pining for Objective-C.
Swift 5 isn't that bad (even if result builders felt like a weird hack to make SwiftUI possible and I dislike SwiftUI massively) but around that point the language has increasingly made me think "why did this happen when Java already existed?"
Yeah, Swift started out fairly clear and cohesive and now it's just a katamari of every language feature ever made by anyone plus a whole bunch of home-grown features too. I'm always mixed on this because in isolation the feature is neat and I like it, but the totality of Swift is becoming as overwhelming and inconsistent as C++.
Now some C functions which are indistinguishable from free Swift functions get named parameters, and you can switch on some enumerations from C, and some C objects are ref counted but other ones still need you to do it. It's going to be quite something to keep track of which library is which since there's no way to know apriori.
Yeah, Swift looks like someone started trying to port a C# syntax onto an esoteric object-orientated C-dialect (similar to Vala and GObject) then at the last moment noticed Rust 1.0 had been released, tried to patch on some Rust features, and hit release before they were done.
It's quite deceptive. Rust seems initially hard to learn, but it's a small language, so you arrive at competency faster than you might think. Swift seems initially easy to learn, but is a broad language with lots of edge-cases, so you're never quite as competent as you think you are, or need to be
Ehh I have been using Swift from the beginning and I disagree with you and the parent. Swift was "good" before the addition of property wrappers and the result builder syntax. That's when lots of the weird "features" started being bolted on.
Before that it just felt like what a modern OO language with reference and value types, type safety, some very light "not truly functional but nice to have" functional programming features, and readable, "normal", dot syntax would be like. The language was basically complete at that point for the purposes of writing UI apps with the existing Apple frameworks.
Rust understands the C ABI, and that's plenty good enough for now. It's hard to guarantee safety anyway when you're linking to what's effectively outside code (not part of the same build) because we don't really have a fully typed equivalent for raw assembly or binary output (unlike your "safe" VM's, where the bytecode always undergoes sanity checks prior to execution) - hence why the raw C ABI often suffices in a practical sense.
That is surely the target for Apple platforms, whatever happens outside is more a nice to have kind of thing.
As proven by the track record of all languages that want to be simple, created as kind of anti-trends, they always tend to evolve into complexity as their userbase grows, as it turns out other programming language didn't got complex just for fun.
Then since they were initially created as kind of anti-complexity movement, the added on features always have warts due to not wanting to break compatibility, and are only half way there.
C23 versus PL/I, ALGOL variants, Scheme R7RS (full report) vs Lisp evolution, Java 26 vs Modula-3/Eiffel, Go 1.26 versus everyone, ...
I absolutely love Swift. I find it to be such an elegant language. I've done a few macOS/iOS apps with it over the years, but have really come to love it on the server. There are a couple of areas I feel could use some improvement with respect to cross-platform support, but overall the use of frameworks like Vapor have been a breeze to work with.
More support for language interoperability like this will just enhance the cross-platform experience. The Java ecosystem is what makes it so attractive to enterprises. Swift being able to easily take advantage of open-source C/C++ libraries will help with the migration.
I find the Swift tooling very lacking. There's no way to lint dead code, there no way to auto format the files exactly as Xcode would do it and tell the linter those rules so that it doesn't lint your auto formatted code. Xcode project files are impossible to edit except with Xcode and Xcode often has issues and I need to manually empty the build folder. These are just some of the issues I remember
I do miss JetBrains' AppCode and their support for Swift in CLion. I wish they would open-source those plugins so that they can continue to be used in modern versions of CLion.
Does anyone have a mirror of the old Mac SETI client? setiathome_mac_3_08.hqx? I'd like to see if I can get it running again on my old iMac. Either the OS 9 or the early OS X one would work.
I checked the wayback machine and the download pages are still findable, but the client downloads are all FTP links and don't seem retrievable.
It's somewhat bizarre to me for this to impact "casks" but not "bottles". Bottles are all ad-hoc signed and presumably have the quarantine attribute removed manually since I do not see Gatekeeper warnings for bottles I install via Homebrew.
Downloaded files that are not executable or contains any executables in their archives don’t receive the quarantine bit. Non-quarantined executables don’t even require the ad-hoc signing as far as I know. It’s there to prevent lateral movement of executables: not to allow it to run on your computer, but to prevent it from running on someone else’s.
The dependency list is also...something: https://github.com/J-x-Z/cocoa-way/tree/main/vendor
reply