4 ms·

I wish I could follow this guys advice. My colleagues are Microsoft camp guys. C# on the back end for anything they can. If your problem can’t be solved with a

I wish I could follow this guys advice. My colleagues are Microsoft camp guys. C# on the back end for anything they can. If your problem can’t be solved with a windows desktop app on whatever .net framework is trending, then it’s not a problem worth considering. But we needed a native app on iOS for irrigation control, so we had to tool up with Swift. I would love to do a solid cross platform thing, but there isn’t one in mobile space for user rich experiences that do Bluetooth, mapping, etc. We tried. So Kotlin has to be added to the mix so we could use the only right/available tool for native Android app job. The embedded stuff? Needed C code. The control node that runs our edge stuff needed to run on little Linux computers and support self hosted development. C wasn’t going to work, nor was Kotlin or Swift. Python it is. We needed a highly threaded cloud bridge sevice. Python was out for that. I guess I could have tried server Kotlin or Swift, but I went with Elixir instead and just wish I could use that everywhere. So if you’re just doing web stuff, I guess you can just use consistent whatever. Though isn’t the whole argument of node/deno that since you have no (real) choice but to use JSON the front side, you might as well use it as the wrong tool for backend as well?

alexchantavy 4y ago
I’m not familiar with the C# world but have you tried Xamarin? What are the gaps?
manusachi 4y ago
> but I went with Elixir instead and just wish I could use that everywhere. Same here! I would say, I'm in the similar camp as your colleagues but about Elixir. I'm glad to choose the right tool for the job as long as it's Elixir :)
owenm 4y ago
As a thought experiment, this got me thinking what would a solution just using .NET core look like? Obviously I don't have all the details but I think you can do all of those things in .NET (with the exception of the embedded stuff probably). * Bluetooth and maps libraries are available for Xamarin, [1] [2] * Control server could be written in C# using the .NET core worker template [3] and deployed as a SystemD service and then the SDK deployed as a package to enable local development. * Cloud bridge deployed as a service or website using raw sockets, SignalR or Azure IOT hub (depending on requirements). You'd end up with 2 languages instead of 5 and I suspect you'd be able to factor some code out into libraries as well... [1]: https://learn.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/map/ https://learn.microsoft.com/en-us/xamarin/xamarin-forms/user... [2]: https://github.com/dotnet-bluetooth-le/dotnet-bluetooth-le https://github.com/dotnet-bluetooth-le/dotnet-bluetooth-le [3]: https://devblogs.microsoft.com/dotnet/net-core-and-systemd/ https://devblogs.microsoft.com/dotnet/net-core-and-systemd/
- travisgriggs 4y ago
  > * Bluetooth and maps libraries are available for Xamarin, [1] [2] I don’t have lots of direct experience with these in particular. I have played with the BLE shim libraries provided for Dart, React-Nativ, and Cordova back in the day. All were maybe ok for single characteristic rare interaction. But as you go up in connection frequency, characteristic count, or update frequency, things degrade in robustness quickly. I spent a solid couple of weeks getting our Kotlin/Android version up to being able to handle 1000 reconnects without hanging the chip. BLE is hard. Given that even with the native map stuff, we had to jump through some “clever” hoops to get the kind of map overlay feedback we were looking for and at tolerable update speed, I remain skeptical that yet another abstraction layer wasn’t going to be an additional hindrance. > * Control server could be written in C# using the .NET core worker template [3] and deployed as a SystemD service and then the SDK deployed as a package to enable local development. We have limited flash space. It’s too small to accommodate the gcc toolchain. If/when we want to do that, we used a mounted sd card to accommodate the space needed for doing hosted development. It’s pretty cumbersome compared to having Python right there. I would guess that if gcc wasn’t much of an option, c# was going to run into similar issues. > * Cloud bridge deployed as a service or website using raw sockets, SignalR or Azure IOT hub (depending on requirements). My choice to use Elixir here would be the most arguable. The nature of how we do MQTT communications securely (uniquely secured by each connection path) dictates either a single threaded many-socket mqtt client (we’d have to do this from scratch) or just use lots of threads, one per client connection. It is not uncommon to have 20,000 threads active in our current solution. Based on some peers comments, that would be a lot. But at that point, I guess we’d pursue the many clients on less threads approach. Which could have been in whatever. I really just wanted an excuse to take Elixir for a spin, and this was an area it could/did shine.
  - owenm 4y ago
    Very interesting - thanks! It's an interesting exercise thinking through some of the constraints and some of the engineering tradeoffs. Out of interest, how much development is actually done on device vs being done on another system and then loaded onto the SD card?

