8 ms·
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 performan
by binarynate 6y ago
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).
- zwieback 6y agoC# 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.
- josteink 6y agoHow do you think they built the Linux-version of the .NET standard library? ;)
- adolph 6y agoLots of wine?
- scott00 6y agoInterop on Linux works well.
- meibo 6y agoC# 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.
- pjc50 6y agoThe 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)
- keithnz 6y agoAlso 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.
- Salgat 6y agoAzure 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.
- blake1 6y agoI’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.
- binarynate 6y agoYes, 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.
- zwieback 6y agoThanks, I'll give it a try. I've done a lot of interop in Windows so it'll be good to leverage to Linux.
- merb 6y agoit'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))
- dataflow 6y agoA 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.
- DownGoat 6y agoIt 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/ https://docs.microsoft.com/en-us/dotnet/core/tools/
- MikeTheGreat 6y agoIs 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. :)
- oblio 6y ago> Is it possible to create a single, stand-alone, self-contained .exe? Yes.
- smcl 6y agoYes 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-looks-like https://blog.mclemon.org/no-this-is-what-peak-hello-world-lo...
- bob33212 6y agoThey were created by the same person.https://en.m.wikipedia.org/wiki/Anders_Hejlsberg https://en.m.wikipedia.org/wiki/Anders_Hejlsberg All the hate C# gets is because of balmer and gates, not for technical reasons
- xbar 6y agoAre 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.
- agumonkey 6y agothere's always a bit of disdain from anything coming from MS I think that's a fair assessment
- bob33212 6y agoRelative to what? Assembly?
- benaadams 6y agoAnything in particular? .NET 5.0 (and therefore C#) runs beautifully on Windows, Mac and Linux (x64 or Arm)
- bkuehl 6y ago.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.
- devilduck 6y agoC# is perfectly rated, I assure you. Not under-rated at all.
- jjice 6y agoWhat's your go to boiler plate for a new TypeScript project?
- binarynate 6y agoThe 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.
- twodave 6y agoOnce 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.
- quietbritishjim 6y agoI 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?
- abdusco 6y agoThe term you're looking for is obfuscation. This seems like a good roundup: https://github.com/NotPrab/.NET-Obfuscator https://github.com/NotPrab/.NET-Obfuscator