Apple does not adhere to EU law. It's their task to either go with the local law, or leave their customers hanging. And I rightfully express my disappointment that they currently do the latter.
They do adhere to the law perfectly by not providing a law breaking feature. If you don't like the way the law allows that, you should address your complaints to the lawmaker.
You mean DMCA. It is not an antitrust framework. Europe has pretty robust anti-trust framework. DMCA is an attempt to regulate companies that cannot be legally considered monopolies, and that do not run afoul of any pre-existing EU regulation.
Just for that case a new category of business classification was invented: the gatekeepers, and coincidentally almost all of those gatekeepers are American companies. Unlike antitrust regulation and other EU regulation that wan't based on clearly observed harm to the consumers, as otherwise that would have been covered by existing laws. It was solely designed to prevent businesses to have a potential ability to do something anti-consumer.
DMCA is the Digital Millennium Copyright Act, a US law. DMA is the Digital Markets Act, a EU law.
It is in fact an antitrust law. It basically argues (correctly in my opinion) that Apple and other companies have created new markets inside of their products. And in those markets they exert total control, including charging developers extortionate fees, forcing them to use their subpar and expensive payment systems or restricting what users can run on the devices they own & a lot of paid money for.
Sorry, my mistake. DMA. However, it runs counter to the definition of antitrust law, that is the law that applies to the trust or a monopoly, an entity that controls the market. DMA instead applies to the companies of certain size, regardless whether they have market control or not.
It's a matter of interpretation. From the DMA's perspective, the iPhone is a market and thus Apple has a monopoly on that market. Likewise they consider MS to have monopoly control of the Windows market.
That reinterpretation would have make Apple a monopoly and thus other anti-trust laws would apply, which did not happen. As I said: they are introducing new category, the gatekeepers, for the sole purpose of making the law applicable.
I think you mean DMA, not DMCA. DMCA mostly protects copyright holders. DMA is about protecting users and competitors from platform lock-in. Bending for Apple would just make that lock-in harder to challenge.
DMCA provides some rather important protection for service providers (including small-scale services like web forums, not just ISPs and web hosts) - it makes them not liable for copyright violations by their users, so long as they take down infringing content upon receipt of a DMCA notice.
Precisely. What it replaced was rightsholders suing web services (like a forum or web host) as a first resort, which was a much more cumbersome and painful process for all parties.
> If it was more painful for the suing party, it was a good thing.
It's a lot easier for a large plaintiff - like a record label, a movie studio, or a software publisher - to file a lawsuit than it is for a small defendant like a web site operator to defend against one.
You should remember that according to a court testimony the whole European area (which goes beyond EU) gives Apple 7% of their revenue, whereas breaking DMCA may incur penalties of ups to 10% of global turnover.
Those numbers make withholding "risky" products a no-brainer strategy. Also, those numbers put a hard limit of how much Apple will want reevaluate their general strategy of tightly integrated first-party software.
I don't think people buy Macs for ideology. They buy cause they like it. Framework, on the other hand, is more ideological proposition than practical. Which is fine, because whatever your choice is it should make you feel comfortable.
If I understand correctly, Go language praised in the article still has red and blue functions, only now they the colours are handled implicitly, and you as a programmer reading the code will have harder time guessing which is which on the call site.
Go (and other language with threads) implicitly run inside the "async IO monad." In the function color analogy, what this means is that all functions are red, and the "ordinary" function call corresponds to "await" in languages such as JavaScript or C#.
Async/await is one implementation of cooperative concurrency, where the programmer must explicitly annotate the points where a context switch may occur. However, one can imagine a program transformation that marks every function as async, and makes every function call an await. After making that transformation, the async/await annotations would no longer be necessary. The end result is pre-emptive concurrency, where the runtime may potentially interrupt the active thread at any function call.
To make another analogy, Haskell requires all IO actions to run in the explicit IO monad, while most languages (C, Java, JavaScript, etc.) do not distinguish between "pure" and "impure" functions. Therefore, C, Java, and JavaScript could all be said to implicitly run in the IO monad.
Async IO is also an instance of a monad. In JavaScript, all async functions must run inside the explicit async IO monad, while Go does not distinguish between async and sync functions. Therefore, Go implicitly runs in the async IO monad. This is similar to the aforementioned distinction between cooperative (made explicit to the programmer) and pre-emptive (handled implicitly by the runtime) concurrency.
In fact, Eugenio Moggi, the PL theorist who realized monads could describe programming languages, was not looking for a programmer-facing abstraction. Rather, he was trying to describe the "implicit" monad in a programming language's semantics (such as the IO monad in most programming languages, or the async IO monad in Go).
>> Go language praised in the article still has red and blue functions
This is my principle point of disagreement with the OP comment in this thread. Your response is either not meant for me, or is meant to agree with me, but I'm really not sure but you write:
> In the function color analogy, what this means is that all functions are red
and
> while Go does not distinguish between async and sync functions
Which was my point. Go does not have the function color problem (around sync/async) because it does not color its functions that way.
I was not looking to disagree with your point, I only wanted to make additional commentary. Sorry if my comment came across the wrong way.
I do think "There are no function colors in Go in the way being discussed," versus "all functions [in Go] are red" are two slightly different ways of formulating the same set of facts, and the distinction between them is insightful, so that was what I wanted to touch upon. Namely, I wanted to point out that there is an "implicit" color within the programming language itself.
> The functions are still coloured, just implicitly. IYKYK to spawn a goroutine or not ts.
In Go, you can choose to either block on a function call or to execute it as a go routine. The function has no "color" in the sense of the article.
If you want to print asynchronously, you can with a `go fmt.Println("Hello")`, or you can block on that print and remove the `go `. There is no color to any function. And the function containing that, it also has no color. It can be called synchronously or spawned as a go routine, Go makes no distinction between the kinds of functions that can be used each way.
Say you have a function like validate_user(). In Go, should you block the main thread on this call, or fork and join? What if it makes a DB request and now your UI is blocked for 2 seconds or something? You need to know implicitly you need to call validate_user() in a goroutine, and then deal with forking and joining manually. If it's explicitly coloured as async, you know.
In most async/await languages you can run async functions as sync, eg. Tokio's block_on method or C#'s .Result.
I think you're missing something. Go's functions are all blue, not all red. As far as I know, the callers of async functions with Rust's Tokio and C#'s Tasks themselves need to be async; not the case for Go.
Concurrency is usually a mix of goroutines and channels. There is no inherent link between caller and asynchronous callee. You can use goroutines without channels, and channels without goroutines.
You can write "go" to launch any function call in its own goroutine, but you cannot get a return value from it. This isn't valid:
user_is_valid := go validate_user(u)
The idiomatic way you can do that is to use a goroutine and a channel:
ch := make(chan bool)
go func() { // runs asynchronously
ch <- validate_user(u) // blocks until it can send
}()
user_is_valid := <-ch // blocks until it can receive
return user_is_valid // ta-da, blue function returning red function result
I don't think it's a boon to have functions "coloured for you" to tell you that they might block. On the other hand, functions that would block tend to accept a Context parameter to let you control what they should do. It's a major indicator that the function's probably going to do something async, but it doesn't have to.
Well, the benefit of async/await is that you can just do
let user_is_valid = validate_user(u).await
But you can also pass around future values. It's pretty dang ergonomic, the tradeoff is that it requires more ceremony to block on async functions (and is not even possible in JS). This was considered a potential problem 10 years ago but we've discovered since than that it's not really an issue at all.
My point about the colouring is that it's actually nice to have explicit colouring, in go the asynchronicity of functions aren't encoded by the type system but in practice you still handle them differently. You can't just call one of them without passing in things like context, or handling channels without refactoring anyways.
I think we're just seeing different sides of the same coin. Go's idiomatic code would be:
user_is_valid := validate_user(u)
i.e. you have no special handling needed, it fits anywhere. You don't even know async is or isn't involved, and it wouldn't matter for correctness if it did. If you want to make it async, you get to do that yourself.
However, the evolution of that design has resulted in use of shared and nested Contexts in order to coordinate state and lifespans across goroutines, which is why they expose this parameter. And if you don't care, you can always use context.Background() for the value. Not only does it provide that synchronisation, but also it made cancellation and timeouts simple and standardised (obviously, async frameworks of other languages have their own idioms for this)
It is a downer, but I would like to test the performance first in the practical scenario. I've been working on a project where tagged unions would literally saved us from complexity. If that to happen again later I would go for boxed implementation and swallow up the penalty.
This is just pedantic. "Algorithm" is obviously shorthand for: a recommendations system that shows me things I didn't explicitly opt into.
Compare e.g. Mastodon vs Twitter or Bluesky. The former simply won't show you anything you didn't explicitly subscribe to, and there's no hidden ranking system.
The law is not a computer program. It is up to human interpretation. The law merely needs to define the intent, which is actually fairly easy to explain: you're not a common carrier if you're mediating and promoting and ranking and pushing beyond what the user has subscribed to with their choices.
You can get technical that "sorting" and "filtering" is a form of that, but you'd be applying the lens of a software engineer, not a lawyer.
It is pedantic, and you have to be pedantic when talking about laws and regulations. The vaguely written laws have the tendency to be interpreted in the most restrictive way possible by the executive branch.
> "Algorithm" is obviously shorthand for: a recommendations system that shows me things I didn't explicitly opt into.
In that interpretation that is applicable to any form of broadcast, including TV and radio, driven by the user ratings of their previous programs.
I understand how you feel but you can't be like "I want the law to make things worse for these businesses" and then when asked to define the boundaries of the law you say "that's pedantic."
In many cases technology laws are myopic in that they only see the most massive websites and forget that there is a whole www outside facebook. Is sorted by likes/upvotes a recommendation? Is the total of likes of your friends a recommendation? Can only data points from the last week be considered? Can there be a falloff by age?
At which point does the weights of the variables start to constitute a "recommendation"?
reply