alexchantavy 4y ago

I’m not familiar with the C# world but have you tried Xamarin? What are the gaps?

manusachi 4y ago

> but I went with Elixir instead and just wish I could use that everywhere. Same here! I would say, I'm in the similar camp as your colleagues but about Elixir. I'm glad to choose the right tool for the job as long as it's Elixir :)

owenm 4y ago

As a thought experiment, this got me thinking what would a solution just using .NET core look like? Obviously I don't have all the details but I think you can do all of those things in .NET (with the exception of the embedded stuff probably). * Bluetooth and maps libraries are available for Xamarin, [1] [2] * Control server could be written in C# using the .NET core worker template [3] and deployed as a SystemD service and then the SDK deployed as a package to enable local development. * Cloud bridge deployed as a service or website using raw sockets, SignalR or Azure IOT hub (depending on requirements). You'd end up with 2 languages instead of 5 and I suspect you'd be able to factor some code out into libraries as well... [1]: https://learn.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/map/ https://learn.microsoft.com/en-us/xamarin/xamarin-forms/user... [2]: https://github.com/dotnet-bluetooth-le/dotnet-bluetooth-le https://github.com/dotnet-bluetooth-le/dotnet-bluetooth-le [3]: https://devblogs.microsoft.com/dotnet/net-core-and-systemd/ https://devblogs.microsoft.com/dotnet/net-core-and-systemd/

travisgriggs 4y ago
> * Bluetooth and maps libraries are available for Xamarin, [1] [2] I don’t have lots of direct experience with these in particular. I have played with the BLE shim libraries provided for Dart, React-Nativ, and Cordova back in the day. All were maybe ok for single characteristic rare interaction. But as you go up in connection frequency, characteristic count, or update frequency, things degrade in robustness quickly. I spent a solid couple of weeks getting our Kotlin/Android version up to being able to handle 1000 reconnects without hanging the chip. BLE is hard. Given that even with the native map stuff, we had to jump through some “clever” hoops to get the kind of map overlay feedback we were looking for and at tolerable update speed, I remain skeptical that yet another abstraction layer wasn’t going to be an additional hindrance. > * Control server could be written in C# using the .NET core worker template [3] and deployed as a SystemD service and then the SDK deployed as a package to enable local development. We have limited flash space. It’s too small to accommodate the gcc toolchain. If/when we want to do that, we used a mounted sd card to accommodate the space needed for doing hosted development. It’s pretty cumbersome compared to having Python right there. I would guess that if gcc wasn’t much of an option, c# was going to run into similar issues. > * Cloud bridge deployed as a service or website using raw sockets, SignalR or Azure IOT hub (depending on requirements). My choice to use Elixir here would be the most arguable. The nature of how we do MQTT communications securely (uniquely secured by each connection path) dictates either a single threaded many-socket mqtt client (we’d have to do this from scratch) or just use lots of threads, one per client connection. It is not uncommon to have 20,000 threads active in our current solution. Based on some peers comments, that would be a lot. But at that point, I guess we’d pursue the many clients on less threads approach. Which could have been in whatever. I really just wanted an excuse to take Elixir for a spin, and this was an area it could/did shine.
- owenm 4y ago
  Very interesting - thanks! It's an interesting exercise thinking through some of the constraints and some of the engineering tradeoffs. Out of interest, how much development is actually done on device vs being done on another system and then loaded onto the SD card?