Have you ever thought about getting rid of all languages ​​other than C#? All in C#.

[sgf]

Have you ever thought about getting rid of all languages ​​other than C#? All in C#.
In fact, if you only use C# to develop some peripheral or purely business-oriented things, it may not make much sense.
This is one of the reasons why .net micro framework cannot really become popular.
It may have advantages over java, but it is not obvious compared to c/c++. If the opponent is rust, then it may be even worse, because rust is both low-level and safe.

Once it involves a lower level, you need to modify the code such as C/C++.
I am a little skeptical about what the advantages of using nano framework are?

In the Internet field, C# seems to face the same problem. Most of the infrastructure (big data, databases, search engines, etc.) are developed in java. Therefore, apart from personal preference, people seem to have no reason to use C#/.net.

Of course, I'm just chatting casually. Please forgive me if I'm offended.

[alberk8]

C# cannot do some of the things C/C++ can do, like real time interrupt processing but C# and nanoframework has make debugging so much easier. As for the big dotnet framework, the problem is stigma. Just because the technology is from Microsoft a lot of people has a obvious bias against it.

In terms of language, memory and speed dotnet is not inferior to Java, and in all honesty it is way ahead of Java. This is my 2cents rant.

[josesimoes]

@sgf what you are suggesting is far from trivial. As we get lower and lower on the layers and get close to the metal, it becomes almost mandatory to use C and even assembly to deal with common tasks required for boot, as an example. Setting up heap, configuring clocks and registers, etc.
Moving all that from low level (and that requires deep knowledge on the MCU intricacies) and exposing it to the daily user would defeat one of the purposes of .NET nanoFramework. Which is to abstract all that and present "only" the high-level layer ready for the daily C# developer to start doing its thing.

In .NET nanoFramework, those complicated parts are still there and available for knowledgeable developers to tweak and adjust at will. That's why one can go and port to a new MCU series or even a totally different vendor/platform.
We've tried to choose a swear spot for the common entry level and "make it easy to write C# code for resource constrained devices" as stated in our mantra . 😉 But you can still go "up and down" as needed on the abstraction layers.

I've seen from the most "obvious" devices blinking an LED or opening a garage door, to very complex systems connected to the cloud or running standalone controlling complex hardware.

We're not claiming to be the holy grail for embedded systems development, not the perfect choice for every use case.
There are projects that require low-level, fine-grained tweaks and be able to squeeze the last uA from a battery, for example. .NET nanoFramework is not the perfect fit for those.
Now, what you can accomplish with the power of .NET ecosystem, the awesome tool that Visual Studio is (from coding to debugging). How easy it is to reuse code across projects and platforms (even cloud or desktop). Requiring a simple USB cable. Using Intellisense. Starting a debug session with "just" hitting F5. All the feature that came in tow with the high level, managed language that C# is and has...
All this perfectly in reach to the average C# developer in contrast with a skilled embedded systems C/C++ developer.
You can come up with a PoC in a couple of hours instead of a couple of weeks in C. A developer can easily make changes by itself, instead of having to wait for a couple of cycles from the embedded dev team to make progress.
Not to mention all the quality tools that are at your disposal: unit tests, various CI/CD tools, hardware tests in the pipelines, and so one. All top-notch tools required for the most demanding projects.
The recent milestone of 20 million downloads of NuGet packages are also a testimony on the broad usage the project has.

I'm biased, of course 😅, by I keep thinking that .NET nanoFramework it's an amazing framework with capabilities and features ready to satisfy the requirements of complex commercial projects to novice developers learning to code.

[Ellerbach]

@sgf just to add on top: you have the choice, so use whatever you think is best for you! You're not forced to use .NET nanoFramework, you have a lot of choices and a lot of other languages and platforms. Now, as José explained, you have a lot of advantages! And it makes for most scenarios your life easier.
So, look at what you need to do and choose the platform/language you prefer. It's the same for all projects.

[sgf]

Of course I know that I have many choices. I just try to discuss whether All in C# is better and more conducive to building a complete language ecosystem. If C# does not support hard interrupts, if necessary, the C# language itself should even be modified. If no one promotes support, perhaps C# will never support it.
This is not a question or a request, just a discussion.

[josesimoes]

If you want to propose changes to C# you should use this repo and engage with the team there.
And nothing against discussing new ideas and suggestions! By all means.