I'm a huge C# advocate but we actually went the other way. Regardless of the tooling etc. we still have to use Golang for mission critical stuff. This is mainly due to the cold start times you mentioned - mainly the "first request" problem C# has with web related requests.

I've been keeping up with the latest developments, and it seems that they're finally starting to address the problem with tiered compilation stuff, which is fantastic. However, for now, waiting for 5+ seconds for a simple controller method to fully complete on a first post - with no way of auto-warming up (without using major hacks) on startup is just not acceptable.

Again, I really love .net, and contribute a fair bit to Signalr (core) myself, but feel this would really need to be addressed in an easy-to-integrate manner before it can be an absolute top tier language. They're addressing the other elephant in the room and providing a single-execuatable runtime-agnostic deployment option soon as well...which is amazing!

Overall though, for a language, you can't beat C#/core in my opinion and would 100% recommend it.

You can usually cut the cold start performance in half by enabling Tiered Compilation. It's just one parameter in your project file, or via an environment variable.

Disclaimer: I work on performance in the ASP.NET team.

I should say (since i've got your attention) that i'm almost 100% sure that all of your customers would be more than willing to sacrifice a startup time for a well-coordinated callback when everything is warmed up, as a toggleable option of course.

To explain this a bit better, i'd definitely be happy even waiting 10+ minutes for all of my controllers/hub methods to be instant response. I could then subscribe to an event when it is ready and let haproxy/nginx or whatever else know that the server is "good to go". This way, the server goes into the pool, and everyone is happy. I remember seeing that the Bing guys did something like this, but again it was majorly hacky.

Thanks for all the great work you're doing on C#/.NET Core in general by the way.

Tiered Compilation is tweaked in a way that it provides a very good balance between startup time and throughput, which is what a majority of users would need. If you want to privilege throughput and don't care about startup time, then you should try COMPlus_ReadyToRun=0 as an environment variable. This will force to use non-crossgened code so the JIT can better optimize your code.

How about using native compilation?

Said that in the post above :) however it doesnt seem to impact HTTP requests or requests to a signalr hub for the first time after boot.

We've had tiered compilation enabled since it came out as an option, but the first requests are still dog slow

What are you disclaiming?

Oh, please - https://dictionary.cambridge.org/us/dictionary/english/discl...

None of those definitions mean "disclosure," which is certainly what was meant.

Yea, this project is mostly batch processing of things, so cold starts don’t matter. There is one api endpoint that we left in go for quick responses. I thought about doing a C# to js transpile, but have not had time to look into it. That being said, our cold starts are < 2 seconds with dotnet core 2.1, which isn’t great, but isn’t too bad.

I actually find the "f5-to-do-the-magic" experience in Visual Studio Code to be preferable (TypeScipt project with Mocha tests) to the Visual Studio experience :-)

