Hacker News Reader

Comment by binarynate | Hacker News Reader

I think that C# is underrated. Although TypeScript is my default language choice for most programming, C# / .NET is my choice for cases where:

- high performance is important - or interop with native libraries is required (because C#'s DllImport attribute makes that super simple)

Another benefit is that C# is syntactically similar to TypeScript (they were both designed by Anders Hejlsberg after all), so switching between the two languages feels easy. Java and Go are both similar to C# in terms of performance, but interfacing with native code isn't as simple with those languages, and they're also not as similar to TypeScript as C# is (especially Go, which is quite different).

View on HN

C# is my goto for Windows, for sure. Is the native interop good in Linux as well? I've never even considered anything like that, would probably gravitate to C++ since that's what I'm familiar with but would seriously consider Go or Java in non-Windows situations.

How do you think they built the Linux-version of the .NET standard library? ;)

Lots of wine?

Interop on Linux works well.

C# on Linux, as of the past 2 or 3 years, has been consistently improving with great tooling, good interop, is open source(MIT) and has the ability to package "native" versions of your app that contain the runtime at negligible space costs for distribution or deployment.

Give .NET 5 on Linux a try, you'll be surprised!

For me, the work this team has been doing is the example of the positive "change" Microsoft has brought to the open source space. A stellar language with great infrastructure.

The native interop is the same. That is, if your DLL and .so have the same function signatures, you can use the same interop code unmodified between Linux and Windows. This is really convenient.

(But watch out for bitness)

Also want to add with Jetbrains Rider, you can get a consistent IDE experience across multiple platforms as well. As much as I like vscode, Rider is just fantastic.

Azure has the majority of its VMs on Linux now. C# is almost certainly more popular on Linux than Windows for anything developed in the last couple years. We are in the process of migrating all our services over to kubernetes, it's quite nice.

I’ve actually been using dotnet 5 on Linux recently. It’s been really successful, and to your question; I put performance critical bits in a .so with which I can use pinvoke. Speaks to the power of C, really because there’s been amazingly, no issues with ABI or strict layout or anything.

Yes, native interop works the same across all platforms (Linux, macOS, Windows, Android, iOS). You can just place a dynamic library with C linkage (.so, .dylib, or .dll file) into your app's folder, and then you can call the native functions as external functions in C#. For example, if your library exports the following C function:

    void printMessage(char *message) {
        printf("Message from C#: %s", message)
    }

You can call it from C# like this:

    MyLibrary.printMessage("Hello from C#!");

    public static class MyLibrary {
        [DllImport("MyLibraryName")]
        public static extern void printMessage(string message);
    }

C# takes care of marshalling data types, and an instance of a native object can be passed as an IntPtr. I'm currently developing web services for a new WebRTC-related product using .NET 5 on Ubuntu, and it's working well. One of the services utilizes a native C++ library and another utilizes a native Go-based library using the same approach. Java and Go are both good options, too.

Thanks, I'll give it a try. I've done a lot of interop in Windows so it'll be good to leverage to Linux.

it's a little bit harder when your linux library is not inside LD_LIBRARY_PATH or the windows one is not inside a path. but there are tricks to override the loading behavior, it's just a little bit tricky since you need a loading context, which can load other c# dll's without having a reference to them.

it's basically like that: AssemblyLoadContext loads the managed assembly (like YourPackage.NativeApi which contains the DllImport) and the AssemblyLoadContext that loads via LoadUnmanagedDll all paths to the DllImports. you also need a Shared Library for the calling package and the dll import package so that you can do (Type)Activator.CreateInstance(LoadContext.LoadFromAssemblyName(YourDllImportAssemblyName))

I agree it is an excellent language from an ergnomics point of view.

One problem I've found for proprietary programs is that C# stored basically your whole source code in the executable. I don't just mean it's easy to disassemble... it's really retained the source code, or at least a lot of metadata. Even the original local variable names are there! I wonder if anyone has any ideas to work around this?

The term you're looking for is obfuscation. This seems like a good roundup: https://github.com/NotPrab/.NET-Obfuscator

A bit of a tangent but is it possible yet to compile C# to native code easily (like calling a normal compiler on the command-line)? Last time I checked I needed to jump through a bunch of hoops through Visual Studio, and create some XML or other nonsense. I don't get why they've made it so hard compared to just compiling managed code.

It is super easy with dotnet core. The new CLI is pretty simple, you use it as a package manager and compiler. Visual Studio also uses the CLI to run and debug dotnet core projects. https://docs.microsoft.com/en-us/dotnet/core/tools/

Is it possible to create a single, stand-alone, self-contained .exe? (I'm fine with only building for a single platform - Mac/Win/Linux)

Needing to run my programs (which show up as .dll's) using dotnet just feels weird (and it doesn't match my intuition for 'how programs are run' in Windows cmd/etc).

I'd be fine with an .exe that's not self contained but at least I run it like a 'normal' exe. :)

> Is it possible to create a single, stand-alone, self-contained .exe?

Yes.

You have to set up "dotnet publish" for the project that makes the executable.

It then makes a stub loader "your program.exe" which looks and behaves normally. You can then make it "self contained", which bundles the assemblies for you and transparently unpacks them.

You can have different publish profiles for the different targets.

.NET 5.0 can now create true single file that doesn't need any unpacking on first run (except on Windows where the Jit and GC dlls will live or be unpacked separately; but that should be resolved in .NET 6.0)

Yes that is possible, you can produce an .exe which contains your application's assemblies but relies on the appropriate .NET runtime being present on the user's computer. You can also build a .exe which has the .NET runtime bundled, but it can be quite big. I made a simple program that wrote "Hello World" to the console [1] and it was between 46-78MB: https://blog.mclemon.org/no-this-is-what-peak-hello-world-lo...

