Hacker News Reader

Comment by chris_nielsen | Hacker News Reader

Not trying to be cheeky, but why not c#? Has pts 2, 3 and 4. For pt 1, what in Rusts type system are you looking for?

> Not trying to be cheeky, but why not c#?

C# is my main language. I consider it a very good all-round language.

Rust's type system has some advantages over C# tho, for example Sum Type, Option (C# has ? but it was added later so you need to be careful when interacting with old code, kinda like TypeScript <-> JavaScript to a lesser extent), exhaustive enum, etc.

Another thing I don't like about C# is the runtime startup time which prevents me from using it for command line tools (Yes I prefer static typed languages even for "scripting"). I think Go has proven that you can have both GC and extremely fast startup time.

Could you try a few sample scenarios for a CLI tool written in C# with the following publish options?

JIT:

    dotnet publish -c release -o publish -p:PublishSingleFile=true -p:PublishTrimmed=true

AOT:

    dotnet publish -c release -o publish -p:PublishAot=true

Either one has really good startup time (below ~100ms and 20-30ms respectively depending on what you do), compact binary size and require no external dependencies. Just like in Go except without all shortcomings of Go :)

p.s.: AOT on macOS requires .NET 8 preview (will be released in November)

Interesting, I remembered I've tried something similar to your JIT example but maybe my memory is playing tricks on me. I'll try these again later

20 milliseconds? On my 7 year old Linux box, this little Nim program https://github.com/c-blake/bu/blob/main/wsz.nim runs to completion in 109.62 +- 0.17 microseconds when fully statically linked with musl libc on Linux. That's with a stripped environment (with `env -i`). It takes more like 118.1 +- 1.1 microseconds with my usual 54 environment variables. The program only does about 17 system calls total, though.

Additionally, https://github.com/c-blake/cligen makes decent CLI tools a real breeze. If you like some of Go's qualities but the language seems too limited, you might like Nim: https://nim-lang.org. I generally find getting good performance much less of a challenge with Nim, but Nim is undeniably less well known with a smaller ecosystem and less corporate backing.

EDIT: I make only observations here, not demands. Another observation on the same machine is `python-3.11.5 </dev/null` with an empty environment taking 7.85 +- 0.02 ms.

20ms as measured with `time` on Fish shell on macOS. Let's be real, comparing versus Nim here is the same as comparing with C - both are a much lower level languages and don't do as much work on startup (threadpool, GC, etc.) and, for the reference, 60fps is 16.6ms per frame. The difference is unlikely to be noticeable. And this isn't measuring program execution time but back to back console receiving a command to launch a binary, OS doing so, binary starting, doing useful work (displaying hint that the command was not in the correct format) and only then exiting.

I agree this particular C# being >180x slower may not matter much for one-off commands keyed-in by and watched by humans, but that may not be all that matters. E.g., some people might `find . -print | xargs -n1 cmd`. Almost everything almost always "all depends". (On a whole lot. E.g., only @raincole can elaborate on his use cases and what might be missing from the Nim ecosystem.)

EDIT: Also, it's misleading to bundle Nim with C and C's many & storied footguns. While "low-level" is somewhat subjective and you can opt-in to go as low as C (if you so desire), most Nim code is as high-level as Python or C# with various choices in automatic memory management, and the language has very high-level capabilities. E.g., Nim has user-defined operators like Julia. Want to add `=~` or `~` for regex pattern matching? No problemo. In that aspect, Nim is arguably higher-level than C#.

> C# is my main language.

Then the answer is F#. OCaml has everything except the big ecosystem. Haskell has a way bigger Ecosystem than OCaml, but is still not comparable to Rust.

Runtime startup might be a fixed issue soon for smaller CLI programs. Correct me if I'm wrong, but I believe they are working on (and it is already available with a compiler option) to compile your C# program ahead of time (C# AOT).

Tried Kotlin native?

- sum types via sealed classes (not great, admittedly)

- enum "when" expressions are exhaustive

- option type via built-in nullable types (honestly the superior solution)

Rust's type system has some advantages over C#

Pick up some F# then. Both can interop, I've built many things in a combo of the two languages, plus it'll make you a better C# developer and your type system power greatly increases. Be careful though you might not want to go back to C#.

C#'s type system is nowhere near as expressive. Lack of sum types/discriminated unions and pattern matching/type refinement.

Sum types, which can only be approximated in C# via records, and no exceptions, which is even a problem for F#.

I don't know C#, so maybe it has these, but it's unlikely:

- absence of null pointers

- proper sum types which can be statically checked for exhaustiveness

- statically controlled mutability (yes, borrow-checking is still useful if you have a GC!)

Also no exceptions, but that's not a type system feature.

C# calls the first one "nullable reference types." When that build option is enabled, all types are non-nullable by default, and you can make them optionally nullable by declaring them like "MyClass? cls = null;"

The compiler will ensure you check for null before de-referencing a nullable type.

How does this interact with third-party dependencies you use? In my experience, most gradual typing things break down at that boundary.

This isn't gradual typing? If libraries are not compiled with the compiler option, then all their reference types will be deemed nullable and I need to check for null before dereferencing. I can't do something like "GetItem().Name" if "GetItem()" returns a reference type like I could in Java, GoLang, JS, etc. If that library did use the flag and was provably non-nullable, then I could.

Then what about F#?

Reply on news.ycombinator.com