It doesn't need to, IPv6 has unique local addresses which is are non-globally reachable; I recall those had it's own can of worms depending on deployment but it's an option for private, local addresses.
EDIT: I also understood the GP comment to be getting around the problem of long IPv6 addresses and not actually making every machine globally accessible.
I might be misremembering but I recall that Nvidia's BlueField DPUs use virtio when communicating with the host machine. From what I gather searching around it's virtio-net in specific
> One issue I’ve heard from F# devs was the lack of ability to comfortably call C# asynchrony methods
This is no longer the case starting with F# 6: https://learn.microsoft.com/en-us/dotnet/fsharp/whats-new/fs... C# and F# can now transparently interoperate using the same main Task<T> type (in the past, this was done via community libraries for C#->F#, and F#->C# was always possible with |> Async.AwaitTask).
> Would the async experiment also imply better interop between .NET languages?
This is a good question. If a language already uses Task<T> and ValueTask<T>, the interop is already a solved problem (like with F#). However, this could allow to completely remove or at least significantly simplify the implementation for emitting state machines / resumable code / coroutines for asynchronous methods for any language that targets .NET 10+ (it will most likely get into 10 but is not guaranteed yet from what I've heard).
For example, a guest language could simply choose to emit calls to async methods with special modreq(?) attribute and the runtime would handle suspension, creating the closure for the state captured by asynchronous continuation and then subsequent resumption without any additional work of that guest language to be async-compatible. You could likely even write that by hand in IL with ILAsm. This is a significant improvement for a .NET as a hosting platform, and arguably makes it better than JVM at some high-level scenarios (because for low-level it already supports almost the entirety of what is expressible with C plus struct generics, and for FP it supports tail. prefix for call* opcodes for mandatory tailcalls required by recursive functions).
And for those in the camp of "function coloring considered harmful" (which I'm not a fan of but to each their own), you could even have a guest language that completely hides the fact that it performs such async calls underneath.
Erlang terms are, to a first approximation, the same as JSON for most relevant communication metrics.
To a second approximation it gets more complicated. Atoms can save you some repetition of what would otherwise be strings, because they are effectively interned strings and get passed as tagged integers under the hood, but it's fairly redundant to what compression would get you anyhow, and erlang term representations of things like dictionaries can be quite rough:
Even with compression that's a loss compared to '{"a":1,"b":2}'.
Plus, even if you're stuck to JSON one of the first things you do is shorten all your keys to the point they're as efficient as tagged integers on the wire anyhow ("double-quote x double-quote" can even beat an integer, that's only 3 bytes). Doesn't take a genius to note that "the_message_after_it_has_been_formatted_by_the_markdown_processor" can be tightened up a bit if bandwidth is tight.
It isn't clearly a loss over JSON but it is certainly not a clear win either. If you're converting from naive Erlang terms to some communication protocol encoding you're already paying for a total conversion and you might as well choose from the full set of option at that point.
This might be answered elsewhere but how does LVN in its current state handle server disconnects (and for prolonged periods of time, in say no coverage zones)?
We have the same strategy as LiveView. We attempt to reconnect when network is lost. There are methods for restoring your state as well that work in LiveView and LiveView Native
Ted's objection is perfectly reasonable, and the way that Linux works and has always worked internally. If an internal (not userspace) API changes then code that uses that API has to be fixed. He also quite reasonably says that it'll take time to understand the trade-offs of encoding constraints into the type system.
Bringing out silly and absurd strawmen attacks like "you're trying to convince everyone to switch over to the religion as promulgated by Rust" is anything but "perfectly reasonable".
anyway, the point of the resignation is not wanting to deal with all this, not necessarily taking a side, so I’m not even disagreeing with you. But obviously, it is a disagreeable atmosphere. I don’t find that debatable, even if that’s due to people feeling paranoid about a (nonexistent?) rust religious takeover.
I think we can all admit Rust definitely has its ideologues and cult acolytes.
Yes, it's really false. They weren't saying that maintainers couldn't change the API nor that the maintainers who changed the API had to update the Rust part, just that they needed to tell the Rust maintainers what they did and what they intended so that they could correctly encode their underlying assumptions in code.
In other words, they simply requested adequate documentation and the response was "I'M NOT LEARNING RUST AND YOU CAN'T MAKE ME", effectively. That is nontechnical nonsense
Yes, the burden on the C maintainers is low but not zero. In a shared project, other people matter too. If you don't like it you should just work on solo projects.
Not really, as the only point he made wasn't under discussion or in conflict at all. The bulk of the words he said were intended to deliver other messages. I took the time to explain it in some detail here: https://news.ycombinator.com/item?id=41396677
Do you by chance mean CVE-2024-{39924, 39925, 39926}?