andygocke

6 ms·

1.
by andygocke 1y ago
Yeah but we have codegen bugs in .NET as well. The biggest difference that stood out to me in this write up, is we would have gone straight for “coredump” instead of other investigation tools. Our default mode of investigating memory corrup
2.
by andygocke 1y ago
There are two types of initializers: internal and external. Internal are inside the type, like field and property initializers. External are outside, like object initializers, collection initializers, and ‘with’ clauses. Internal initialize
3.
by andygocke 1y ago
> MS have done is to outsource the issue to all C# devs Let's be clear: breaking dozens of tools because of a change to the IL format also outsources an issue to all C# devs. The .NET IL format has been basically unchanged since .NE
4.
by andygocke 1y ago
Unfortunately, there are alternatives to this behavior, but they all have other downsides. The biggest constraint was the schedule didn't support a new version of the .NET IL format (and reving the IL format is an expensive change for
5.
by andygocke 2y ago
Hi, I own the Native AOT compiler and self-contained compiler for .NET. Self-contained will work fine because we precompile the runtime and libraries for all supported platforms. Native AOT won't, because we rely on the system linker a
6.
by andygocke 2y ago
I guess people have different experiences as I don’t see the React changes as improving the mobile experience: just the opposite. I often interact with GitHub by browsing through the file tree and various links. But the new react renderer b
7.
by andygocke 2y ago
> First, primitive operations for crypto are intrinsics in Java and operate without FFI at all. This is a pretty strange assertion given that I didn’t specify the crypto operation I wanted to perform. Is XAES-256-GCM available in the Jav
8.
by andygocke 2y ago
Yes, we considered that and implemented a solution. Effectively, the runtime will generate thunk methods that will invisibly bridge between the two worlds. Calling (and overriding) regular async methods with runtime async methods will be st
9.
by andygocke 2y ago
I agree with your general point, that it depends on your specific problem how difficult this is, but I disagree about how common or easy to work around. Regarding > But the FFM API does not directly expose Java objects to native code at
10.
by andygocke 2y ago
Ah, I see. You were saying that green threads can usually be scheduled on multiple os threads and take advantage of parallelism. Yup, I agree. Apologies for the confusion.
11.
by andygocke 2y ago
Well, any additional FFI overhead, right? The cost for exposing very little tends to be that marshaling costs more due to the requirement that values be copied between domains rather than shared.
12.
by andygocke 2y ago
> The Gleam example has all the convenience and readability of its C#/Python counterpart - but without the downsides. This was mentioned in the write-up, but the big downside is interop. Green threads have significant downside when
13.
by andygocke 2y ago
In practice we don't think there will end up being tradeoffs in async2 vs. async1. If you look below, at the "JIT state machine" section, you'll see that async2 looked better and the GC behavior differences were probably
14.
by andygocke 2y ago
I'm not sure that the original description is precisely correct, but yours isn't correct either. Basically, you can't treat green threads just like "a multi-threaded runtime" and have it just work. That is, a 1:1 ma
15.
by andygocke 2y ago
I’m the author of the original issue — I agree, we’ll have to ensure the struct layout is solved. I think the only thing that makes sense is to just waste a little space and store the fields side-by-side. In almost all cases where people wo
16.
by andygocke 3y ago
You're right -- there are a lot of tradeoffs here, and one solution isn't necessarily better. What Native AOT offers is very small binaries, with very fast startup, and smaller working set. It can also be integrated as a standalon
17.
by andygocke 3y ago
.NET 8 will support macOS, and yeah I think your approach of basically re-implementing much of the SDK logic in bazel is probably your best bet for a reliable experience. At the same time, it's obvious that that's a considerable c
18.
by andygocke 3y ago
> Separate thought: .net AOT is still very much experimental. All sorts of things are silently incompatible with it, either in the "refuses to build" or the "crash at runtime" way. I'd only use it for small proje
19.
by andygocke 3y ago
> I couldn't find any compile-to-obj command with flags and such, instead there's a `dotnet` command that takes its input via a monolithic `.csproj` XML file and spits out a fully-formed binary FYI I'm the lead of the Nati
20.
by andygocke 4y ago
I don't think this works... It looks like FetchPersons is free in the body of the receive, and I can't see any indication of the synchronization points in the actor. I mean, maybe every function in the actor is implicitly synchro
21.
by andygocke 4y ago
Thanks for the feedback! If you have some details and want to post them on https://github.com/dotnet/runtime , we can include them in planning. As you might have guessed, this is a pretty huge long-term project and many