Live data from Hacker News

C# 9 top-level programs and target-typed expressions

developers.redhat.com

101–110 of 188 posts

Re: C# 9 top-level programs and target-typed expressions

#101
post #91

I mean, top-level programs are nice, I guess? IMO it's more of a means of attracting non-.NET developers into the fold. I work in a .NET shop and we probably won't use this in our production code. The benefit of target-typed expressions IMO is that it changes property syntax from: public List Foos = new List (); to simply: public List Foos = new(); It may seem subtle, but if you write C# you see this pattern constant…

top level is mostly going to be nice when teaching new programmers. You can just get on with hello world and now have to type all this boiler plate and explain why you have to. But yeah, for "real" programs it is probably irrelevant. But who knows, maybe we will find a use for it. I am mostly excited about the sort-of option type getting rid of nulls option.

> top level is mostly going to be nice when teaching new programmers. You can just get on with hello world

Yeah it seems like kind of a weird thing? “Here’s marginally less boilerplate once, if someone is going to learn to use the language, they may as well learn how it actually works instead of hiding stuff that they’ll soon see anyways...

Re: C# 9 top-level programs and target-typed expressions

#102

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 bet…

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.

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...

Re: C# 9 top-level programs and target-typed expressions

#103

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 bet…

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.

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.

Re: C# 9 top-level programs and target-typed expressions

#104

Earlier quoted context omitted.

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.

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'…

Gotcha, thanks!

Re: C# 9 top-level programs and target-typed expressions

#105
post #57

Earlier quoted context omitted.

I don’t think they’re just randomly throwing stuff at the wall. These are all things they’ve been talking about for years.

The C# language design process is very much in the open, so anybody can go and take a look at the rationale etc. https://github.com/dotnet/csharplang

I think it suffers from the design by a self-selected committee now. Very little of recent changes have long-term vision behind them now, and seem to be quick patches.

Specifically, I just tried disabling 7.0+ features in an open source project I run, and we only actively used pattern matching for "is MyType inst", ref structs (hi Rust!, that one is really fundamental), and natively sized integers (which are still poorly supported by runtime).

Other sugar changes have uses across codebase you can count by fingers of one hand.

We also use unmanaged function pointers, but the feature appears ugly in many ways. For our purpose, I'd prefer a tiny bit more flexible DllImport (a hook to give it the dll path at runtime) over function pointers.

Re: C# 9 top-level programs and target-typed expressions

#106

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 bet…

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

Re: C# 9 top-level programs and target-typed expressions

#107
post #98

Scala 3 kills C# by a large margin, imho. C# is not a good pursuit unless you are stuck with .Net codebase.

How so? .NET is 2-4x faster than Scala in benchmarks (https://www.techempower.com/benchmarks/#section=data-r20&hw=...). Do you just prefer the syntax and language features?

Re: C# 9 top-level programs and target-typed expressions

#108
post #69

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 bet…

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.

Re: C# 9 top-level programs and target-typed expressions

#110
post #98

Scala 3 kills C# by a large margin, imho. C# is not a good pursuit unless you are stuck with .Net codebase.

Scala is a great language with terrible (in comparison) tooling. I'd use it (or F#) over C#, if IDE support was not as slow as it is, and if it was comparable to ReSharper/IDEA Java feature-wise for refactoring.
Post reply on HN