
Giving Mono Souper Powers - MikusR
https://www.mono-project.com/news/2018/12/06/souper/
======
dvfjsdhgfv
I have a more general question: has anyone here built a truly portable app
using Mono (i.e. one that runs on several platforms, has a reasonable number
of active users and is supported) and can share some insights regarding
performance and other issues? If you started today, would you still use Mono?

~~~
minxomat
I can't share the name, but we've built a complete enterprise stack on Mono.
There are several parts:

\- Server, Nancy2/Marten/Hangfire, runs on linux

\- Headless clients for linux and Windows (x64)

\- GUI clients for macOS, linux and Windows (x64)

The server is deployed as a static fat binary. The headless clients are static
binaries for linux and .NET proper for Windows.

The GUI clients use Eto, which in turn means:

\- Static binary using Eto.Gtk on linux

\- Static, signed app bundle (Gatekeeper friendly) using Eto.Xamarin on macOS

\- .NET proper application using Eto.Wpf on Windows

No performance issues so far. I wish Mono would implement a GUI for the
profiler though. The log profiler is great to use, but clunky in comparison
with dotTrace or NProfiler.

The whole architecture sounds complicated but really isn't. It's a single
solution with three* projects:

\- Server

\- Headless Clients

\- Single Eto GUI for all platforms

\- (* Target build projects for the GUI platforms, no code in here)

The build server then only needs to do some additional work for creating DMG
installers and signing the macOS app.

~~~
oblio
How's Eto? It seems really cool but it's backed by a small company, I think
there's just 1 developer.

Also, do your GUI clients have fancier UIs? For example, have you implemented
your own grid view, something where you put custom controls in the cells,
images, graphics, etc.?

~~~
minxomat
We maintain internal forks of Eto and Nancy. They are easy enough to grok for
us to modify and maintain, even when development upstream dies.

Most of the user interaction is happening via the web app served by the
server. The local clients are "just" for configuration, comparable in
complexity with e.g. Tunnelbear or Glasswire. We use some custom grid
elements, which have been easy to implement.

Eto is the only framework out there which gives you native GUIs everywhere.
That's what was most important to us. Native speed, native OS integration
(tray menus, notifications etc.). It's also really easy to learn for devs who
might have been WPF-exclusive before.

~~~
oblio
A sort of follow-up question: have you contributed things back to Eto? Were
they responsive?

Thank you for your detailed answer, by the way! :)

~~~
minxomat
No, most of the small customizations are very specific to our application.
Mostly how closing events or notifications are handled. TBH at least I don't
think much about Eto day to day, it's just there and works. Questions mostly
have been answered by existing issues, where the author seems responsive
enough.

------
StefanKarpinski
I've tried using Souper on a number of occasions to micro-optimize handwritten
LLVM code and every single time it just returned the same code to me with
different formatting. Has anyone else had better success with it? Perhaps all
my cases where already optimal, but I have a hard time believing that. Or
perhaps I should try again since it's been a few years.

~~~
gameswithgo
I think some people tend to think like a compiler when they write code, and
when you do, you less often get interesting compiler driven improvements. You
are already folding constant expressions, lifting loop invariants out of loops
etc.

------
polskibus
Does anyone know how well does mono to LLVM perform in contrast to standard
RyuJIT on .Net Fx or .Net Core?

------
xmichael999
Genetec, on of the largest Video Management systems does everything in Mono.

~~~
xpolitix
Nop, they use old dotnet framework, on windows, even for their embedded stuff.
They use C# and F#.

