Hacker News Reader

Comment by twotwotwo | Hacker News Reader

C# was mostly irrelevant to me a long time when Microsoft's implementation was closed, but there are some neat things about it. They've done a lot of interesting stuff in the language since it first came out, including pragmatic sugar-y stuff like type inference (`var`), async/await, and recently some moves towards more functional-style pattern matching though they're not totally there yet (https://www.kenneth-truyers.net/2016/01/20/new-features-in-c... discusses proposals, some of which didn't make C# 7). Interfaces and value types also seemed like important things to have early, and there's some other handy looking stuff like the SustainedLowLatency GC mode (defer full-heap compactions as long as it can).

Can be tempting to think of it as a Java clone because of its early history and the shared general category (OO-focused GC'd imperative statically typed language whose first major impl was bytecode/VM-based), but there's signs of more to it than that.

View on HN

I feel as though, with C#, Microsoft's brilliance was to get a number of very clever people in a room together (Anders Hejlsberg, Eric Lippert, etc).

Somebody at Microsoft said to themselves, these guys are clearly brilliant, let's see what happens if we hire them all, task them with creating a new object oriented programming language, pay them a tonne of money, and see what happens.

C# was the result, and it's awesome!

Don’t forget former Arhus professor Mads Tergesen, he’s been the lead C# designer for sometime now.

The problem with C# for me is the fragmented ecosystem that's hard to navigate, coupled with dense and hard to find documentation that seems to be spread out over 14 different msdn domains and GitHub projects.

CoreFX? CoreCLR? No idea what these are or what they're for.

And don't get me started on the dumpster fire that is roslyn. I've tried no less than 10 times over the last few months to get "intellisense" working in emacs via roslyn and it has never worked.

C#'s a cool language that I want to like but it's just so much work to get started with.

There are many more names for things in C# than what you really need to be aware of as a C# developer. Want to write C# that targets Linux? Download the .NET Core SDK. Simple as. Everything else: .NET Standard, .NET Framework, are just names used by the .NET contributors to keep things straight in their head, but you honestly rarely deal with that stuff if you’re starting fresh with .NET Core.

If you’re trying to write C# in emacs you’re doing it wrong. C# has probably the best tooling in the world if you embrace it.

Agreed. I basically live in emacs, but for C#, I'm in VS 2017 community and it works great.

C# has a decade and a half of hyper-fast Microsoft-funded idea churn behind it, so I agree that it can be super confusing. It's very hard to distill it down to the "modern" stack when every Google hit gives you piles of results that are painfully out of date.

I love c#, but I've been using it since '05. I don't envy newcomers.

What is it with using C# w/ emacs that is wrong? Compared to say development of Java or python code on emacs? Although it doesn't have all the tooling present from say VS, it is still managable with refactoring, autocompletion and some more functionality working already.

I am the current maintainer of omnisharp-emacs and would love to know out what are the most pressing problems people encounter using C# on emacs via omnisharp - https://github.com/OmniSharp/omnisharp-emacs

I've never been one of those guys who gets super into his editor, as I don't see it as being the driving force in productivity or efficiency. VS Code or VS Community are my go-to, because they have all the features that are possible. I'm not being pulled away to find a solution to a solved problem: it's there, and it's solved.

How does time travel debugging work in emacs?

Ah, .NET debugging is not implemented in omnisharp-emacs as debugger service is not provided by the underlying omnisharp-roslyn project (the parent language server project).

So you are expected to download VS Code, use sdb or something else if you want to have step-by-step debugger...

To be fair, C# is a chore without good tooling.

I used to use omnisharp with atom and frankly it was just rubbish. It crashed all the time and required constant restarts, and (still) takes a massive amount of time (and memory) to start.

I went back to using golang, and didn’t regret it for a second. The tooling in go is excellent and you can use a simple editor for many things. That’s really compelling for people.

So... to be fair, if you were to idly pickup .net core as a linux user, and expect vim or emacs to do the job, you’ll find it a terrible experience.

...but, with the right tooling, it can be really great. vs, cscode or rider (not free) make using c# a pleasure to work with.

The dotnet cli tool is still quite terrible (how do you install dotnet watch again? why does it take 25s to restart a simple web app? You think git has obscure inconsistent incomprehensible command line flags...? ha! remind me why ‘dotnet build’ is running like 50 shell commands from the .csproj file...but only in this configuration you didn’t specify excplictly? surprise!) ...but its usable, and its slowly improving.

I feel like a lot of C# enthusiasts shoot down complaints as people being rubbish, or trolling or ‘doing it wrong’; but the reality is c# on a platform other than windows is new, and still pretty raw.

Pointing people in the right direction (you do need a proper IDE) and acknowledging that doesn’t suit everyone is better than telling them they’re ‘doing it wrong’; thats just jerk behaviour and comes off as fanboiism.

C#'s bread-and-butter was desktop apps and then web servers.

I've yet to see good Windows GUI support for Go.

Let me know when Go has something comparable to Windows Forms, WPF, UWP, Xamarin.Forms, Avalonia.

Oh, and when I have to use Go, I find a chore to write generic code as if I was back in 1992 using Borland C++ 2.0 for MS-DOS, with pre-processor based code generation for BIDS or still using Java 1.4 (EOL in 2008).

When was the last time you wrote a micro service that compiled to a single binary and interop'd seamlessly using grpc in C#?

I'm going to guess the answer is never, because it's basically impossible to do.

Do you care? I doubt it, but some people really do.

It's just different use cases for different things. Sure, go has its problems, but needing a large heavy IDE isn't one of them. That's really important to some people.

/shrug

> Oh, and when I have to use Go, I find a chore to write generic code...

Oh man, don't even start. If you don't like go, don't use it. It was just one example of tooling that's better than C#. Rust, node, clojure, heck, even python has a better story for 'pick up and start using' than C# does at the moment.

Do we really need to start digging down into how fundamentally terrible nuget is as a package manager, and how I personally find it like installing Master of Magic using 3 1/4 inch disks one by one when it screws up, or the feed screws up (like it did TODAY for about 4 hours)?

nah. No one cares.

Let's just leave it at: There are some valid concerns people have with the C# ecosystem, and using C# on non-windows platforms. It's a work in progress.

At least we now have a coherent direction for everything going forward~

> I'm going to guess the answer is never, because it's basically impossible to do.

You mean by using something like Mono -aot, CoreRT, IL2CPP?

> Do we really need to start digging down into how fundamentally terrible nuget is as a package manager,

No, because in spite its issues, it still runs circles around the half-baked solutions that Go devs are still trying to fix.

I'm not even going to bother.

Nuget is such a pile of rubbish it's not even worth arguing about; if that's the best package manager you've ever used, you should really go check https://github.com/fsprojects/Paket out.

(they also helpfully articulate why nuget isn't really very good)

The irony is that the folk from go-world have finally acknowledged the package management solution they have is really terrible, and they're building a lovely new one (https://github.com/golang/dep).

Maybe sometime in the future you'll be eating your words, when go has a lovely package manager.

...and c# still has nuget.

Hey, current maintainer of omnisharp-emacs here.

Would you be willing to submit an issue to github about the problems you have encountered (if not already?)

I would love to make the experience of using C# on emacs with omnisharp-emacs easier for people.

> ... Coupled with dense and hard to find documentation that seems to be spread out over 14 different msdn domains and GitHub projects.

docs.microsoft.com is steadily improving this.

> I've tried no less than 10 times over the last few months to get "intellisense" working in emacs via roslyn and it has never worked.

https://github.com/OmniSharp/omnisharp-emacs

Are you not using this? Works great for me.

If you want getting started to be less of a chore use VS Code, VS, Rider, VS for Mac, Xamarin Studio, or Monodevelop.

The fragmentation was really what allowed the new breakneck pace of development. I’m a c# developer full time since 1.0 and I have huge problems following even though I’m 100% on the “old” (desktop) frameworks.

I’m hoping that things will slow down and converge again in a while.

It probably seems fragmented because it's easy to get things confused, and Microsoft isn't making life easy during their journey in open sourcing the whole stack (or at least significant portions of it).

There's the languages (C#, F#), there's the runtime (CLR - Common Language Runtime), and then various frameworks (including the base framework, and the ASP.NET framework). Then there's the difference between the original variants of these and the new 'Core' variants.

Plus there's various other related bits like the .NET Standard projects which are meant for library developers to target to make library cross-platform portability easier.

As for difficulty getting intellisense working via emacs - that's certainly been something demoed, but it's not really a well tested use-case at this time.

If you're coming at it from a non traditional (Windows) developer perspective - then you're looking at a massive ecosystem in flux and in migration from being a primarily single platform to multiplatform.

Sure. Sharing mostly the same view of this (hi)story... but: did those guys leave? lost their muses? What happened besides maturing and "standards"-lockdown... outside of some smaller bubbles and marketing gigs the whole eco-system seams stagnant and mostly irrelevant to today's internet/web development... despite so obvious interest of the company. What happened? What did not happen? (besides mono and unity)

Also TypeScript and Turbo Pascal and Delphi.

> He currently works for Microsoft as the lead architect of C# and core developer on TypeScript.

https://en.wikipedia.org/wiki/Anders_Hejlsberg

"Can be tempting to think of it as a Java clone".

C# is superior to Java in every way I can think of. Just a couple examples, unsigned types, simple value types without boxing, and a real generics implementation (java generics are truly awful). The reflection API is c# is also far more useful and easy to understand.

Java enums are better. Seeing as C# is going to run on more than Windows that's about all I can think of.

Anonymous inner classes are more powerful than c# anonymous types. I think c# wins out overall, but there are a few corners where Java has features c# is missing, coming from the fact that c# was a bit more pragmatic where Java was a bit more oop-purist in its origins.

Anonymous delegates (which have been available since 2.0) are the equivalent feature in C#, at least as far as use cases go.

While anonymous inner classes are more verbose, they're also more powerful because you can create a whole class instead of a single method.

But, they're equivalently powerful with respect to an API.

In Java, a method might expect one instance of a class, to which you can pass an instance of anonymous class, whereas in C# a method might expect a set of delegates, to which you can pass a set of anonymous delegates or lambda expressions.

However, thanks to C#'s type inference, it actually ends up being far less verbose, yet more flexible, because anonymous delegates and lambdas can close over local variables. So, strictly speaking, they're more powerful than anonymous inner classes.

On the other hand, as someone that greatly admires Smalltalk, I sometimes envy Java's slightly better purity.

During Java early days, I was a big fan of Eclipse's Java browsing perspective, it was a way to feel like I was still using Smalltalk.

Delegates are nice in the common case but I do miss anonymous classes.

Anonymous classes have better oo organization than passing in two or more delegates. Sometimes variable capture doesn't cut it or isn't as clear.

..And the biggest thing. I can pass it in to a method that already takes a class and not a delegate.

> And the biggest thing. I can pass it in to a method that already takes a class and not a delegate.

One solution is the build a small inventory of "ad-hoc" classes that just wrap a delegate (usually a closure), as described here: https://stackoverflow.com/questions/20703002/does-object-exp...

What are the features that c# is missing? As the other comment explained delegates are the equivalent of anonymous inner classes and are far better. Checked exceptions are really a nuisance, I would call them a negative feature. Java enums in c# are basically classes with readonly properties if you need to pass constructor arguments. Streams in Java are a huge clusterfuck. I can't think to anything that Java has that is better than c#.

It'd be great if the secret to language design was cramming in as many features as possible.

Delegates are not the equivalent of anonymous inner classes. They're commonly used for similar design patterns (observer and other callbacks), yes, but they're not the same thing. To be more specific, an anonymous delegate / lambda can be thought of as an implementation of an interface with a single method. But with Java anonymous inner classes, you can implement multiple methods at once.

The reasons why Java enums are better, is because they're actually constrained to the domain you specify. In C#, the range of values for any enum is the same as its underlying integer type - it's just that some of those values have names, while others don't. But it's always legal to cast (and few people know this, but 0 is always a valid enum value that you don't need to cast) - so any method you write that accepts an enum value has to validate it. In Java, since enum is basically a final class with a bunch of private singletons, you are guaranteed that the reference you get points to one of those.

That said, given that C# now has pattern matching, and it seems to be getting more powerful with every release, I'd be surprised if it didn't get something like case classes very soon.

Delegates and anonymous inner classes are equivalent, modulo API:

    //Java
    
    Bax.addHandler(new Foo()
                   {
                       @Override
                       public void Bar()
                       {
                           doSomething();
                       }

                       @Override
                       public int Baz(X n)
                       {
                            return computeInt(n);
                       }

                   });
    
    //C#

    Bax.AddHandler(() => DoSomething(), n => ComputeInt(n));

But, anonymous delegates and lambdas are at once syntactically nicer and more powerful, because of type inference and the fact that they can capture local variables.

Regarding Java enums, the actual equivalent feature in C# is class nesting. There is a tiny bit more ceremony involved in defining them, but they're more flexible than Java enums. For instance, you can decide whether or not to implement them as readonly (final) fields, or as static properties, depending on how much you care about cache friendliness.

    public abstract partial class SomeEnum
    {
         private SomeEnum(){}

         public abstract int Biz();

         sealed class AFoo : SomeEnum { public override Biz() => 2 }
         sealed class ABar : SomeEnum { public override Biz() => 4 }         
         sealed class ABaz : SomeEnum { public override Biz() => 8 }         
  
    }

    //Singleton implementation:

    public abstract partial class SomeEnum
    {
        public static readonly SomeEnum Foo = new AFoo();
        public static readonly SomeEnum Bar = new ABar();
        public static readonly SomeEnum Baz = new ABaz();
    }  

    //Cache friendly implementation:

    public abstract partial class SomeEnum
    {
        public SomeEnum Foo => new AFoo();
        public SomeEnum Bar => new ABar();
        public SomeEnum Baz => new ABaz();
    }

It's also worth noting that extension methods on C# enums give you most (all?) of the power of Java enums.

On your delegates example for C#, since the parameters of the lambda and methods match, and you aren't relying on any closure behaviour, you can use 'method group syntax' to make it even more succinct:

  Bax.AddHandler(DoSomething, ComputeInt);

That is only equivalent within the boundaries of your API (i.e. when you use them as pure callbacks). But your delegates are two different objects, while in the Java example, it's a single object. This makes a difference if, for example, object identity matters.

From practical purpose, Java anonymous classes can be used in any scenario where you need to create a one-off object that derives from a class or implements one interface. A delegate can only be used in a scenario where the receiving variable or function wants a function type.

I'm not arguing that delegates are lambdas are bad, mind you. For the common scenario involving callbacks, they're vastly superior. But they're not a complete replacement for Java inner classes.

Yes, but we can recover all of the power of anonymous inner classes by building up a (usually small) set of "ad-hoc" classes that just wrap delegates, as I explain here: https://stackoverflow.com/questions/20703002/does-object-exp...

By the way, thanks for your work on PTVS, I just discovered it recently.

But they aren't really anonymous then, since you have to write a wrapper class for every class or interface that you intend to implement inline.

By the way, I totally forgot about F# object expressions! But they're a good example of this feature. Better than in Java, in fact, because they let you implement multiple interfaces. Also, IIRC, they're true closures (whereas Java only lets you close over finals, not writable locals).

Ideally, you'd have both those and lambdas in a language, like C# and Scala do. If I had to choose, though, I'd definitely pick lambdas - that is the 90% use case.

Brevity is the feature, not anonymity. What C# actually lacks is syntax sugar. But, a few years ago, I spent an hour or so implementing `Ad-hoc` classes for most of the interfaces and abstract classes that I thought I would ever need, and it's been sufficient over 90% of the time[1]. N.b. these classes could have been generated programmatically.

I'm not claiming that the technique is exactly equal to what Java gives you out of the box, but rather that C# can get within epsilon. In other words, for my purposes, the prefix AdHoc- might as well be a keyword (as in AdHocIEquality<T>, AdHocIEnumerable<T>†, AdHocDisposable, AdHocHttpHandler, etc...), because it's indistinguishable from syntax sugar.

On the other hand, the F# object expression really is more than just syntax sugar, because of the way it interacts with type inference (no need to upcast to satisfy the type checker), and (as you noted) that it can implement an arbitrary set of interfaces. But, it's not all carrots and apples: F# lambdas don't work well with protected members. Meanwhile, C# can close over just about anything (a ref local, such as Span<T>, being the obvious exception).

[1] https://github.com/noblethrasher/AdHoc-Implementations/blob/... (in a newer version, I implement the interfaces explicitly)

† which, really only works well in VB because lambdas can contain `Yield` statements.

Side note: in C# 7.0, local functions (which, while not anonymous, are true closures) can contain "yield".

- Better enums

- The way one can plug into JIT code generation via invokedynamic, methodhandles and varhandle bytecodes

- A JIT compiler written in Java (Graal), now pluggable in the reference JVM

- An actual roadmap to rewrite remaining C++ from OpenJDK in Java (Project Metropolis)

- The research being done in Graal and Sulong about using Java to write compiler infrastructure

- Being portable to devices where the CLR probably will never be ported to

- A a better JIT in what concerns dynamic code re-writting

- Multiple implementations, some of them with AOT support, from disparate vendors

I just enjoy using both eco-systems since they exist.

> An actual roadmap to rewrite remaining C++ from OpenJDK in Java

Very cool. I wasn't aware of that. Do you think this will help introduce more "low level" features in Java since it is paramount to at least keep the same level of performance, and definitely improve it in the future?

Yes, this is nothing new, there are a few meta-circular JVMs, just they weren't commercial products.

Jalapeño from IBM,

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.8...

Sun's own Squawk VM, used on Sun SPOT before IoT was a thing.

https://www.researchgate.net/publication/221320697_The_squaw...

https://en.wikipedia.org/wiki/Sun_SPOT

Regarding Project Metropolis specifically, you can find the information here.

"Your next JVM: Panama, Valhalla, Metropolis by John Rose"

https://www.youtube.com/watch?v=OMk5KoUIOy4

http://cr.openjdk.java.net/~jrose/metropolis/Metropolis-Prop...

Note that I wasn't completely fair, the .NET team also has some plans to incrementally move the runtime into C#, but so far it has only been mentioned on an InfoQ interview, no official plans revealed.

https://www.infoq.com/articles/virtual-panel-dotnet-future

"So, in my view, the primary trend is moving our existing C++ codebase to C#. It makes us so much more efficient and enables a broader set of .NET developers to reason about the base platform more easily and also contribute."

> What are the features that c# is missing? As the other comment explained delegates are the equivalent of anonymous inner classes and are far better.

Not entirely. .NET delegates don't support generic type parameters (aka first-class polymorphism). Methods in C# and Java do.

C# interfaces also don't support static methods, which are useful for factory patterns. C#'s factory patterns require a lot more code as a result.

C# also has a bunch of artificial limitations, like not being able to specify type constraints on Delegate, Enum, and a few other built-in types. It's just nonsense.

The rest of C# is overall better than Java though.

Not sure what you mean by "delegates can't accept generic type parameters" because you can certainly make a delegate with a <T> in it in C#

There is no delegate equivalent of passing around an instance of IFoo:

    interface IFoo
    {
        void Bar<T>();
    }

This is known as first-class polymorphism.

Classes with methods are strictly more powerful than delegates, but they shouldn't be. It's even worse than that actually, because you can't even create an open instance delegate to a generic interface or abstract class method (you'll get a runtime error, not even a static error).

> The reflection API is c# is also far more useful and easy to understand.

It's really annoying that you can't query a Java package to find out what classes it defines.

A java package is a namespace right? In .NET you can't query a namespace, but you can query a module (very rarely used) or assembly. Surely Java has something to query a jar.

A package is the equivalent of an assembly

If this is technically incorrect, as suggested by the voting, I'd appreciate someone setting me straight.

An assembly is closer to a JAR. It is a single unit which can contain multiple namespaces. However, in the Java runtime, the package is the top-level organizational unit. In .NET, it's the assembly. The fully qualified type name in .NET contains the assembly, namespace, and type name. In Java, it's just the package and type name.

There's nothing built-in quite like that. However, in normal circumstances, you can do it on top of what's in the JDK: pick a class you know is in the jar, load it as a classpath resource URL, parse that URL to find the jar, then read the jar using the built-in jar support. There are other ways to do it, eg starting from the classpath and working down. There are any number of libraries for doing this, eg:

https://github.com/lukehutch/fast-classpath-scanner

As a language, yes C# is probably better. If I may grant Java a pithy defense as a C# user not as a contradiction but additional information.

On the implementation side, Hotspot blows the CLR out of the water on performance. All things being equal that is, not handicapping the Java code, bottlenecks "for realism" and other benchmark-defeating tricks.

Java is the superior serverside solution. Other than Hotspot performance, the other big selling point is Java's vastly larger opensource library selection.

I like both. I like the fat OOP space. Maintenance reasons is a huge one, I don't want to get burned having to maintain some fly-by-night's code in 10 years from a Frankenstein's creation of random JS libraries. Both Java and C# are industrial-strength designs, with good tooling and a swath of devs.

Between the two, I'd still reach for C# myself, because at this point you can have an almost entirely C# codebase from the server to the client. It's good enough in the performance and library aspects that Java holds over its head. I'm expecting the C# package to be quite complete once it adds compiling to wasm to its list. But if I made a career switch, it would be from C# to Java, and nothing else. I admire Rust and (especially) Elixir but no jobs in my area for either of those.

Java is faster for high-level code. The moment you start using structs and stackalloc and whatnot, Hotspot cannot really keep up.

Even for high-level code, it depends on the kind. E.g. Java generic collections have to box value types; I'm not sure if Hotspot even tries to avoid it - I think it does these days - but this kind of analysis is necessarily limited in scope. In C#, value type generics are fully reified, even on JIT level - every combination of type parameters gets its own JIT-compiled implementation.

That is just temporary glitch, until Java gets value types.

The biggest problem is that no-one wants to do a Python3 on the pile of Java code written in the last 20 years, so of course that have been doing baby steps, which are starting to see the light now post-Java 9.

And they will come, because Java is feeling the pressure on Fintech from companies that want to move away from C++, but still feel some pain, ergo Pony.

Java also needs such features for Project Metropolis, the JVM can only be successfully rewritten in Java, if there are no performance regressions.

Also, IBM and Azul JVMs do have language extensions for value types.

Well, it's been a temporary glitch for, what, 13 years now?

Yes, Java will fix this eventually (although, doing this for generic collections would also require reified generics, no?). But, of course, C# will also advance further in that time.

The general problem, I think, is that the process that Java uses for language evolution is deliberately slower than C#, so C# can bring new features faster. There's a trade-off there in that there's also less breakage, and acquired Java skills take longer to become obsolete. Which probably has something to do with why Java is still very prominent in the enterprise, and in industries like banking.

Well, C# did not switch hands among a company acquisition, whose owner lost sight how to move forward the language.

Even C# does move slowly, these lovely C# 7.2 features that I can already use on my private projects, will take years to be allowed on my typical set of customers, the enterprise.

I just helped one transition to .NET 4.6.1.

Likewise another one just moved into Java 8 this year.

Worse is the Android situation, regardless of the features Java might get, even feature parity with C#, Google will cherry pick only the ones they care about.

The nice thing about many new C# features is that they are still supported on older runtimes. So you can ship stuff that runs against 4.5 or even 4.0, while using e.g. the new property syntax, or inline out, or even pattern matching (for your own classes). For something like tuples that needs library support, they now provide the requisite bits as NuGet packages - if I remember correctly, the one for tuples is also 4.0 up.

Yeah, but that is a side effect of the CLR original target, as a means to support any language, including C like ones.

Which is ironic that nowadays JVM gets more languages, with compiler backends pretending to be Java like, while .NET SDK 1.0 even had multiples examples of programming languages.

I didn't know that. That's beneficial for me to know and makes sense.

I recently made my career change to become a C# developer so I did a good indepth review on the overall landscape. Came down to Java and C# as my best bets, C# won because it fits a lot of my work history and I've heard multiple people that I trust say they just can't find .Net developers. To me that's a feature. I really like it and don't understand all the hatred and fashion-oriented programming trends going on. Honestly, I'm more about maintenance and all the best tooling to help me get complex tasks completed without issue. Of course, maintaining employment is important too, has to be jobs around. I spoke with a few companies, one is switching from a .Net stack to Node and I think that's insane. I'm not sure why you'd actually willingly accept a downgrade like that. Maybe if you're starting from scratch, sure do what you will, but overall I expect the "app" side to JS to dwindle away as wasm takes over. I intend to build most of my webpages leveraging as much of the native browser functionality as possible, leaving apps to Xamarin and wasm for native code solutions.

I like the irony, you can not say that C# is superior to Java in every way in a discussion about C# Span while Java as ByteBuffer (the same API) since Java 4 (circa 2002 i think).

Span<T> out of the box you can use with any type, not just Byte, Char, Double, Float, Int, Long, Short

It can be put over an array (as per ByteBuffer); but also over stack allocated memory; a native pointer T* etc

The underlying allocation is separate from the type

ByteBuffer provides universal access to on heap/off heap data.

JNI or Unsafe allow to create ByteBuffer from native pointers, created in C/C++ or in Java using malloc, memcopy them, etc. This is used (and abused) by most web servers, DataStax or LMAX-Exchange have even created their whole business on that.

You also have have CharBuffer, DoubleBuffer, FloatBuffer, etc

There is no stack allocated ByteBuffer in Java (Java provides no stack access, this is religious) but in Java can do relaxed data access on Buffer element, volatile access, opaque access, CAS, etc.

This is the same API.

Does it work over non-primitive and user defined types?

Object, InetAddress, etc

Though only `struct` value types should be used in stack or native memory due to risk of GC holes

No, not yet. I believe there is a prototype of that kind of buffers that comes with the valhalla project (value types) but i've not tested it.

Don't forget tail recursion!

It's worth mentioning that C# is one of the most flexible languages available today.

Not many languages can claim a great web development, native GUI, native mobile apps, and first-class gaming development, story.

> handy looking stuff like the SustainedLowLatency GC mode

Don't forget "server mode" GC. I have a long-running, memory-intensive console app which was taking about 45 minutes to process a typical batch of data. With some profiling I discovered that after the 20 minute mark, most of the time was spent in GC. Some of the classic optimisations (classes to structs, new list to list.clear) helped get the processing down to 30 minutes. After some more Googling I discovered and tried server mode GC. Suddenly it took less than 13 minutes.

> They've done a lot of interesting stuff in the language since it first came out

It was always interesting to see which features were just syntactic sugar (and thus backwards compatible) vs. which required runtime support.

out of curiosity why do you know so much about a language that was "mostly irrelevant to you"? Were you forced to develop in it for work, or what happened? For being irrelevant, your comment suggests you've been tracking it super closely (you link a discussion of proposals) ... (quoting you) "since it first came out"!

I just read about and play with things I don't use for work or any real projects--recently-ish I posted about Dart/Flutter here, and I worked through some basic Kotlin exercises after Google announced it as a supported language for Android. ML languages fascinated me early on; I think OCaml was the first language I saw with both strong typing and good type inference to keep code from getting verbose. Once I started looking deeper the pattern matching seemed like a key feature. Stuff like WebKit's new Riptide GC for JS is interesting (concurrent and generational but not copying is a neat corner of the space I hadn't heard much about). Rust is making progress on low-cost memory- and thread-safety. Computers can be interesting!

HS/college was a lot of C(++). My work has been Perl (I'm old) and then Python/Django (with the usual sprinkling of other stuff: JS, bash, etc.). Go has been a surprisingly intense hobby over the past few years and it's probably the only lang I could bust something interesting out in soon without much of a learning curve. (I guess also some of the close cousins of JS out there, but not really a brand-new environment then.)

I did play with very early (pre-`var`) C# more than 10 years back (I'm old!), but that was before most of these improvements happened and before I understood the relevance of the things like value types that were in there from the start. It's interesting now mostly as another point in the space of programming languages/environments, e.g. different tradeoffs around GC, generics, etc. Guess it has somewhat more potential to be relevant to me as an open/cross-platform project, but it's hard to see myself making the big time investment to actually get up to building-stuff speed in it just for giggles. Similar feelings about Swift or Kotlin, FWIW. (Not that I'm totally ruling anything out, but I've got stuff to do!)

That specific discussion of proposals I just Googled up looking for the C# pattern matching stuff. I first heard about it via a different link posted on lobste.rs a while back, but it was faster to Google this than look for that.

thanks, this was interesting!

C# is a more polished and "prettier" Java. It has done well with it's incorporation of functional programming, generics, dynamic programming and syntactic sugar in the last few releases. Too bad it's pretty much confined to the windows ecosystem.

It's not confined to the Windows ecosystem, aside from Mono there's now the officially supported cross-platform .NET Core.

It's definitely not confined to the windows ecosystem. I develop C# on OSX via Jetbrain's Project Rider and run the developed code on anything from linux to docker instances.

In some alternate reality, progress on the Java language doesn't get lost in the shuffle in the death of Sun after 1.6 was released. Those five years of relative stasis hurt, especially where C# was making such strides.

I took the AP CS test in high school with Java 6, and four years later, the jobs I was looking at after college were still Java 6. The ones where companies weren't still on Java 5, or even more archaic releases.

> Too bad it's pretty much confined to the windows ecosystem.

We released games written in C# for iOS, Android, Windows Phone, Windows PC and Linux servers.

Our server library and framework software suite and Apps have been running cross-platform for several years and with the support of .NET Core 2.0 they now run fast and flawlessly on Linux which is a very popular deployment target for our Customers, in fact all our .NET Core Live Demos were developed on Windows and deployed to and running on Linux:

  - https://github.com/NetCoreApps/LiveDemos
  - https://github.com/NetCoreWebApps/LiveDemos

Each project can also be opened and developed on Linux or Mac with VS Code or Rider. Xamarin's solutions has been making C# a popular language for developing native high-performance iOS/Android Apps for several years and the stigma of C# server apps being confined to Windows should be eradicated with the advent of .NET Core.

> pretty much confined to the windows ecosystem.

That's interesting. Apparently I'm dreaming that I'm developing with C# on my macOS and deploying to Linux?

It's cross platform now.

I've recently implemented a rich GUI software for embedded ARM linux, running on .net core 2.

Works OK, however I spent substantial time implementing GUI stack (dllimport, NanoVG, GLES, DRM/KMS).

Reply on news.ycombinator.com