51–60 of 71 posts
Earlier quoted context omitted.
Also, if you compile Ahead Of Time (AOT) you can cut down on the features and get basically as small a subset as you want of the libraries. IMHO C# and dotnet are really starting to become very impressive.
AOT requires a lot of fiddling around, and might break the application unexpectedly, with very weird errors. It is mostly targeted to Blazor (WASM) and for serverless functions. The default runtime and JIT are fine for most use cases.
• Supported return types: ◦ Collections: ..., List , ... ◦ Note: Arrays are not allowed as return types because they are mutable. Use IReadOnlyList instead. I don't understand. Why is List allowed then if it's mutable?
Array also implements IReadOnlyList if I'm not mistaken. I think C# doesn't really have immutable collections, they just can be typecasted to IReadonly* to hide the mutable operations. But they can always be typecasted back to their mutable base implementation. The only real immutable collections I know of, are F#s linked lists.
Earlier quoted context omitted.
Also, if you compile Ahead Of Time (AOT) you can cut down on the features and get basically as small a subset as you want of the libraries. IMHO C# and dotnet are really starting to become very impressive.
AOT requires a lot of fiddling around, and might break the application unexpectedly, with very weird errors. It is mostly targeted to Blazor (WASM) and for serverless functions. The default runtime and JIT are fine for most use cases.
> AOT requires a lot of fiddling around, and might break the application unexpectedly, with very weird errors.
> It is mostly targeted to Blazor (WASM) and for serverless functions.
[1]: https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
[2]: https://learn.microsoft.com/en-us/dotnet/core/deploying/trim...
This seems like the kind of feature that should be built into MSBuild.
Earlier quoted context omitted.
Can't you already do that with embedded resources?
Yes, you can. But it's a bit cumbersome. The API to read them is not really intuitive, they are only accessible as a Stream, so they need to be either read every time into a string (new allocation, slow), or you need a helper that reads them once and keeps them in memory. I think there are also a lot of gotchas around naming and listing them. In modern code I don't see them that often anymore.
• Supported return types: ◦ Collections: ..., List , ... ◦ Note: Arrays are not allowed as return types because they are mutable. Use IReadOnlyList instead. I don't understand. Why is List allowed then if it's mutable?
Array also implements IReadOnlyList if I'm not mistaken. I think C# doesn't really have immutable collections, they just can be typecasted to IReadonly* to hide the mutable operations. But they can always be typecasted back to their mutable base implementation. The only real immutable collections I know of, are F#s linked lists.
Earlier quoted context omitted.
Modern C# and .NET are great. It still suffers from the bad reputation of the Windows-only .NET Framework. It's still a quite heavy platform with a lot of features, but the .NET team invested a lot of time to make it more approachable recently. With top level Programs and file-based apps[1] it can be used as a scripting language now, just add a shebang (#!/usr/local/share/dotnet/dotnet run) to the first line and make…
Also, if you compile Ahead Of Time (AOT) you can cut down on the features and get basically as small a subset as you want of the libraries. IMHO C# and dotnet are really starting to become very impressive.
"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.
Earlier quoted context omitted.
I love (and heavily use) source generators, but the development experience is godawful. Working with the raw Roslyn types is painful at best and this is compounded by them having to be written against .NET Standard, severely limiting the use of newer .NET functionality. Eventually I want to write a good baseline library to use for my source generators -- simplifying finding definitions with attributes, mapping types…
I agree, .NET Standard limitation unnecessarily complicates development experience. I think it's because some tools (Visual Studio) is still use legacy .NET Framework. I don't understand why they didn't integrate them via out of process architecture into these tools, since source generators didn't exist in the legacy framework anyway. I sometimes generate code from plain CLI projects (avoiding source generators altog…
• Supported return types: ◦ Collections: ..., List , ... ◦ Note: Arrays are not allowed as return types because they are mutable. Use IReadOnlyList instead. I don't understand. Why is List allowed then if it's mutable?
Array also implements IReadOnlyList if I'm not mistaken. I think C# doesn't really have immutable collections, they just can be typecasted to IReadonly* to hide the mutable operations. But they can always be typecasted back to their mutable base implementation. The only real immutable collections I know of, are F#s linked lists.
I think Zig really shines here: https://ziglang.org/documentation/master/#comptime
You can think of zig’s comptime as partial evaluation. Zig doesnt have a runtime type reflection system, but with comptime it makes it feel like you do.