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"?
One of the most convenient aspects of Air Drop for me is that it selects the fastest available connection between the devices and ability to work without both devices being on the same network.
I tried on three phones, two of which are using the same account, I'm reasonably confident I am technically competent to not make silly mistakes, though the best I've achieved was endless wait.
I had better success with IR and BT file transfers. Hell, even spinning a local http server (with python -m http.server) works better than quick share.
Yeah, ARC Raiders has a lobby system to sort people by aggressiveness.
Which is interesting, because the early Steam reviews loved the fact that the game was mostly cooperative. Most players were helpful or neutral, but some would attempt to kill you. This meant that running into other players was tense. Would they heal you? Would they help you take down a machine? Or would they rob you? You had to guess, and guess quickly.
Then there was a big influx of Twitch viewers who were just there for PvP.
I actually think the "mostly cooperative but not always" dynamic is a really interesting vibe, but probably a hard one for the developers to maintain.
There’s also the recent release of Marathon where I think some ARC players might be attracted if they want more of the sweaty gameplay. Definitely a different vibe with appealing aspects to both
There are plenty of real life examples of this, from softball leagues that self-sort based of levels of seriousness / competitiveness / aggressiveness, to people actively avoiding going into areas like investment banking or high-pressure sales because they have a reputation of being very aggressive.
You can’t always avoid people who are aggressive towards others, but I’ve found that my life is a lot more stressful when I work with aggressive people, so I actively try to avoid these situations and work in more collaborative environments.
reply