3 ms·

I'm looking at a language to write simple executables with or without GUI and that are not too verbose or too complicated. A bit like a compiled python :) Woul

I'm looking at a language to write simple executables with or without GUI and that are not too verbose or too complicated. A bit like a compiled python :) Would .NET 8 be a good challenger ? I previously didn't consider it because the compilation to binary was looking more like an experiment, and the example I've seen were quite verbose (in a java way).

imiric 3y ago
Go seems like a good fit for that.
- eddtries 3y ago
  Yup, Go is absolutely the language for this! And almost every scripting thing you need to do is probably in the standard library, which is helpful.
- kaba0 3y ago
  Go is insanely verbose compared to both C# and Java due to its low expressivity, especially around its error “handling”.
  - imiric 3y ago
    I think you're confusing Go's simplicity and explicitness with verbosity. Yes, it won't help you write the least amount of code, but this forces you to write readable code and avoid cleverness, which is almost always a good thing. Its error handling is an exhausted topic, but avoiding exceptions and being forced to decide how to handle errors where they happen is also a good thing IMO. On the other hand, I would absolutely use verbose to describe both C# and Java. They are huge languages, with many features, a complex syntax, and conventions and patterns that lead to writing a lot of hard to understand code. I'd use Go over both of them any day, especially when it comes to writing cross-platform GUI or console apps that can be quickly compiled and easily distributed. Other options to consider might be Nim or Zig, but these are not as mature as Go.
    - kaba0 3y ago
      > I think you're confusing Go's simplicity and explicitness with verbosity I think those are quite innately related, yes. But I believe you also mix verbosity up in your very next sentence, for what it’s worth — readable, maintainable code is not as close a concept. In fact, certain type of verbosity helps readability, e.g. I argue that Go’s identifier capitalization harms readability, and marking it at a single place by public/private is much better, at a tiny price of more verbosity. “Clever” code is another topic, there is definitely overly clever code, which is a net negative, but in this particular comparison, is a hand-written, 3-times nested for loop with any number of side effecting statements more clear to read than the “smart” stream/linq expression? I would argue the latter is much more readable and maintainable. For another, even better example there is that math proof, which can be done an order of magnitude faster by choosing a clever notation, but I can’t look up its name yet. Re error handling, no, go doesn’t force you to handle the errors. It forces you to do some stupid meaningless if err ritual, that won’t result in correct handling of the error case, and will in fact often swallow errors. Java’s checked exception does force you to correctly handle it, though, but even runtime exceptions at least bubble up, making the default action (doing nothing) correct.
- poulpy123 3y ago
  It seems to be the more mature language for my use case. How is the GUI development and C++ interop ?
  - neonsunset 3y ago
    Abysmal. Almost no one does GUI in Go and .NET has had zero/low-cost interop as one of its main features in mind since the very first versions of .NET Framework back in the day.
    - poulpy123 3y ago
      Thanks !
Smaug123 3y ago
Personally I use F# for console apps, with ahead-of-time if startup latency is important, yeah. Works fine for me! (Ahead-of-time is much harder with F# though, because .NET idiomatically leans heavily on reflection thanks to C#'s influence, and reflection is banned in AOT. C#'s workaround is source generators, which F# does not support except very unofficially. I therefore find myself stamping out boilerplate for e.g. JSON deserialisation more than I would like.)
- poulpy123 3y ago
  Thanks I will have a look !
- etra0 3y ago
  > I therefore find myself stamping out boilerplate for e.g. JSON deserialisation more than I would like. This was my first experience while getting started in the .NET ecosystem. I wanted something similar, I wanted to build small console tools/services and F# looked cool but hit the reflection issues too soon. I mostly use crystal and golang, but both have their own issues. Hopefully F# improves with time to be fully usable with AOT!
  - neonsunset 3y ago
    Luckily nowadays C# is just as terse for writing CLI apps or even terser, which does not have aforementioned issues with AOT.
    - etra0 3y ago
      I'm willing to try it, I'm just waiting for a few more benchmarks regarding memory usage. Last time I checked I could only find the Benchmark Game [1] for AoT measurements, but they're from .NET 7. Memory usage is important to me and golang is very good at that being light, but I really hate writing it for various personal reasons. If I had more free-time I'd just simply go with Rust but you know, free time is limited :P. [1] https://programming-language-benchmarks.vercel.app/csharp-vs-go https://programming-language-benchmarks.vercel.app/csharp-vs...
