6 ms·

> One can write code for almost any use case (except perhaps embedded) with .NET. How so? Do you mean it doesn't support ephemeral ftrace-based tracing or so

> One can write code for almost any use case (except perhaps embedded) with .NET. How so? Do you mean it doesn't support ephemeral ftrace-based tracing or something? That seems unlikely to be true given core CLR features like reflection as well as Microsoft's extensive history of embedding .NET into services and devices.

jackmott42 4y ago
There could be sufficiently small and performance critical things that you really need to use C/Rust and avoid the overhead of garbage collection all together, or you need deterministic timing and so can't use GC. The performance ceiling of C# is extremely high now though, if you use the low level features. Unsafe blocks, even simd intrinsics! But at that point you aren't really doing C# so much, but at least you can dip into those features for performance critical parts of your code without having to pull out a new language and compiler and complicate your workflow and build tools.
- tannergooding 4y ago
  > But at that point you aren't really doing C# so much I wouldn't really agree on this point. Unsafe blocks have been a feature since C# 1.0 They may not be the default way of writing C#, but they've always been a natural and integral part of C# and have extensive use internally to ensure that interop can work and extra performance is available where possible. SIMD acceleration has likewise been a part of the BCL (standard library) for nearly 10 years now and is just as integrated behind the scenes. It being part of the formal BCL makes it even more "standard" than the equivalent in C/C++ where such functionality is relegated to compiler specific headers/extensions. SIMD code itself is also very idiomatic C#. There is nothing really different about utilizing the APIs, the only difference is in how you think about handling your data. Needing to think differently about how data is handled for some contexts is applicable to many domains in C# (and programming in general). It's no different than making code work with async or multi-threading ;) Simply put, all these features are still C# and I don't think its necessarily good to say that using them means you're not really writing C# anymore. I view it as a disservice to the language, its extensibility, and power. It also leaves a connotation that you might be better off writing C/C++ instead, which is often not the case.
Alupis 4y ago
Embedded is a very barren environment. One where bytes of memory and individual clock cycles can matter a lot. This is just not the environment a memory managed language, running atop a virtual machine runtime is suitable for. You'd have to strip all that away, and then you'd just be left with C# syntax, but it would be very far from being C# and would not be compatible with any standard C# library, framework or platform. For a lot of embedded work, even Rust is having a difficult time getting traction. Even the C++ Standard Library doesn't fit on many of the systems folks are working on, let alone the STL.
- HeyLaughingBoy 4y ago
  There's embedded and then there's embedded. The system I'm working on at my day job has about 1meg of Flash and, IIRC, 128k RAM. It was reduced in resources to save cost (disposable device). The one I'm working on at home has about 4M Flash and 256k RAM. One of them is making liberal use of the STL and I know both have Python implementations available. Tiny, memory constrained devices are still around, but they're a smaller and smaller part of the pie every year.
- kaba0 4y ago
  You do realize Java was literally made for set top-boxes and the like? Sure, there are much more resource-constrained embedded devices as well, but byte code takes up much less space than machine code, plus a naive interpreter can be really really small, so it’s not an unworkable path.