Devdiv (org that builds .NET, C#, VC++, VS etc) has always been one of the top notch organizations within Microsoft with great engineers (although from what I hear, some of them have left recently). Nonetheless, as someone who now works at a company with an open source tech stack, I sorely miss the tooling I had when I worked at Microsoft.

C++ belongs to WinDev, hence the whole politics WinDev vs DevTools, the torpedoing of Longhorn and WinRT.

As someone eager to start (properly) learning C#, is doing so on Mac actually viable? It sounds like it from your post but would be eager to hear your thoughts (I only have a Mac at home to practice on).

I've been doing C# on a Mac w/ Rider and it's been a delight. There's a few rough edges (using Windows/DOS style paths in the csproj breaks my muscle memory) but it's great.

Yes. VS Code is probably the easy button to get started. With a few plugins, it's ready to write, build, and debug C# projects.

I haven't built any production code in VS Code or .Net Core yet, but have started analysis for converting legacy .Net applications. I've also had interns doing some prototype work in .Net Core using VS Code, both on Macs and PCs. So far, so good.

I also used VS Code to do some React development. That worked out well also.

At this point, I'm hoping to get the legacy solutions converted in the next year or two, ditch my MSDN subscription, and move to VS Code full-time. Right now, I'm on a Mac, and running VS in VMWare.

Mac + VSCode is my daily driver.

Totally. .NET Core SDK, VS Code and the C# VS Code plugin are enough.

Yes, Unity3d developers have been developing in C# on Mac for over a decade. Visual Studio for Mac (aka Xamarin Studio aka MonoDevelop) is better than Xcode in some respects.

I'm using a 2015 Macbook Air + vscode. Builds are fast, easy to debug code, even spinning up a local webserver to test my .NET MVC web app goes fast enough.

.NET Core on Mac with Rider has been great here.

I'm complete new to C# and Java but I'm looking into them to choose a new language to learn. I'm mostly worried about memory consumption since I often use a cheap $5 VPS. Would you happen to know which one would be a better fit for my use case? Thank you.

If your end game is working professionally just check what is more in demand in your geographic location.

Personal opinion

C# is a lot better than Java. You have less boilerplate code (getter and setter in 2018, really?) and lambdas are great.

But really both are similar so you can pretty much just start with one and still find your way in the other.

Java is the most popular language of the JVM ecosystem, but not the only one. If I were to restart from scratch, I would seriously look into Kotlin, which is how Java should have been.

Honestly, people still using the getter and setter argument in 2018 as a reason to pick a language should not be taken seriously.

Indeed Java has more boilerplate, but honestly I've never been bothered by it (as you can generate most within your IDE) and because its explicitly written down it can make code more readable.

And Java also has lambda's.

> because its explicitly written down it can make code more readable.

more text to read does not means "more readable", it means more effort to do

unless that text validates hidden assumptions, or conveys important information to the user.

not always the case, but you can't argue that "less text is more readable" any more than you can argue "more text is more readable". what you want is, "just the right amount of text" which will depend on your tastes.

Java is much heavier to read because of all the boilerplate. And it may have lambda but for example the stream implementation sucks compared to the elegance of LINQ. They had 8 years to make it right and I’m still amazed how did they manage to implement it so badly...

Yeah... the bigger reason to move away from Java isn't Getters and Setters...

The bigger reason is one word: Oracle

Whether you go towards C# or other companies... Oracle is a horrible company.

Oracle is only one player in the Java ecosystem. OpenJDK owns just about everything now, and most organizations are going to get support somewhere besides Oracle. There's been some good recent innovation with Java, and I think it'll continue due to the new accelerated release schedule.

That reminds me, I want to experiment some with AOT compilation and also the new GC plugins.

lambda's are much more limited in flexibility when compared with linq. Because of the way java lambda's work, I imagine there are some scenarios where they are more performant, but it probably comes down to the specific problem/usage.

If you want to be on the JVM I highly recommend giving Kotlin a look before Java. Great language and excellent tooling.

I would go so far as to argue that Kotlin is the JVM's real equivalent to C#. The syntax is different, but language semantics are much more similar.

I would like to learn Kotlin, but I've no prior knowledge about Java... That's a real impediment?

If it isn't, do you know (by chance) about some resource(s) for a total newbie/newcomer to the language?

thanks in advance.

I'd say a rudimentary knowledge of the Java ecosystem is required, Maven or Gradle are the preferred deps management and build tools. It's a bit of a bummer as quite a bit of 3rd party docs assume you have already written things in Java, and gloss over things like, importing a library. For someone who doesn't have a magic importer (or worse yet, someone who is not using an IDE), you'll literally have to dig around in API docs just to figure out what comes from where (I'm looking RIGHT AT YOU Vertx!!)

Overall, the language feels pretty nice though.

I don't think lack of other JVM knowledge will be a big impediment, but it might be a small annoyance bootstrapping a project (e.g. how to do dep mgmt) and debugging (how to read a stack trace).

jetbrains is doing a very good job of creating good error messages, but just like any other jvm language, you can run into huge, messy, jvm stacktraces. In my experience, Java/jvm proficiency is useful

We're using .NET Core 2.1 in prod on Linux Docker containers. One of our production services that gets 2-3 requests per second on average (not a ton of traffic, but a legit prod workload) uses between 78 and 90 MB of RAM.

If you're worried about memory usage, then neither is great (C# is a little better than Java), you may want to look into Go or Rust.

In this list we also have D and Swift. Good on yr mem, general purpose-y (Go is not a GP lang), quite popular.

> quite popular

Disagree, especially on the same level as the others with D, and especially concerning cross-platform ecosystem with Swift.

I'm curious: what was the problem with Go?

The domain experts all write C#, and I don’t have strong language preferences, so it’s easier for me to switch to C# than it is for them to switch to Go. There isn’t a real technology reason, it’s just team ergonomics.

And that is very smart decision making. Professional!

I'd be curious too, but one place might be cross-platform easy runtime shared library use. Go with non-Windows "plugins", or poor c-shared support w/ crappy Cgo that doesn't even work with MSVC, is very bad in this area. Of course I watch all the GitHub issues addressing these with hope, but it's clear this story in Go is terrible.