There are also large trading/market making firms providing liquidity, especially on markets associated with up/down bets on crypto, stocks etc. They use all the options trading machinery they've already built for more 'respectable' venues like CME/Eurex etc, further squeezing the margins for retail traders.
They're active on bets that are even considered "meme" bets. Example: Jesus returning in 2026 - If you can get a loan at 4% as a big well respected trading firm and plonk it on Jesus not returning at 94 cents, you're making ca. 2% for 'free'. (Unless Jesus returns, in which case you have bigger problems than your portfolio pnl).
Not an expert in game development, but I'd say the issue with C++ coroutines (and 'colored' async functions in general) is that the whole call stack must be written to support that. From a practical perspective, that must in turn be backed by a multithreaded event loop to be useful, which is very difficult to write performantly and correctly. Hence, most people end up using coroutines with something like boost::asio, but you can do that only if your repo allows a 'kitchen sink' library like Boost in the first place.
> that must in turn be backed by a multithreaded event loop to be useful
Why? You can just as well execute all your coroutines on a single thread. Many networking applications are doing fine with just use a single ASIO thread.
Another example: you could write game behavior in C++ coroutines and schedule them on the thread that handles the game logic. If you want to wait for N seconds inside the coroutine, just yield it as a number. When the scheduler resumes a coroutine, it receives the delta time and then reschedules the coroutine accordingly. This is also a common technique in music programming languages to implement musical sequencing (e.g. SuperCollider)
Much of the original motivation for async was for single threaded event loops. Node and Python, for example. In C# it was partly motivated by the way Windows handles a "UI thread": if you're using the native Windows controls, you can only do so from one thread. There's quite a bit of machinery in there (ConfigureAwait) to control whether your async routine is run on the UI thread or on a different worker pool thread.
In a Unity context, the engine provides the main loop and the developer is writing behaviors for game entities.
> but I'd say the issue with C++ coroutines (and 'colored' async functions in general) is that the whole call stack must be written to support that.
You can call a function that makes use of coroutines without worrying about it. That's the core intent of the design.
That is, if you currently use some blocking socket library, we could replace the implementation of that with coroutine based sockets, and everything should still work without other code changes.
They don't need a multithreaded event loop. Single-threaded schedulers cover plenty of game-style work without hauling in Boost, and the uglier part is that async colors the API surface and control flow in ways that make refactors annoying and big legacy codebases harder to reason about.
Which is the reason only Linux kernel survives nowadays in such platforms.
Additionally there is an increasing number of embedded OSes alternatives with permissive licenses, meaning eventually not even the Linux kernel will be taken into account.
OOP has nothing to do with it. In your C++ example, foo(bar const&); is basically the same as bar.foo();. At the end of the day, whether passing it in as an argument or accessing this via the method call syntax it's just a pointer to a struct. Not to mention, a C++ compiler can, and often does, choose to put even references to member variables in registers and access them that way within the method call.
This is a Python specific problem caused by everything being boxed by default and the interpreter does not even know what's in the box until it dereferences it, which is a problem that extends to the "self" object. In contrast in C++ the compiler knows everything there's to know about the type of this which avoids the issue.
That's not true. I mean: it's true that it has little to do with OOP, but most imperative languages (only exception I know is Rust) have the issue, it's not "Python specific". For example (https://godbolt.org/z/aobz9q7Y9):
struct S {
const int x;
int f() const;
};
int S::f() const {
int a = x;
printf("hello\n");
int b = x;
return a-b;
}
The compiler can't reuse 'x' unless it's able to prove that it definitely couldn't have changed during the `printf()` call - and it's unable to prove it. The member is loaded twice. C++ compilers can usually only prove it for trivial code with completely inlined functions that doesn't mutate any external state, or mutates in a definitely-not-aliasing way (strict aliasing). (and the `const` don't do any difference here at all)
In Python the difference is that it can basically never prove it at all.
> This is a Python specific problem caused by everything being boxed
I would say it is part python being highly dynamic and part C++ being full of undefined behavior.
A c++ compiler will only optimize member access if it can prove that the member isn't overwritten in the same thread. Compatible pointers, opaque method calls, ... the list of reasons why that optimization can fail is near endless, C even added the restrict keyword because just having write access to two pointers of compatible types can force the compiler to reload values constantly. In python anything is a function call to some unknown code and any function could get access to any variable on the stack (manipulating python stack frames is fun).
Then there is the fun thing the C++ compiler gets up to with varibles that are modified by different threads, while(!done) turning into while(true) because you didn't tell the compiler that done needs to be threadsafe is always fun.
What is going on here is not, that an attribute might be changed concurrently and the interpreter can't optimize the access. That is also a consideration. But the major issue is that an attribute doesn't really refer to a single thing at all, but instead means whatever object is returned by a function call that implements a string lookup. __getattr__ is not an implementation detail of the language, but something that an object can implement how it wants to, just like __len__ or __gt__. It's part of the object behaviour, not part of the static interface. This is a fundamental design goal of the Python language.
> This is a Python specific problem caused by everything being boxed by default and the interpreter does not even know what's in the box until it dereferences it
That's not the whole thing, what is going on. Every attribute access is a function call to __getattr__, that can return whatever object it wants.
bar.foo (...) is actually bar.__getattr__ ('foo') (bar, ...)
This dynamism is what makes Python Python and it allows you to wrap domain state in interface structure.
You can also get private medical insurance in the UK. The cost is usually much lower than the US and quality is decent. NHS acts as an anchor keeping down premiums.
Teaching an undergraduate class or even a graduate class is still teaching. The author does not say he won't do that anymore.
The problem is about the fresh talent pipeline for researchers (i.e. PhDs). In many ways, elementary school and a Master's degree are more alike than a Master's and a PhD in the sense that you're learning prior art with clearly defined exam/project assessments and no expectation of making something truly novel in both elementary school and the Master's, while a PhD is all about discovering something nobody uncovered before. So, calling this a problem of not wanting to teach isn't quite right.
IMO, the article is rather highlighting a different problem; the former problem in this area was that only a tiny sliver of the best engineering/CS undergrads wanted go into research given the far more lucrative industry careers, and now the supply part of that market is about to vanish too due to agentic AI. This will basically kill the concept of an academic career as we know it and the point of the article is that we need to find a different model of advancing and funding science.
>You can also cut yourself with a kitchen knife but nobody proposes banning kitchen knives.
oh nice, i love this game.
you cant carry a kitchen knife that is too long, you cant carry your kitchen knife into a school, you cant brandish your kitchen knife at police, you cant let a small child run around with a kitchen knife...
literally most of what "the state" does is be a "nanny"
(not agreeing or disagreeing with google here, i have no horse in this particular race. but this little knife quip is silly when you think about it for more than 5 seconds)
In this example we still don't require you to register with anyone to buy a knife, get the blessing of some institution to sell knives, or, as in this case, get a certification before you can start making knives.
its crazy that different things, like knives and app stores, have different rules. maybe thats why the quip about the knife sounded super cool but fell apart as an analogy for this scenario when thought about for more than 5 seconds?
the point of my comment was that the state does implement a lot of rules (read: "is a nanny"), despite the claim otherwise.
I think it's important to consider the intent of those laws, too. They are primarily or even exclusively to prevent you from hurting others with knives. They are not really intended to protect you from cutting yourself in your own home. So I think the parent's comment still holds weight.
sorry, should say "carry", not "buy". most states have a maximum length you can carry (4-5.5 inches is common).
although, i would imagine at some length, it becomes a "sword" (even if marketed as a knife) and falls under some other "nanny"-ing. i have not googled that.
As kevin_thibedeau points out elsewhere in the thread, he's not necessarily wrong. In many states and foreign countries it's illegal to carry a large knife in public without a reason and I'm sure purchases are restricted in some places as well. Most people are more or less OK with that, it seems, so there historically hasn't been a lot of pushback.
Claiming they have the unrestricted right to scrape whatever information they want off the internet but complaining about it when others do to you and bringing out the 'China bad' card, just ironic
Somebody’s nervous about the competition, so they’re running a PR campaign. To me, though, this campaign hurts Anthropic more than anyone else. How can I trust the output of a model they can modify at will for certain clients? And who are they, after scraping the entire web, to complain about theft?
reply