delta_p_delta_x 4y ago
> How so? I specifically left embedded out because I didn't really want to make assumptions about CLR byte code running within the constraints of such environments. I've only ever programmed in C++ on embedded devices, so I can't actually comment on CLR (ergo the perhaps in my comment).
- smcl 4y ago
  There actually was a sort of embedded-systems variant of .NET called ".NET Micro" but it fell off a few years back (last release was back in 2015) and I think it had some high-ish minimum requirements (e.g. it's not running on a PIC or the AVR arduinos)
  - com2kid 4y ago
    I wrote a blog post about .NET Micro (https://meanderingthoughts.hashnode.dev/history-of-microsoft-joule-band-v0-part-1 https://meanderingthoughts.hashnode.dev/history-of-microsoft...). It is actually a pretty nice framework, but it does (did) require a 32bit CPU at minimum, and a hefty amount of flash. That said, the UI framework was a joy to work with!
    - smcl 4y ago
      Oh nice! That was a good wee read, thanks!
      - com2kid 4y ago
        The next post in the series, https://meanderingthoughts.hashnode.dev/history-of-microsoft-joule-band-v0-part-2 https://meanderingthoughts.hashnode.dev/history-of-microsoft... is more technical. I should do some sort of write up of just .netMF, but I don't honestly recall too much about it in a general sense, since most of my time was spent in the weeds optimizing code.
        smcl 4y ago
rbanffy 4y ago
Modern embedded is not the same as it was in our youth. Embedded platforms then were 8-bit, 1-4 MHz and 64K of RAM would be a luxury. Often that address space would be shared with ROM. Now we take multi-core, 64-bits, gigabyte address spaces, memory protection and multi-tasking Unix-like OSs for granted most of the time. Except for the most stringent requirements (such as hard real time or very constrained power budgets) that we find small bare metal platforms. And those are real fun to do ( but not as much fun to debug).

jackmott42 4y ago

There could be sufficiently small and performance critical things that you really need to use C/Rust and avoid the overhead of garbage collection all together, or you need deterministic timing and so can't use GC. The performance ceiling of C# is extremely high now though, if you use the low level features. Unsafe blocks, even simd intrinsics! But at that point you aren't really doing C# so much, but at least you can dip into those features for performance critical parts of your code without having to pull out a new language and compiler and complicate your workflow and build tools.

tannergooding 4y ago
> But at that point you aren't really doing C# so much I wouldn't really agree on this point. Unsafe blocks have been a feature since C# 1.0 They may not be the default way of writing C#, but they've always been a natural and integral part of C# and have extensive use internally to ensure that interop can work and extra performance is available where possible. SIMD acceleration has likewise been a part of the BCL (standard library) for nearly 10 years now and is just as integrated behind the scenes. It being part of the formal BCL makes it even more "standard" than the equivalent in C/C++ where such functionality is relegated to compiler specific headers/extensions. SIMD code itself is also very idiomatic C#. There is nothing really different about utilizing the APIs, the only difference is in how you think about handling your data. Needing to think differently about how data is handled for some contexts is applicable to many domains in C# (and programming in general). It's no different than making code work with async or multi-threading ;) Simply put, all these features are still C# and I don't think its necessarily good to say that using them means you're not really writing C# anymore. I view it as a disservice to the language, its extensibility, and power. It also leaves a connotation that you might be better off writing C/C++ instead, which is often not the case.

Alupis 4y ago

Embedded is a very barren environment. One where bytes of memory and individual clock cycles can matter a lot. This is just not the environment a memory managed language, running atop a virtual machine runtime is suitable for. You'd have to strip all that away, and then you'd just be left with C# syntax, but it would be very far from being C# and would not be compatible with any standard C# library, framework or platform. For a lot of embedded work, even Rust is having a difficult time getting traction. Even the C++ Standard Library doesn't fit on many of the systems folks are working on, let alone the STL.

HeyLaughingBoy 4y ago
There's embedded and then there's embedded. The system I'm working on at my day job has about 1meg of Flash and, IIRC, 128k RAM. It was reduced in resources to save cost (disposable device). The one I'm working on at home has about 4M Flash and 256k RAM. One of them is making liberal use of the STL and I know both have Python implementations available. Tiny, memory constrained devices are still around, but they're a smaller and smaller part of the pie every year.
kaba0 4y ago
You do realize Java was literally made for set top-boxes and the like? Sure, there are much more resource-constrained embedded devices as well, but byte code takes up much less space than machine code, plus a naive interpreter can be really really small, so it’s not an unworkable path.

delta_p_delta_x 4y ago

> How so? I specifically left embedded out because I didn't really want to make assumptions about CLR byte code running within the constraints of such environments. I've only ever programmed in C++ on embedded devices, so I can't actually comment on CLR (ergo the perhaps in my comment).

smcl 4y ago
There actually was a sort of embedded-systems variant of .NET called ".NET Micro" but it fell off a few years back (last release was back in 2015) and I think it had some high-ish minimum requirements (e.g. it's not running on a PIC or the AVR arduinos)
- com2kid 4y ago
  I wrote a blog post about .NET Micro (https://meanderingthoughts.hashnode.dev/history-of-microsoft-joule-band-v0-part-1 https://meanderingthoughts.hashnode.dev/history-of-microsoft...). It is actually a pretty nice framework, but it does (did) require a 32bit CPU at minimum, and a hefty amount of flash. That said, the UI framework was a joy to work with!
  - smcl 4y ago
    Oh nice! That was a good wee read, thanks!
    - com2kid 4y ago
      The next post in the series, https://meanderingthoughts.hashnode.dev/history-of-microsoft-joule-band-v0-part-2 https://meanderingthoughts.hashnode.dev/history-of-microsoft... is more technical. I should do some sort of write up of just .netMF, but I don't honestly recall too much about it in a general sense, since most of my time was spent in the weeds optimizing code.
      - smcl 4y ago

rbanffy 4y ago

Modern embedded is not the same as it was in our youth. Embedded platforms then were 8-bit, 1-4 MHz and 64K of RAM would be a luxury. Often that address space would be shared with ROM. Now we take multi-core, 64-bits, gigabyte address spaces, memory protection and multi-tasking Unix-like OSs for granted most of the time. Except for the most stringent requirements (such as hard real time or very constrained power budgets) that we find small bare metal platforms. And those are real fun to do ( but not as much fun to debug).