> Still not sure how I feel about China of all places to control the only alternative AI stack, but I guess it's better than leaving everything to the US alone.
Fully agree. From a US perspective, that sucks. For everyone else it's pretty great.
At this point the world's opinions of China are better than those of the US in some polls. One country invests and helps build infrastructure on a massive scale globally, the other alienates allies, causes countless conflicts, and openly threatens to end civilizations.
Indeed, even if one isn't partial to China, there's reasons to be glad that an increasingly hostile US has powerful competition.
> This is about who will dominate the world of tomorrow.
For this you'd need a technological moat. So far the forerunners have burned a lot of money with no moat in sight. Right now Europe is happy just contributing on research and doing the bare-minimum to maintain the know-how. Building a frontier model would be lobbing money into the incinerator for something that will be outdated tomorrow. European investors are too careful for that - and in this case seem to be right.
> Indeed, even if one isn't partial to China, there's reasons to be glad that an increasingly hostile US has powerful competition.
This is how I see it. The US has openly threatened multiple times to annex my country, and has repeatedly threatened every western nation. Letting the US have a monopoly on... well.. anything, is really bad for the world. The more countries that have their own production for various critical things like computer chips, medicine, etc, the better it is for the world at it distributes power.
People in the US don't seem to understand that with the current administration the US is seen as a potentially very hostile nation. While I don't think China is a friend to Canada or the west, at least it provides alternatives when the US tries to use it's monopolies against us. And vice versa too.
>Building a frontier model would be lobbing money into the incinerator for something that will be outdated tomorrow. European investors are too careful for that - and in this case seem to be right.
Strong disagree here. Mistral does great work, in the long term being a few months or even a year behind is a non-issue. Also Cohere just merged with Aleph Alpha to continue producing foundational models. It's extremely important that the middle powers continue to do this.
Yeah it's confusing. I mean China has work camps for Uighurs and is very brutal on Tibetans etc. OTOH, their leader is not setting the world on fire every second week and compared to Trump seems like the paragon of reason on the surface. Of course we know it's a facade but man what crazy times to live in.
China can't project power globally because the US has them locked in place. There is a constellation of US allies and military bases surrounding China's coast.
It's extremely (read: extremely) naive to think that China keeps to itself because they don't have global power ambitions.
Look at the South China Sea, the one playground that the US stranghold allows them to play in...they don't give a fuck about anyone else's territory there.
If Trump acted more like Xi with regards to public speaking, but the actions were still the same, thing would be a lot different.
My point is that Trump could sign/execute/order all the same exact things he's done, but if I just never spoke about it, or kept hidden like Chinese do, he would be compared MUCH differently.
If someone like Trump could talk smarter, he would be smarter and would do things smarter.
That would also make him a lot more dangerous. After all in his first presidency he was still the man behind the biggest military on the planet but he knew shit on how to leverage this. In his second term he is even more loose but loose is tempertantrums and simple short sighted strategies. Easy to read, hard to accept.
You do realize that the US has a greater percentage of it's citizens in prison than any other country, including China?
In the US its not the Uighurs or Tibetans who are being oppressed - it's the blacks and immigrants. The US elected a president who characterizes immigrants as rapists and murderers (while he himself is a convicted rapist, suspected pedophile, and wants to commit war crimes in Iran).
The facade, believed by many Americans, is that USA is the land of the free, a democracy (despite no popular vote) one of the good guys, but actions say otherwise.
Function coloring also only applies to a few select languages. If your runtime allows you can call an async function from a sync function by pausing execution of the current function/thread whenever you're waiting for some async op.
Libraries like Tokio (mentioned in the article) have support for this built-in. Goroutines sidestep the issue completely. C# Tasks are batteries included in that regard. In fact function colors aren't an issue in most languages that have async/await. JavaScript is the odd one out, mostly due to being single-threaded. Can't really be made to work in a clean way in existing JS engines.
“Function coloring” is an imaginary issue in the first place. Or rather it's a real phenomenon, but absolutely not limited to async and people don't seem to care about it at all except when talking about async.
Take Rust: you return `Result<T,E>`, you are coloring your function the same way as you are when using `async`. Same for Option. Errors as return values in Go: again, function coloring.
One of your nested function starts taking a "serverUrl" input parameter instead of reading an environment variable: you've colored your function and you now need to color the entire call stack (taking the url parameter themselves).
All of them are exactly as annoying, as you need to rewrite the entire call stack's function signature to accommodate for the change, but somehow people obsess about async in particular as if it was something special.
It's not special, it's just the reflection that something can either be explicit and require changing many function signatures at once when making a change, or be implicit (with threads, exceptions or global variables) which is less work, but less explicit in the code, and often more brittle.
Function coloring does not mean that functions take parameters and have return values. Result<T,E> is not a color. You can call a function that returns a Result from any other function. Errors as return values do not color a function, they're just return values.
Async functions are colored because they force a change in the rest of the call stack, not just the caller. If you have a function nested ten levels deep and it calls a function that returns a Result, and you change that function to no longer return a result because it lost all its error cases, you only have to change the direct callers. If you are ten layers deep in a stack of synchronous functions and suddenly need to make an asynchronous call, the type signature of every individual function in the stack has to change.
You might say "well, if I'm ten layers deep in stack of functions that don't return errors and have to make a call that returns the error, well now I have to change the entire stack of functions to return the error", but that's not true. The type change from sync to async is forced. The error is not. You could just discard it. You could handle it somehow in one of the intervening calls and terminate the propagation of the type signature changes half way up. The caller might log the error and then fail to propogate it upwards for any number of reasons. You aren't being forced to this change by the type system. You may be forced to change by the rest of the software engineering situation, but that's not a "color".
For similar reasons, the article is incorrect about Go's "context.Context" being a coloration. It's just a function parameter like anything else. If you're ten layers deep into non-Context-using code and you need to call a function that takes a context, you can just pass it one with context.Background() that does nothing context-relevant. You may, for other software engineering reasons, choose to poke that use of a context up the stack to the rest of the functions. It's probably a good idea. But you're not being forced to by the type system.
"Coloration" is when you have a change to a function that doesn't just change the way it interacts with the functions that directly call it. It's when the changes forcibly propagate up the entire call stack. Not just when it may be a good idea for other reasons but when the language forces the changes.
It is not, in the maximally general sense, limited to async. It's just that sync/async is the only such color that most languages in common use expose.
> If you are ten layers deep in a stack of synchronous functions and suddenly need to make an asynchronous call, the type signature of every individual function in the stack has to change.
See my other post about the point. If you "just" turn an async back into a sync call by completely blocking the async scheduler, yes, you've turned the async call back into a sync call, but you've done that by completely eliminating async-ness. That's not a general solution. That is exactly what everyone back when Node was promoting this style spent paragraph upon paragraph warning you not to do, because it just punts by eliminating the asyncness entirely. "Async is great when you completely discard it" is not a winning argument for async... which is OK, because it's not the argument anyone is making.
> If you "just" turn an async back into a sync call by completely blocking the async scheduler,
I am not doing that. The caller (which is the only one being blocked here) is sync anyways and just wants to call an async function, so no async scheduler is blocked.
If you are ten nested functions deep in sync code and want to call an async function you could always choose to block the thread to do it, which stops the async color from propagating up the stack. That's kind of a terrible way to do it, but it's sort of the analog of ignoring errors when that innermost function becomes fallible.
So I don't buy that async colors are fundamentally different.
You can exit an async/IO monad just like you can exit an error monad: you have a thread blocking run(task) that actually executes everything until the future resolves. Some runtimes have separate blocking threadpools so you don't stall other tasks.
If you have something in a specific language that does not result in having to change the entire call stack to match something about it, then you do not have a color. Sync/async isn't a "color" in all languages. After all, it isn't in thread-based languages or programs anyhow.
Threading methodology is unrelated though. How exactly the call stack is scheduled is orthogonal to the question of whether or not making a call to a particular function results in type changes being forced on all function in the entire stack.
There may also be cases where you can take "async" code and run it entirely out of the context of any sort of sceduler, where it can simply be turned into the obvious sync code. While that does decolor the resulting call (or, if you prefer, recolor it back into the "sync" color) it doesn't mean that async is not generally a color in code where that is not an option. Solving concurrency by simply turning it off certainly has a time and place (e.g., a shell script may be perfectly happen to run "async" code completely synchronously because it may be able to guarantee nothing will ever happen concurrently), but that doesn't make the coloration problem go away when that is not an option.
Here's the list of requirements: 1. Every function has a color. 2. The way you call a function depends on its color. 3. You can only call a red function from within another red function. 4. Red functions are more painful to call. 5. Some core library functions are red.
You are complaining about point 3. You are saying if there's any way to call a red function from a blue function then it's not real. The type change from sync to async is not forced any more than changing T to Result<T,E>. You just get a Promise from the async function. So you logically think that async is not a color. You think even a Haskell IO-value can be used in a pure function if you don't actually do the IO or if you use unsafePerformIO. This is nonsense. Anything that makes the function hard to use can be color.
And you appear to have read my post way too hastily to get to the point you wanted to make, because I can't even correlate what you're saying to what I actually said, particular the argument that I'm "stuck" on async being the only color.
I have inside information about how that is not the case since I typed, but deleted before posting, some points about how Haskell is one of the few languages that can create arbitrary numbers of colors in libraries, but it started spiraling when I started trying to characterize when a new color was created. It is, for instance, not as simple as "it's monadic", because types that implement "monad" that allow extracting of the value like List or Maybe don't create colors even though IO does, so I just deleted it, especially when my thoughts turned to trying to explain how Haskell is also one of the few languages that can abstract over color. (Although I gather zig is giving it the college try with sync/async.) Using monad as an example is just an invitation to trouble since way more people think they understand it than actually do.
A function simply taking an annoying amount of parameters is not a color problem, because the entire essence of "color" is the transitivity. If you don't have the transitivity flowing up the call stack, you don't have color. Just being "hard to use" is not sufficient... the proof of which being that we've had "hard to call" functions for many more decades than we've had widespread "color" in our functions and nobody was talking about this transitivity problem until we started having async functions. That is a new problem... I mean, new on the relevant time frames... the whole color thing has been ongoing for years now, but it's still relatively new.
A function taking a new parameter that you have to pass all the way down the call stack is a color. If you have a large Haskell application, and then you decide that something 50 functions deep needs to access the user database, you've added a color. It's color if it affects the whole call stack in reality. You could pass an empty user database, but you obviously won't.
You can still use a function that returns result in a function that uses option.
And result and option usually mean something else. Option is a value or none. None doesn't necessarily means the function failed. Result is the value or an error message. You can have result<option, error>
That's different then async where you can call the other type.
Function coloring is an effect. If the language makes a distinction between sync and async, then it has that effect. Just because there are escape hatches to get around one effect doesn't really change this fact.
Like in Haskell there is the IO monad used to denote the IO effect. And there are unsafe ways to actually execute it - does that make everything in Haskell impure?
This allows one to sprinkle implicit returns throughout the entire body of one's function and I'm not sure what to think of that.
Also the syntactic rules around control flow within elements/literals/identifiers seem a bit inconsistent. Some things require curly braces, others don't.
By the way you can probably implement this to 90% without needing a compilation step for React. Just track what elements get created by react factory functions during the function component execution (similar to how hooks work), and treat any that weren't passed as children to another as implicit returns. This only breaks when they're used verbatim in expressions, but this library doesn't allow doing that without a special wrapper tag either. A library approach should probably add a lint rule to disallow it.
The only thing you can't implement as a library is some of the syntactic sugar that allows one to directly put control flow within elements without wrapping the thing in an IIFE.
Overall a bit too much magic for my taste. The style stuff is nice, but I'd prefer a library approach for that in a react app as well.
Finally here's something with rather strange output:
export component Test() {
<div>{Date.now()}</div>
if (Math.random() > 0.5) {
return;
}
<style> div { color: 'red' } </style>
}
So you either get the date when the component was most recently rendered, or the date when the page was loaded with a 50% chance each (should probably pick one). And the CSS is unconditional, which is not very intuitive.
I'm not sure how much of that is intended, and how much is a bug.
Not to mention that those devices all support regular EPUBs out of the box, and so you can still put new content on them today.
Of course, you'll get a bit more out of them if you convert your EPUBs to KEPUBs with Kepubify[0], but the point remains that Kobos are supplemented by their cloud/connected features, not inherently dependent on them.
I don’t understand why anyone would choose a Kindle over the Kobo range of devices.
When I bought the Kobo Clara it was also a significantly better device purely on hardware specs. It was slightly more expensive, but that’s more than paid for by how long it’s already lasted me, whereas my spouse’s kindle (bought before we discovered Kobo), is already e-waste.
Kobo has also officially tied up with iFixit to provide official fixing guides and parts, allowing for relatively inexpensive hardware repair (to be fair, the battery replacement process I went through my device was quite annoying due to the waterproofing layer, but it worked, and my device is much older than their iFixit partnership, so hopefully the newer devices have repairability more in mind).
Calling DotA just a custom map is a bit of a stretch. That was merely the packaging. These "custom maps" had various scripting capabilities that made them more than just some terrain.
Also custom maps are mods by definitions anyways, with the exception of games where the creation of maps is a component of gameplay.
I mean, to those who played them, 'custom map' is basically just a term of art indicating the things you said. In the parlance of the mid-2000s WC3 scene, you would call them custom games or custom maps.
Or, if you were slightly older, you might call them UMS, as they were in Starcraft. Short for "Use Map Settings", indicating that the game logic should come from the scripts and triggers in the map file rather than the built-in logic for ladder games.
> Somebody is making all those faked videos and photos.
Yeah. Bored 15 year olds for laughs.
We had a great time putting the most ridiculous stuff out there.
Having a classmate who was actively buying into tons of conspiracy theories (9/11, cold sun, hollow earth, ...) was just the cherry on top and probably what got us into it in the first place.
I can call my ISP and someone will pick up within 5-10 minutes. Sometimes instantly. For a 40 euro/month contract.
These guys have millions of customers. At least in this country fast and competent customer service is the main factor that differentiates them from their competition, which is cheaper but can be a pain in the butt. This seems to be worth the extra 5-10 bucks to millions of people.
Boastful lies like this are a telltale sign of vibe-coded projects. Approximately, an AI is making word-association guesses from its context window, and arranging those guesses into grammatical forms that human RLHF reviewers find impactful. Frequently the lies are obvious if you have a mental model of the project, which the AI doesn't have.
If they didn't have an LLM wipe their DB, they would've found another way. At least that's the feeling I got reading that.
reply