viktorcode

Unlike Rust, it has some C++ binding, which is extremely useful.

> Truly incredible that they not only defaulted, but LIMITED change-detection to WILL-change

That's not strictly true. You get the new value inside the closure. This is very useful for observing changes on data model that drives SwifUI from outside of SwiftUI. Before you had to write the code like this to achieve that:

func startObservation() { withObservationTracking {

        print(store.state.toggle) // Here we have the new value (+ it is called once before any change)

    } onChange: {
        Task { startObservation() }
    }
}

My guess is you've encountered issues with actor isolation made suddenly explicit in your language upgrade. This is exactly what's addressed in Swift 6.2, so it won't be nonsensical in that case. Speaking from my personal experience of trying to upgrade and stopping.

The moment this language version is released I will move to Swift 6. In our project case it will happen. with no source code changes.

The actual targets are very different. For Rust is to be memory safe and available at any level starting from embedded. For Swift it is to be readable.

You are talking about the language but bringing up an example of creating an app for an Apple platform. Regardless of the language you will have to create app bundle structure, copy assets inside, add mobile provision and sign it.

If you ask me, those platform specific things should never be integrated part of the language.

As he mentioned in a forum post some years ago, Chris wanted the language to be more modular, but Apple's drive for adding features to it sets very different priorities.

To be fair, every new language version usually includes things that eliminate those special cases making writing the code more straightforward. Like the described support of functions in key paths, or the ability to set default global actor isolation.

Spans and inline arrays are the two missing pieces of performance puzzle Swift needed. I'm super hyped for the release!

A large removable standard library seems to be the optimal solution. It is there by default for everyone, but if needed for embedded scenario it can be removed, leaving only the core language features.

Are you going to use a 10 years old phone just because it still receives software updates? If so, good for you, but overwhelming majority of people will opt buying a new one.

Retina means high pixel density, not high resolution. And there are very few standalone displays on the market which can be called “retina”, unfortunately.

I think it will show you the confirmation code on the device. Then the scammer will call to learn the code.

The author confuses development for an Apple platform with using Apple's service API in development, and suggests to write for web instead. If you can use Apple Music API in web development (I don't know if you can) then you'll face exactly same issues as described, because the problem is this service's API.

Not protecting Foxconn, but I suggest you to compare their work conditions with other Chinese companies, where the competing mobile devices are manufactured. Problem is China and its borderline slavery labor conditions.

Thankfully, Apple started moving out to India and Vietnam.

The title should have been "Health insurance in America is too expensive".

Sadly, it does not provide the list of countries that blocked the library. Internet censorship is what I'm interested in here.

It is the most expensive power source. Cost is prohibitive without the state footing part of the bill. And depending on the type of power station, it is not as reliable too: remember past year France shut down few of their nuclear plants due to the draught causing water levels in rivers to drop? They needed that water for circuit cooling.

> I think greed is a major reason why those services don't take off.

Why, they did take off. There are several active remote play services in different countries. As I said, those are serving niche audience and there's no demand for them to grow any further.

> What the users want would be to have a gaming PC in the cloud - same experience as their own gaming PC but without the cost of ownership/maintenance and burden of physically having the machine and moving it.

I agree, but this is technically unachievable. Local connection will always have more hassle free bandwidth than a remote one. So, what happens in reality, the users trade the cost of their gaming PC ownership/maintenance (which is pretty affordable in case of game consoles) for cost of maintaining high speed and high reliability internet connection.

There were several instances when a person of interest suspected something's wrong with their phone and knowing they can be a target of a government surveillance they promptly submitted their devices to security companies. That's how some zero-days were uncovered by Apple.

Think of remote gaming as a computer where the connection between the computer itself and its input/output is stretched over the internet. It's bound to remain technically inefficient compared to local wires.

The goal, of course, is to make game running server shareable between different clients, right? But there already was a service to share your own idling PC with internet players. And unlike Google's servers it can be used to play locally by its owner.

But the biggest issue with the whole game streaming is the economy. What's more profitable for publishers and stores, to sell access to games which run on your hardware, or sell the copies of the games and let the players handle hardware cost themselves? The obvious answer leads for remote play services to live off the niche of people who would like to play games but can't afford to invest into hardware. If you compare the cost of a game console with the cost of games you'll understand there can't be a lot of people in this category.

TL;DR Remote play is doomed to stay on the fringes due to the economy and physics.

Only for mass attacks. A targeted attack will encounter the risk of the attacker being exposed.

Think journalists, politicians, public figures

I use many messengers, Signal too. It lacks in polish and features compared to all the others. Its security premise is undermined by insistence of using a phone number – which can be spoofed or taken over – to sign up.

I see it as the result of hacking spirit running the development, not the product team. Currently it can’t compete.

> Where is the hacker spirit here?

There was none to begin with. It was an attempt to build a business on top of a virtual macOS.

Edit: sorry, confused them with a different service. This one used previously published research on reverse engineering iMessage to build the business.

The historical precedent of dropping ARMv6 support from Apple SoCs, for instance. No matter what the secrecy level of a corporation is, no one will waste their CPU area for backwards compatibility when it's no longer demanded by the majority of the user base. It runs agains the economics of hardware production.

Source?

All large competing messengers have P2P encryption. Today it is what the customers expect, and if they are to stay competitive Meta must roll it out.

I own one, and can say that Motionflow produces uneven results. In certain scenes it kicks in, while completely ignoring others. Still has a way to go.

I wish for theatre film releases to move on to HFR instead of sticking to 24 FPS which was arbitrarily set by ancient technology limits.

Rosetta 2 expects certain capabilities from ARM CPU, which exists solely for the purpose of running x86 simulation. Apple will drop that in future versions of their SoCs and Rosetta will go as well.

If you target latest macOS that's an easy choice.

“Your IP has been blocked”. I’m using Apple’s private relay