In the .NET embedded space there's also Meadow from Wilderness Labs (which is based on Mono, as opposed to NanoFramework which is a rework of MicroFramework[0]).

There was (semi) recently a "dev day" for Meadow which I found super interesting[1]. The founder of Wilderness Labs has also been doing a bit of streaming on Twitch[2].

They also have some great docs if you're interested in learning about electronics in general[3].

[0] https://community.wildernesslabs.co/t/lay-of-the-land/362

[1] https://www.youtube.com/watch?v=qE8qWhiz8Vw&list=PLoP9Fu9zn7...

[2] https://www.twitch.tv/wildernesslabs

[3] http://developer.wildernesslabs.co/Hardware/Tutorials/Electr...

It me! :)

It's worth noting that Meadow runs full .NET; so you get generics, and all the other modern goodies. Currently we support .NET Framework 4.7.2/.NET Standard 1.6, though we're working on Core3.x support.

Also, we support F# and VB.NET. We even ship templates for both. However, F# 5 broke our F# support. :'( :'(

Hoping to fix the F# support soon.

Using this in combination with F# would make it pretty straightforward to build reliable embedded devices.

Probably not F#, although the programming part might be a lot easier. The problem with F# is that programming idiomatic F# tends to abuse the garbage collector quite a bit. They had to build a new garbage collector for the CLR before F# became really usable, and this runtime abandons that garbage collector for a simpler mark/sweep collector.

What about it facilitates reliability?

Has anyone had much success with nano? I wanted to use it on an ESP project but it never got off of the ground.

I've found it difficult to understand as a noobie. Especially trying to figure out "is X supported" or "is X device supported"

Their getting started page is a great example of what I experienced. (Linked from their youtube video related to getting started)

https://docs.nanoframework.net/articles/getting-started-guid...

Another F# fan here wondering if this supports it :)

Naively I would say why shouldn't it? No matter which language you program in, the resulting IL code should be the same. On the other hand there are often utilities in the class library that compilers rely on, like attributes, helper functions and what not.

You may be interested in Elixir Nerves as well.

https://www.nerves-project.org/

Meadow has F# support, but F# 5 broke us. :'(

Hoping to fix that soon. I <3 F#.

Curious why they've got pictures of Wordpress code on MacBooks for a .net framework.

Because it's a stock photo :D

Also, I've been using .net core on my Macbook and it works great :)

I've used it as well on a MacBook - no major issues. But does the .net nanoframework work on a MacBook?

Yeah, it's stock photo. I get it. I guess I would have expected a .net-oriented project may have at least chosen a stock photo with, say, C# code on the screen... :)

"PROUDLY POWERED BY WORDPRESS" Maybe it's from the one working on the website for the framework?

It was .NET MicroFramework / Netduino that got me into playing with embedded programming and microcontrollers. Whilst I found it useful at the time (being a C# coder) the fact that it's interpreted and has a huge runtime means it's not really suited for embedded work. It sounds like this is the same so I'm not going near it.

Hmm, I've seen fully interpreted Lua, Basic, Javascript and Python facilitating micro-controller tasks decently well.

So what's the issue with a small bytecode runtime besides a few X performance hit?

FWIW, Meadow takes a different approach; we're working on AoT support right now, so it won't be interpreted.

I wonder how it compares to MicroPython.

I've been using C# for over a decade, but recently switched my focus to Python.

I've been using MicroPython to build wasp-os apps for the PineTime/P8 smartwatch, and I find it to be a great compromise between productivity (REPL, dynamic, expressive syntax) and performance (@native, @viper, C embedding).

It it possible to use this with F#?

What's the difference between micro framework and nano framework? Does nano have generics?

nanoFramework is a fork of Micro Framework.

https://en.wikipedia.org/wiki/.NET_Micro_Framework#History

>On 23 January 2017, after numerous attempts to revive .NET Microframework project and bring it to community governance and a period of work "in the dark", a group of embedded systems developers publicly announced .NET nanoFramework as spin-off of .NET Micro Framework.

It's just a rework of the .NET MicroFramework, so it does not have Generics or any of the other new goodies post .NET v1.0 that are not compiler sugar.

Check out [Meadow](https://www.wildernesslabs.co/), though. Has both Generics and F# support. :)

Isn't generics just a part of the compiler?

No, .NET generics are real and are reified at runtime, unlike Java where generics are just some compile-time typechecking.

On platforms that don't allow runtime code generation, such as iOS, generics are actually compiled ahead of time.

It's reasonable to ask if the same is done with NanoFramework.

To clarify, I was under-educated on how generics work, rather than being this clever.

Does this imply that generics in Ocaml/Haskell are not real?

My understanding is it doesn't matter in Haskell since it lacks reflection, they are real because you can't reflect and see they have been type erased at runtime.

In C# and Java reflection is used extensively and the generics still exist in C# when reflecting they are gone in Java.

"Generics" in Haskell are real, but they're not what is in the .NET lingo called reified. Just like Java does not monomorphise.

On the other hand, C#, F# or Rust monomorphise (have reified generics).

Are “monomorphism” and “reification” interchangeable terms though? Considering how .NET now has covariant/contravariant generics I wonder if it could be described as having “polymorphic” generics as opposed to monomorphic generics - (unrelated to OOP polymorphism, ofc).

AFAIUI _monomorphisation_ and reification are interchangable.

That means, that if I have a polymorphic (generic) class `MyClassA<T>`, the compiler (regardless if it is JIT in the runtime as in C#, or AOT as in Rust) monomorphises (reifies) `MyClassA` for each instantiation of `T`. So `MyClassA<MyClassB>` and `MyClassA<MyClassC>` are distinct classes.

For this reason, co-/contra-variance in C# works only for interfaces. Type parameters in classes are invariant. `MyClassA<MyClassB>` and `MyClassA<MyClassC>` are distinct classes, neither sub-/super-class of the other, even if `MyClassB` were a subclass of `MyClassC`.