bflat

There's also bflat [0]. Not an official Microsoft product, more of a passion project of a specific employee. "C# as you know it but with Go-inspired tooling that produces small, selfcontained, and native executables out of the box." Really impressive. Self contained and small build system. [0] https://github.com/bflattened/bflat

You can :) It just requires going out of your way a bit. It effectively works as C with better type system and generics (C++ lite if you will), that can be either JIT or AOT compiled (statically linked too). For example https://github.com/bflattened/bflat has a target flavour that does not support GC at all. I'm not saying it's an optimal choice for embedded, only pointing out that you can write allocation-free code with confidence. Patterns that allocate are known - predominantly boxing and closures. You can easily avoid both, you can also declare your structs as 'ref struct' which completely prohibits placing them on the heap, either as a box or as a part of heap-allocated memory inside some other object/struct.

There is a practical answer to this question: https://github.com/bflattened/bflat specifically the --stdlib:zero target. C# is quite a bit more than just enhanced C if you remove GC-reliant features as the generics and interface constraints enable a huge subset of features, alongside SIMD API, stack-allocated buffers and all sorts of memory wrappable in Span<T>s, which almost every method in the standard library that works on some sort of buffer accepts nowadays instead of plain arrays. You can also manually allocate objects - there are multiple ways to go about it and even with the presence of GC, there is a "hidden" but supported API to register a NonGC heap that GC understands when scanning object references. Though effective targeting is limited to much fewer count of platforms. Mono can target as low as ARMv6 but CoreCLR/NativeAOT ma

Static fields may be placed on Frozen Object Heap. The values of static readonly fields may not exist at all if the ILC's static constructor interpreter can pre-initialize it at compile-time and bake the value into binary or codegen. Tiered Compilation does a similar optimization but for all cases. This is with JIT though which is not usable in such environment. Otherwise, statics are placed in a static values array "rooted" by a respective assembly. I believe each value will be contained by a respective box if it's not an object. This will be usually located in Gen2 GC heap. My memory is a bit hazy on this specific part. There is no concept of globals in .NET the way you describe it - you simply access static properties and fields. In practice, you will not be running .NET on microcontrollers with existing mainline runtime flavours - ver

The sibling comment pretty much sums it up. But if you want more detail, read on: Generally, there are three publishing options that each make sense depending on scenario: JIT + host runtime: by definition portable, includes slim launcher executable for convenience, the platform for which can be specified with e.g. -r osx-arm64[0]. JIT + self-contained runtime: this includes IL assemblies and runtime together, either within a single file or otherwise (so it looks like AOT, just one bin/exe). This requires specifying RID, like in the previous option, for cross-compilation. AOT: statically linked native binary, cross-OS compilation is not supported officially[1] because macOS is painful in general, and Windows<->Linux/FreeBSD is a configuration nightmare - IL AOT Compiler depends on Clang or MSVC and a native linker so it is subject to rest

Strong replacement for Ocaml which is also performant and has rich ecosystem is F#. Technically speaking, Java and C# would serve somewhat different purposes and I would rather recommend Kotlin and C# with the former serving higher-level code goals better with existential types, SRTPs and overall strong type system and the latter for lower-level and/or performance-sensitive code with SIMD, pointers/byrefs, struct generics (zero-cost abstractions) and free/cheap interop. The only concern is how well Kotlin Native works today regarding compatibility. NativeAOT has seen a lot of work to improve this and scenarios that will never be supported (runtime reflection emit which needs JIT or arbitrary unbound reflection) are now well-documented. You may also be interested in Bflat[0] which has 'UEFI' as a target or even Zerosharp[1] as a demonstrat

I've been wondering how to integrate modern .NET Core into a custom build system (buck2) and was wondering similar things. There's this project I think is cool called bflat[1] that basically makes the C# compiler more like the Go compiler in the sense it's a one-shot single-use tool that can cross compile binaries natively. It's done by one of the people on the .NET Runtime team as a side project, and quite neat. I mostly use Visual Studio but I think in practice you're supposed to compile whole .dll's or assemblies all at once, which acts as the unit of compilation; I don't think the csharp compiler generates native object-files-for-every-.cs or translation unit, the kind of approach you'd expect from javac or g++. Someone please correct me if I'm wrong though! I'd like to learn more if there's a more granular/incremental unit of compila

It uses malloc in place of the GC’s allocator, so objects stay allocated forever: https://github.com/bflattened/bflat/blob/master/src/zerolib/...

It uses malloc in place of the GC’s allocator, so objects stay allocated forever: https://github.com/bflattened/bflat/blob/master/src/zerolib/...

I think it means that reference type objects stay allocated forever, but I'm not sure. From [0]: If an API allocates as part of its operation and doesn't return that as result, it's not good. We don't have a GC. This is all memory leaks. [0] https://github.com/bflattened/bflat/tree/master/src/zerolib

I'm having a hard time understanding how memory management works with the no-GC Zero stdlib. I see this but I don't get it. Anyone see a better explanation? https://github.com/bflattened/bflat/tree/master/src/zerolib

There's a GitHub issue about it: https://github.com/bflattened/bflat/issues/6

We changed the URL from https://github.com/bflattened/bflat to the project page. Both are nice, but the project page is more unique. Yes I know you can't be "more unique".

I feel like the "Java" way of doing things in C# is simply a byproduct of inertia and outdated habits. You can model domain with records in C# in a very concise manner (F# style), you can pass around raw memory slices with Span<T>. Writing simple CLI tools is incredibly easy with top-level statements and implicit usings, or even using bFlat [0] or ProcessX/Chell [1, 2]. [0]: https://github.com/bflattened/bflat [1]: https://github.com/Cysharp/ProcessX [2]: https://github.com/mayuki/Chell