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#.
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.
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.
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++.
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.
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.
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.
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.
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?