neonsunset 3y ago
It would. Compiling .NET binaries to a single executable that does not require installing a runtime has been a thing for quite some time actually, but NativeAOT definitely improves the "simple and lightweight" part of your inquiry: JIT: dotnet publish -p:PublishSingleFile=true -p:PublishTrimmed=true AOT: dotnet publish -p:PublishAot=true
- poulpy123 3y ago
  Looks interesting! Does nativeAOT works for GUI ?
  - neonsunset 3y ago
    It's a bit of a hit and miss as of today. CLI, back-end and natively compiled libraries (think dll/so/dylib or even .lib/.a - you can statically link NAOT binaries into other "unmanaged" code) work best, GUI - requires more work. Avalonia[0] and MAUI[1] have known working templates with it, but YMMV. [0] https://github.com/lixinyang123/AvaloniaAOT https://github.com/lixinyang123/AvaloniaAOT / https://github.com/AvaloniaUI/Avalonia/ https://github.com/AvaloniaUI/Avalonia/ [1] https://github.com/dotnet/maui https://github.com/dotnet/maui (try out with just <PublishAot>true</PublishAot> in csproj - it is known to work e.g. on iOS)
    - poulpy123 3y ago
      Thanks !
sandreas 3y ago
It depends... .NET 6 was already capable of most things you are looking for, but there are some limitations. I personally think it is a really versatile language and if you know it, you can get the most things done somehow. I wrote a little cross platform C# command line tool called `tone`[1] for tagging audio files and it compiles via github actions for windows(x64), linux(x64,arm64,arm6,arm7), macOS (x64, arm64) as a single monolitic binary (similar to `golang`), which is pretty cool. With the right compiler flags it is not even too big (about 20MB, for comparison a `golang` binary with similar features would be about 5MB, `rust` more like 1MB or less). You can also go WASM (which is generally supported, but feels a bit experimental at times). In the GUI department there are three main competitors: - MAUI - Windows, macOS, Android, iOS (Microsoft's pet, xamarin successor) - Avalonia UI - Windows, Linux, macOS, Android, iOS, WASM - Uno Platform - Windows, Linux, macOS, Android, iOS, WASM All these feel kind of unfinished, I like Avalonia UI the most, but it's lack of standard libraries for real world apps (Preferences, SecureStorage, Encryption Wrappers, Phone-Hardware-Access, Media-Players, WebView) and the outcoming App Size (>50MB) made me use Flutter for my personal projects (App size ~15MB for the same feature set). For some Apps it might be ok. .NET may also still be incompatible / unfinished on other OS and platforms (e.g. RISC hardware or BSD operating systems). So if you only target the mainstream systems like x64 and the raspberry pi, it might not be a real problem. [1]: https://github.com/sandreas/tone https://github.com/sandreas/tone
- poulpy123 3y ago
  I would target the main desktop, and maybe raspberry and android but it's very far from my horizon and not a criteria. I was thinking that flutter is a dart library/framework ? How is it compatible with C# ?
  - sandreas 3y ago
    Flutter is written in Dart, nothing to do with C#, but a cross platform UI library. I think Flutter has a lot of advantages over the C# UI libraries and is worth learning when planning a Cross Platform UI or App. It's possible with C#, but you have to work around a lot of shenannigans depending on the use case. Command line apps are totally ok with C#...

imiric 3y ago

Go seems like a good fit for that.

eddtries 3y ago
Yup, Go is absolutely the language for this! And almost every scripting thing you need to do is probably in the standard library, which is helpful.
kaba0 3y ago
Go is insanely verbose compared to both C# and Java due to its low expressivity, especially around its error “handling”.
- imiric 3y ago
  I think you're confusing Go's simplicity and explicitness with verbosity. Yes, it won't help you write the least amount of code, but this forces you to write readable code and avoid cleverness, which is almost always a good thing. Its error handling is an exhausted topic, but avoiding exceptions and being forced to decide how to handle errors where they happen is also a good thing IMO. On the other hand, I would absolutely use verbose to describe both C# and Java. They are huge languages, with many features, a complex syntax, and conventions and patterns that lead to writing a lot of hard to understand code. I'd use Go over both of them any day, especially when it comes to writing cross-platform GUI or console apps that can be quickly compiled and easily distributed. Other options to consider might be Nim or Zig, but these are not as mature as Go.
  - kaba0 3y ago
    > I think you're confusing Go's simplicity and explicitness with verbosity I think those are quite innately related, yes. But I believe you also mix verbosity up in your very next sentence, for what it’s worth — readable, maintainable code is not as close a concept. In fact, certain type of verbosity helps readability, e.g. I argue that Go’s identifier capitalization harms readability, and marking it at a single place by public/private is much better, at a tiny price of more verbosity. “Clever” code is another topic, there is definitely overly clever code, which is a net negative, but in this particular comparison, is a hand-written, 3-times nested for loop with any number of side effecting statements more clear to read than the “smart” stream/linq expression? I would argue the latter is much more readable and maintainable. For another, even better example there is that math proof, which can be done an order of magnitude faster by choosing a clever notation, but I can’t look up its name yet. Re error handling, no, go doesn’t force you to handle the errors. It forces you to do some stupid meaningless if err ritual, that won’t result in correct handling of the error case, and will in fact often swallow errors. Java’s checked exception does force you to correctly handle it, though, but even runtime exceptions at least bubble up, making the default action (doing nothing) correct.