Yeah, it's not really a "real" native binary.

You can get it down to 8kb by jettisoning all comforts: https://medium.com/@MStrehovsky/building-a-self-contained-ga... but that's not exactly practical.

Wow! Yeah indeed there's a few impractical steps required to go all the way to 8kb, but trimming down to a couple of MB is definitely a huge improvement. I somehow never looked into CoreRT before, I'm gonna need to do so. Thanks for sharing this!

Yes, you can use ILMerge to merge all other DLLS into the main exe/dll: https://stackoverflow.com/questions/8077570/how-to-merge-mul...

It's possible but along with an .exe you'll get a couple of .dlls. Exe size will be 60+ Mb.

But I want it to produce a single EXE and that's it... like the C# compiler has always been capable of doing. Sorry I neglected to mention that part (kind of assumed it was a given).

Also, the whole thing is still a stateful operation revolving a .csproj file, which (again) is XML I have to create (sure, it's just one command) and manage/deal with every time. Even to compile a tiny C# file from my editor now I need to make a project for it. With a normal C# or C++ compiler I can just invoke csc.exe or cl.exe and produce the executable in one command from my editor... no intermediate state or project file management required. That's kind of what I was getting at with it being "simple". I didn't just mean the syntax, I also meant the structure of the solution.

You can still just invoke csc.exe, no project file required - I'm not sure what you are getting at? But it's probably going to be easier to just dotnet new console and get the project file for free. They tried migrating away from csproj but there is just too much ecosystem around it. The XML sounds bad, but in reality they added file globbing and other things to make it so you rarely even have to change it. That and to be honest it just works and is quite readable even though it's the "evil" XML.

csc.exe doesn't compile to native?

No, it's always compiled to MSIL. You've always had to use a separate tool (such as NGen or dotnet publish) to do AOT compilation. But there are tradeoffs and AOT doesn't always mean faster performance.

But again, if you use the dotnet CLI you can just dotnet publish to create a AOT version of your exe. Just remember it still has the runtime and GC. You are just reducing the work of the JIT. Also AOT does not guarantee you will not JIT and still contains the MSIL. It's just a performance optimization where pre-compiled code will be used when possible.

Yes, I'm already aware of all this? I'm confused why you're explaining all this background—I'm well-aware of all this and my previous comments were already in response to these.

I think the short answer to your question is "no".

For single-file-no-project simplicity your best bet is dotnet-script: https://github.com/filipw/dotnet-script

For native code your best bet is NativeAOT: https://github.com/dotnet/runtimelab/tree/feature/NativeAOT

I'm not aware of anything that combines the two.

As to why: it's not so much that they've made it hard as they haven't made it easy. The reason they haven't made it easy is that it's a fringe use case. The main benefits of AOT are faster startup time, smaller storage requirements, and compliance with the iOS interpreted language ban. Most people who worry about those things don't mind having a project file.

They _have_ made some changes that may partly address your concerns. Visual Studio is no longer required to build C#; you can do it purely from the command line. There is also a new project file format. It's still XML, but much simpler. The HelloWorld example[0] from NativeAOT is a good example of how simple it can get. And the command line tools include an easy way of creating basic project files[1], so you don't have to memorize what little boilerplate remains.

[0] https://github.com/dotnet/runtimelab/tree/feature/NativeAOT/...

[1] https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-ne...

Gotcha, thanks!

The C# compiler has always been included with the .NET Framework, it has never required Visual Studio:

https://stackoverflow.com/questions/861384/is-it-possible-to...

On Windows using .Net Core makes this fairly trivial.

You basically install the .Net Core SDK and then run these commands to create your first executable:

  dotnet new
  dotnet build
  dotnet run

And I suspect it is the same on the other platforms

Here is an simple console example with more detail: https://www.zeusedit.com/phpBB3/viewtopic.php?f=5&t=8135

They were created by the same person.https://en.m.wikipedia.org/wiki/Anders_Hejlsberg All the hate C# gets is because of balmer and gates, not for technical reasons

Are you sure? My personal reluctance to C# has been that it's not handy for the stuff I do that needs to run on Windows, Mac, and Linux, which is everything.

there's always a bit of disdain from anything coming from MS I think that's a fair assessment

Relative to what? Assembly?

C/C++. Java. Python. JavaScript.

It should take less than 5 minutes to get it up and running. https://docs.microsoft.com/en-us/dotnet/core/install/macos

It took me about 60 seconds on a new EC2 ubuntu instance

Anything in particular? .NET 5.0 (and therefore C#) runs beautifully on Windows, Mac and Linux (x64 or Arm)

.net core has handled that well in the last ~3-5 years. Yeah, not a great rep before that but the new iteration/rewrite has been impressive.

I don't think it really started to settle down until .Net Core 3.0 which is just 18 months ago. Five years ago it was version 1.0 and a bit of a dog on all platforms.

What's your go to boiler plate for a new TypeScript project?

The three most popular kinds of TypeScript projects I create are:

- Node.js services built with Serverless framework targeting AWS Lambda - Create React App front-ends - Gatsby front-ends

For the first, I have a single shared webpack config that I reuse for all my serverless services. For the front-end projects, I just followed the few steps to add TypeScript support to CRA and Gatsby.

Once you suss out working with local shared dependencies, Serverless framework with typescript is pretty awesome. If I were starting a new project today I'd have to take a good hard look at this for my API back-end.

- Lambda Authorizers for token auth (or use the built-in stuff if you can get away with it)

- Lambda w/ API Gateway for individual endpoints

- Aurora for relational dbms

It's really a nicely put together ecosystem.

Reply on news.ycombinator.com