As a C/C++ developer, C# feels like unreachable high level heaven. But then again, I prefer my code to have no garbage collector, be portable without any problems and have very high performance. So, C++ it is. If I was writing a Windows-only GUI app with no resemblance of realtime requirements, I would only use C#.

Across how many compilers and operating systems is your code portable without any problems?!

When written with discipline C++ is very portable. I've worked on codebases that spanned devices with ~8mb of memory to full-blown desktop PC and arches(x86/MIPS/ARM/PPC just to name a few).

Writing with discipline is a synonym for writing castrated C++, to avoid touching language features not yet implemented or with slight semantic differences across compilers.

One of the things that attracted me to Java was that I finally could write something where I could use 100% of language features and actually use it everywhere.

C++17 is around the corner, yet most embedded, mainframe and commercial UNIX vendors are between C++11 and C++14, in the few cases where they already support anything from C++14.

Then there are the UB and implementation defined differences across those compilers.

Across devices it seems it is very portable.

Now, across compiler vendors and versions it is hard

Generally speaking when you are targeting that wide of a range of devices you are targeting a wide range of compilers. It requires some discipline but it's far from the hardest thing in the world assuming you are regularly building and testing for all platforms. I'd say that most major C++ applications or libraries compile in Clang, GCC and MSVC without issue and often build for less common targets as well (icc, nvcc for cuda support, etc.) Things definitely get harder when you move to weirder embedded platforms.

Yup, we targeted GCC, MSVC, plus a few proprietary compilers. As long as you stick to a reasonable set of features(which you should anyway for sanity reasons) it works pretty well.

Having a good CI is a must though but it's not nearly as hard as porting an old codebase backwards.

It's just a configuration problem - at one job, we had a million line code base compiling with clang, gcc (2 versions, can't recall which), on 2 versions of solaris, 2 versions of linux, and linux 32bit and 64bit, plus windows on VS2010, and 2015, so that makes 18 *nix builds and 2 windows builds, so 20 different C++ builds of one code base. All unit tested, and regression tested. Get your CI system of choice working, e.g. TeamCity, fix your makefiles, and you're good to go.

Having done C and C++ across UNIX and Windows, during the late 90's throughout mid-2000's, using the OS vendor's compiler tooling, it was a bit more than just configuration.

For example, back then aCC wasn't even fully C89 compliant.

Of course when one uses the famous trio (gcc, clang, msvc) the world gets simplified a lot.

So when your cloudbleeding, your atleast doing it as fast as possible, right?? ;)

Sure if u write game engines, do it in C/C++. Embedded devices? Probably a good choice.

I work at a startup, and we only have a few devs. I share my C# code-base across the client/server/mobile platform and even cross-compile it to a few other lauinages in between. If i need speed, i just extern out to a C/C++ dll i need and get it (never need to). Or integrate a microservice in eralang.

C# is just like C++, to write fast code, u need to understand the hardware. Its just C#, the hardware includes the garbage collector.

>Sure if u write game engines, do it in C/C++. Embedded devices? Probably a good choice.

Bingo. Those two things are exactly what I do professionally and as a hobby.

There is Rust now. Why stay with C++?

Comments like this appear on HN with frequency, and they betray a complete detachment from reality. Like what an outsider would think looking at the industry.

A very mature language, rapidly evolving, with an enormous volume of well proven libraries and tools, or a cutting edge, barely production level (with a breaking changes language), tiny library new toolset. And you question why someone doesn't just transition? Is that serious?

> barely production level (with a breaking changes language)

Oh no you didn't.

There's an argument to be made in Rust vs C++ but to my knowledge there hasn't been a breaking change in Rust since 1.0 and there's been a ton of work to keep it that way.

There technically have been some small changes, just like in C++.

The key is, as you said, you aren't even sure there were ones. That's how we like to keep it, and that's part of where all that work goes. The rest goes into making sure nothing breaks accidentally :)

Trivial example: shortly after 1.15 was released, a new API was found to have a soundness hole, so a breaking change was made to fix it in 1.15.1.

Because you like the ability to dynamically link to your dependencies so the entire world doesn't need to be rebuilt just to upgrade libxyz.

I love Rust, and I've been trying to get a hobby project written in it - but it really stinks that I can't just rely on my distribution to keep dependencies up-to-date like I can something written in C or C++.

Do like many of us in consulting, use both stacks. :)

How do you keep up with the stacks? It's hard enough keeping up with .net changes and that ecosystem is much smaller than java.

You don't need to know every single detail.

Usually we switch stacks when we switch customer, on average every six months or year.

Sure there is a kind of adaptation period, like the first week, then is back again to full speed.

I also use both on personal projects, so sometimes I use the stack that I currently don't on the project.

There are also mixed projects where the frontend is a native desktop application written in .NET, with the backend done in Java.

Basically, it is no different of mastering several human languages at writing, reading and speaking levels.

There's a few things Java still has over C# IMO. The biggest one for me is the warnings omitted by the compiler. C# can't seem to tell me about methods that are never called, unless I turn on code lens and look at them all manually.

I suspect most people using C# don't see this issue because they're using an IDE that tells them about methods which are never called.

So are most java people. The difference is in Java it's emitted by the compiler, so you can go through your warnings and nuke them all in one go. Even with Visual Studio though it's situational, you can't get a list of them all at once. only see it in isolation.

You can if you use ReSharper, which many C# developers use (maybe even the majority by now?).

I've never used it. I'd like to though.

Anonymous methods were basically the last thing that Java still had over C#, and now there's not even that.

Inner classes and objecty enums are still things. Also, anonymous inner classes that implement interfaces - C#'s a anonynous types are fun, but they can't inherit or implement.

This is probably not a popular opinion, but checked exceptions can actually be used for good as well as evil.

been jealous since LINQ and co landed in c# over a decade ago. Only if C# could run on jvm.

Scala does all this and so much more.

Sometimes the "so much more" is the issue with Scala, but yeah, Scala is a great way to make you say "man, I wish I had _" in every other language you use.

Kotlin too. There's even a super nice wrapper over spring-data-jpa [1] so you can do LINQ-to-Entities-esque query building where JPQL queries either aren't staticly-typed enough for you or you need dynamic query generation.

[1] https://github.com/consoleau/kotlin-jpa-specification-dsl

Every time I look at Scala, the version has changed and the entire world needs to be rebuilt.

Kind of a noob question. But why would you be happy if C# ran in jvm? Is it just cross-platform compatibility so that you can develop your C# application for Linux?

> Is it just cross-platform compatibility so that you can develop your C# application for Linux?

C# runs just fine on Linux, using .Net Core.

So any particular reason to want C# in jvm?