poulpy123 3y ago
It seems to be the more mature language for my use case. How is the GUI development and C++ interop ?
- neonsunset 3y ago
  Abysmal. Almost no one does GUI in Go and .NET has had zero/low-cost interop as one of its main features in mind since the very first versions of .NET Framework back in the day.
  - poulpy123 3y ago
    Thanks !

Smaug123 3y ago

Personally I use F# for console apps, with ahead-of-time if startup latency is important, yeah. Works fine for me! (Ahead-of-time is much harder with F# though, because .NET idiomatically leans heavily on reflection thanks to C#'s influence, and reflection is banned in AOT. C#'s workaround is source generators, which F# does not support except very unofficially. I therefore find myself stamping out boilerplate for e.g. JSON deserialisation more than I would like.)

poulpy123 3y ago
Thanks I will have a look !
etra0 3y ago
> I therefore find myself stamping out boilerplate for e.g. JSON deserialisation more than I would like. This was my first experience while getting started in the .NET ecosystem. I wanted something similar, I wanted to build small console tools/services and F# looked cool but hit the reflection issues too soon. I mostly use crystal and golang, but both have their own issues. Hopefully F# improves with time to be fully usable with AOT!
- neonsunset 3y ago
  Luckily nowadays C# is just as terse for writing CLI apps or even terser, which does not have aforementioned issues with AOT.
  - etra0 3y ago
    I'm willing to try it, I'm just waiting for a few more benchmarks regarding memory usage. Last time I checked I could only find the Benchmark Game [1] for AoT measurements, but they're from .NET 7. Memory usage is important to me and golang is very good at that being light, but I really hate writing it for various personal reasons. If I had more free-time I'd just simply go with Rust but you know, free time is limited :P. [1] https://programming-language-benchmarks.vercel.app/csharp-vs-go https://programming-language-benchmarks.vercel.app/csharp-vs...

neonsunset 3y ago

It would. Compiling .NET binaries to a single executable that does not require installing a runtime has been a thing for quite some time actually, but NativeAOT definitely improves the "simple and lightweight" part of your inquiry: JIT: dotnet publish -p:PublishSingleFile=true -p:PublishTrimmed=true AOT: dotnet publish -p:PublishAot=true

poulpy123 3y ago
Looks interesting! Does nativeAOT works for GUI ?
- neonsunset 3y ago
  It's a bit of a hit and miss as of today. CLI, back-end and natively compiled libraries (think dll/so/dylib or even .lib/.a - you can statically link NAOT binaries into other "unmanaged" code) work best, GUI - requires more work. Avalonia[0] and MAUI[1] have known working templates with it, but YMMV. [0] https://github.com/lixinyang123/AvaloniaAOT https://github.com/lixinyang123/AvaloniaAOT / https://github.com/AvaloniaUI/Avalonia/ https://github.com/AvaloniaUI/Avalonia/ [1] https://github.com/dotnet/maui https://github.com/dotnet/maui (try out with just <PublishAot>true</PublishAot> in csproj - it is known to work e.g. on iOS)
  - poulpy123 3y ago
    Thanks !

sandreas 3y ago

It depends... .NET 6 was already capable of most things you are looking for, but there are some limitations. I personally think it is a really versatile language and if you know it, you can get the most things done somehow. I wrote a little cross platform C# command line tool called `tone`[1] for tagging audio files and it compiles via github actions for windows(x64), linux(x64,arm64,arm6,arm7), macOS (x64, arm64) as a single monolitic binary (similar to `golang`), which is pretty cool. With the right compiler flags it is not even too big (about 20MB, for comparison a `golang` binary with similar features would be about 5MB, `rust` more like 1MB or less). You can also go WASM (which is generally supported, but feels a bit experimental at times). In the GUI department there are three main competitors: - MAUI - Windows, macOS, Android, iOS (Microsoft's pet, xamarin successor) - Avalonia UI - Windows, Linux, macOS, Android, iOS, WASM - Uno Platform - Windows, Linux, macOS, Android, iOS, WASM All these feel kind of unfinished, I like Avalonia UI the most, but it's lack of standard libraries for real world apps (Preferences, SecureStorage, Encryption Wrappers, Phone-Hardware-Access, Media-Players, WebView) and the outcoming App Size (>50MB) made me use Flutter for my personal projects (App size ~15MB for the same feature set). For some Apps it might be ok. .NET may also still be incompatible / unfinished on other OS and platforms (e.g. RISC hardware or BSD operating systems). So if you only target the mainstream systems like x64 and the raspberry pi, it might not be a real problem. [1]: https://github.com/sandreas/tone https://github.com/sandreas/tone

poulpy123 3y ago
I would target the main desktop, and maybe raspberry and android but it's very far from my horizon and not a criteria. I was thinking that flutter is a dart library/framework ? How is it compatible with C# ?
- sandreas 3y ago
  Flutter is written in Dart, nothing to do with C#, but a cross platform UI library. I think Flutter has a lot of advantages over the C# UI libraries and is worth learning when planning a Cross Platform UI or App. It's possible with C#, but you have to work around a lot of shenannigans depending on the use case. Command line apps are totally ok with C#...