Programming languages: This old favourite is gaining popularity again (C#) | Hacker News Reader

Programming languages: This old favourite is gaining popularity again (C#)

zdnet.com

13 pointsokareaman6 comments

Microsoft's C# has always been popular language thanks to .NET developers, but this year it has seen something of a surge in popularity. Tiobe Software CEO Paul Jansen says C# is "by far the most likely candidate" to be named its programming language of the year, given to the language that's seen the highest increased in ratings in a given year.

Single binary executables in .Net 6.0 that run cross platform are the killer feature. The target machine does not need any supporting shared libs. That and the speed improvements.

Not the only good feature, though. I've been doing Advent of Code in C# this year to get my head around it. The standard library and language features seem to be sane and nicely-designed and I am having fun with it.

As an aside, it's always interesting to see how standard libraries do splits and joins between arrays/tuples/collections and strings.

In Perl they're both functions:

  @arr = split(/ /, $str);
  $str = join (" ", @arr);

In Python they're methods on the separator or tuple:

  arr = str.split(" ")
  str = ",".join(tuple)

That idea that you're telling comma to join a group of items always rubbed me wrong. In C#, joining is a class method:

  arr = str.Split(" ");
  str = string.Join(" ", arr);

Here "string" is a class name. The lack of parallelism grates on me somewhat. I think I would have preferred

  str = arr.Join(" ");

Does anyone know why this form is not used?

> Does anyone know why this form is not used?

Likely because early versions of C# (Pre-generics) wouldn't have had a good way to specifically offer a .Join method on string arrays specifically.

Now that we have generics, .Join() on an array normally refers to a type of Linq operation where you join two sequences together. You actually probably could make an extension method for your own usage in-app that would give you this functionality; if I had to guess why they didn't, I would assume it would consume Linq users.

OTOH that's kinda the nice thing about C# though. It's easy to go:

    public static class StringArrayExtensions
    {
        public static string Join(this string[] arr, string joinToken)
        {
           return string.Join(joinToken, arr);
        }
    }

and package such utility functions into a shared lib for your team to use.

There is a Join method in Linq, with entirely different meaning and matches string[]

https://docs.microsoft.com/en-us/dotnet/api/system.linq.enum...

> Single binary executables in .Net 6.0 that run cross platform are the killer feature.

This is a good feature but It presents packaging challenges and questions. For example, this example [0] used Single-file to create hello World at a size of anywhere from 60MB (No tweaks) to 30MB (Compression). Tree shaking (which can require careful testing and tweaks if your app or its libs use reflection) got it down to 11MB. By comparison, as an app requiring the runtime, it came out to 150KB.

> The target machine does not need any supporting shared libs.

There's caveats to that too; if you do have native dependencies (for example, an sqlite implementation) my understanding per the description [1] is that you have to include those as separate files, or configure it to bundle, in which case it will wind up having to self-extract. IDK if that gets 'cached' between runs when that happens or not.

[0] - https://dotnetcoretutorials.com/2021/11/10/single-file-apps-...

[1] - https://devblogs.microsoft.com/dotnet/announcing-net-6/#sing...

I would agree with you except terabyte drives are so cheap these days that 30MB doesn't seem like a big deal anymore. There are situations when multi megabyte apps are a problem, but not my situations.

Reply on news.ycombinator.com