viktorcode

They will, because a typical private plane passenger is already someone who chose to pay extra. The carbon tax will hit economy passengers harder.

> Not only is flying in a private plane just about the worst thing one can do for the planet, it is also one of the habits with the easiest substitutes.

Apparently, Vice don't get that private jets are also used to get someone into a random location in a shortest time possible. There's a demand, but no substitute for that.

It should be noted that the need for standard GUI doesn’t come from the users, who mostly prefer consistency among different apps within their OS of choice.

> Is the Pony language's GC a GC then? It runs at determinate times, namely when a behaviour (an actors' receive function, basically) finishes running...

It is. It might run when a behaviour finishes running, according to their docs.

That is expected. With different input data (what you call runtime condition) you get different result. With the same input data the determinism holds for RC, but not for GC.

The academia tends to call RC a form of GC. For programmers experienced in languages with manual memory management those are very different beasts.

See that last graph with memory overhead? Not everyone's definition of "better" allows for that.

> It’s possible to do this correctly if you actually read the docs and understand what you’re doing, using tools like weak pointers, but when you have hundreds of developers, many of whom got their job either by transferring from an android team or by just memorizing pat answers to all the “Ninja” algorithms interview questions (practically all of which have leaked on Leetcode and various forums), you can be sure that enough of them will fail to do so to create major issues with OOMs.

This pretty much nails down what I imagine is the main difference between GC and ARC: with the former you sacrifice performance for ease of use, and with the latter you improve performance by placing some additional work on the programmers.

> So reference counting works by the programmer knowing the lifetime of each object allowing them to only increment / decrement the refcount once, and trusting that the raw uncounted pointers they use elsewhere are always valid? There's another word we have for this: manual memory management.

Programmer, or compiler. In latter case it is automatic reference counting, which I never heard called "manual memory management".

> he also dismisses GC as inherently flawed

It's a compromise, on memory consumption and performance. Modern GCs are minimising the impact of those factors, but they still remain a part of the design.

RC is a performance compromise.

Deterministic means that running the same part of the program will take the same amount of time. Deallocating the same memory object graph is pretty much deterministic.

GC can throw a spanner in that by deciding that now is the time to do its thing.

> it's the myth that garbage collection always automatically means your program is going to be spending 80% of its time doing it and freezing for a second every five seconds the instant you use a language with garbage collection.

Not 80%, but still annoying enough to dump it: https://discord.com/blog/why-discord-is-switching-from-go-to...

As I heard those guys write allocation-free Java code in critical paths. Nothing allocated, nothing to collect.

Putting both under the same term is meaningless.

Reference counting and Garbage Collection have very clear difference: when the referenced objects are destroyed (not deallocated). In RC it happens when the count reaches zero. In GC it happens some time later. That difference is crucial for having or not having deterministic performance in your program.

For two messengers operating on two different encryption protocols the only way to talk to each other is to introduce an intermediary, which will decrypt and then re-encrypt messages, thus throwing p2p model out of the window.

Some optimists here telling that all messenger might follow a certain "standard" for transmitting encrypted messages. And in fact some messengers might, but this standard will be the lowest common denominator, i.e. the weakest security protocol all know.

For p2p model generating secure private key is paramount. Can this be guaranteed by every peer operating in a chat? Not unless they all made by the same team with high security standard.

> If you’ve been developing software for a while, you know that code has this natural tendency to turn into a mess.

That doesn't apply to everyone and every project. When people leading the project are experienced developers understanding clean architecture the mess is just an oversight which is local and can easily be corrected.

Yes. But this is how world works. I suggest you to try doing it yourself: get rid of all fossil-fuel based heating and cooking appliances, replace your car with an EV, and maybe set up your own renewable power generation if your area's electricity isn't green.

It is all doable, but it is expensive.

What's the point of producing low margin hardware if you don't control the sales on this platform?

Well, at one point of history it was "impossible to compete" against Nokia on mobile market. I find statements that we are living at the point of the market where competition is no longer possible to be very naive.

> As one example, making "core messaging functionality interoperable". How exactly does that work with end-to-end encryption?

Quite simply: it doesn't. It can only work the same way as iMessage interoperates with SMS, by throwing away security.

Overall, it's the most expensive way of producing energy. Long term it is on the way out.

Does WASM support SIMD?

> Using async and await with C#’s Task can be a bit of a headache with Godot, especially if you don’t realize that that most ways of executing an async Task in C# starts a new thread (or recycles one from the task thread pool).

Unity makes it much easier though.

I'm afraid it's worse. The law does apply, but what the law does is at the discretion of a civil servant handling the case. It isn't clear cut. As the result thousands of people who were living legally in the UK for decades found themselves facing possible deportations as they can't prove to the government that they have lived there for all those years.

Android has a wide plethora of devices, Apple can't make hardware catering to everyone's needs.

I concluded from experience that it always pays off to keep views separate from any logic except the bare minimum required for presenting the data on screen. This works regardless of UI framework.

I'm wondering what you needed to write unsafe code for? Could there be another way to get rid of reference counting for your use case?

Another question, have you tried using Accelerate framework to solve performance bottlenecks (or save yourself from having to write your own calc code)?

There is. You can easily nest UIKit/AppKit inside SwiftUI and vice versa.

In many countries your mobile phone number is too linked with the ID. So technically government already can watch your movements if you are carrying a mobile phone.

> When I ported individual sections of functionality, the Swift source typically measured 30% the size of the corresponding C++ code.

This is impressive.