Memory usage of a toy C# server and client with 500K concurrent connections on
github.com
github.com
async/await - C# is the ONLY language which gets this right. Javascript has it now but you need to be use libraries which support it too, which are hard to find. Kotlin has coroutines but Java base library doesn't have support for coroutines so you can't use it all the way through and create a chain of all async functions. Once you use async/await it's hard to go back, since the code is as easy to write as synchronous code.
Then you have proper support for generics(unlike Java which has type erasure), LINQ queries and an amazing IDE which is visual studio.
Hopefully it will see a renaissance when people realise that with ASP.Net Core they can write code that looks broadly similar to Rails/Laravel/Django code, and get much better performance more or less for free. There are definitely some rough edges around the ecosystem though. Entity Framework isn't nearly nice as Laravel's Eloquent ORM, and it's pretty jarring looking at a promising library, only to realise that it's a commercial offering (don't get that with PHP!).
I've used F# in a few professional projects before and that language is certainly underrated. I used to work in Microsoft's DevDiv and everyone knew it was criminally underfunded. I think if it had OCaml-style modules and Microsoft threw more weight behind it could take off big time.
In addition, there was the question what not to implement. A notable omission from the design was the functorial module system of OCaml. Functors were a key part of Standard ML and a modified form of the feature was included with OCaml, a source of ongoing controversy amongst theoreticians. The author was positively disposed towards functors as a “gold standard” in what parameterization could be in a programming language but was wary of their theoretical complexities. Furthermore, at the time there were relatively few places where functors were used by practicing OCaml programmers. One part of the OCaml module system – nested module definitions – was eventually included in the design of F#. However, functors were perceived to be awkward to implement in a direct way on .NET and it was hard to justify their inclusion in a language design alongside .NET object programming.
The Early History of F# https://fsharp.org/history/hopl-draft-1.pdf
Yes, you do end up writing some code that a great ORM would just give you for free, but honestly I haven’t felt pain from doing this as it makes me actually think about and set in stone what relationships and models I intend to support in my data layer.
ORM's like Eloquent (PHP) are super nice, because they let you lean on them completely for simply queries, and then give you layers of opt-outs. For example, inserting a row is just obj->save(). For slightly tricky selects you can use the whereRaw method to interpolate raw SQL into just a where clause of the query, or you can use DB::query() to write a full raw SQL query if you have some queries that are particularly complex.
I guess I could give Dapper a go though. SQL is... fine.
But from what I can see, EF is trying to provide an abstraction layer that pretends that I am just working with collections of objects, which I don't like at all because it makes it harder to control which queries actually get executed and when!
On the other hand, Eloquent provides an abstraction for generating queries, but this maps pretty closely to SQL, and it otherwise largely stays out of the way...
The type safety is nice, and of course you don't get that in PHP. But IMO that's more about the language than the library.
Eloquent also has object collections. Both frameworks have similar methods for filtering and querying. Eloquent is much more clunky (because PHP) and the underlying conceptual model is different (ActiveRecord style vs. DataMapper style). I certainly would use Eloquent for PHP projects but I definitely wish PHP could do something like EF.
There are a lot of add-ons for it that simplifies all the generics for you.
There are ways to mitigate this [1]. You write your queries in .sql files in Visual Studio, so you get intellisense and syntax highlighting, and you can even add these to your automated test suite to ensure they run correctly.
I think the link is pretty clear: it combines and batches queries while providing a type-safe interface for the returned results. It further provides intellisense and unit testing features that are tedious and error-prone to achieve in other ways.
Of course you can do this all by hand, or manually batch your queries to avoid round trips, but why would you want to?
The flexibility and performance of full SQL, without having to write all the mapping boilerplate by hand.
The eco system still seems wonky, but NuGet probably isnt more weird than that of Golang.
NuGet, I'm still not sure of either, but at least it mostly works transparently. Though I haven't actually tried publishing anything to it, only consumed. npm seems to have the least resistance imho, for good and bad results alike.
Have you tried Python's asyncio?
This applies just as much to Python asyncio so I'm not sure it's a good suggestion from that perspective. You can use an executor to wrap things that don't support asyncio but that doesn't really qualify as good asyncio/await imo.
Typescript (and normal Javascript) both support async/await very well as long as you use Babel to compile your code.
Infact, you don't even need to use Babel to compile your code because a large portion of browsers natively support async/await: https://caniuse.com/#search=async
I'm not sure why people say you need libraries that support async/await. In JS/TS, async/await are built into the language itself and most libraries utilize the Promise API, which means they also support async/await (since async/await is built on top of promises).
Example taken from here: https://mariusschulz.com/blog/typescript-2-1-async-await-for...
It's easy enough to wrap a non async library with promises so I can use it with async and await.
I've sometimes done the same thing with non-async libraries in C# by wrapping them with Tasks.
I usually only do this when I'm pretty sure I'll have to farm out the functionality to a separate service in the very near future. I just start with an async facade around the library, and then swap in an async wrapper around the web service when the time comes. Then I can just drop it in without needing to make any changes aside from changing the interface binding in the DI container initialization.
I suppose this might violate YAGNI. But I really don't do it often at all. I only doing it when I'm following the principle of PSIGNIS (Pretty sure I'm going to need it soon). Maybe it's better to just use the library synchronously and then refactor when it's time to move the functionality to a separate service. I don't think the amount of dev time spent is hugely different either way.
It seems like a good language with very good tooling if object oriented programming (in the Java and C# sense) is your posion of choice. Now with .Net Core and other good iniatives from Microsoft it might be a more relevant language than ever.
I've not seen any thread on HN bashing MS without reason. However, the only guys who claim to use C# either work with big companies or freelance.
Some context has shifted, the Microsoft takes over Github part has shown sentiment shift also ( not everyone of course)
Beyond that, MS does deserve the skepticism it gets, and I'm not a fan of the "M$" references or similar. Leadership at MS has changed and it does show. I do wish they'd stop doing sleazy things with windows though. I've been using more Linux and Mac as a result.
Migrating large projects to dot net core piece by piece is fraught with tooling bugs and issues (you pretty much need to migrate everything to SDK-style projects before you do anything else, for example, otherwise you get strange interactions between net461 and netstandard projects around auto-generated binding redirects). There's still DLL hell. Default "copy local" results in crazy n log n file copies in large solutions that totally kills build performance (you can tweak this to use hard links in an effort to improve things, but not within Visual Studio which is where I really want cycle times to be low, or do mad hacks with shared output folders, but that can give you nondeterministic builds).
So it's far from all roses - check out their bug trackers on github and there are a number of surprising issues. There are also a lot of missing things on Linux still (e.g. Out-of-the-box support for kerberos auth in ASP.NET core/WebAPI things on Linux). Quite a number of APIs pretend they are there in netstandard but throw at runtime on Linux machines, and yet other things are annoyingly half-hearted, like mapping some Linux syscall return codes to Windows HResults, but not all of them and not consistently across all APIs.
It's getting there, but the surrounding ecosystem has a lot of catching up to do compared to Java, IMO.
The language is nice, though. F# also.
NuGet does have some rough edges, and compile time for even my small .NET Core projects tends to be on the order of seconds, which is surprising for a mature compiler and stripped-down framework.
For that matter, anything using node/npm on anything but SSD/NVME is VERY slow (HDD, even enterprise drives)... local builds for me are in a couple seconds for a large complex project, on the servers it's minutes. So, YMMV.
The API layer I'm working against is .Net core, local build is under 3 seconds, building/deploying 12 seconds on my desktop (kills existing container, builds in one container, deploys to another and starts) docker for Mac, probably faster on linux... NVME drive on i7-4790K, 32GB RAM.
[1] https://gist.github.com/tracker1/8cd6309ecc3e480616f79e83712...
Anything outside of that is average, if anything.
I understand that's changing of course, now that Microsoft has open-sourced the core of the language and started pushing to get support onto Linux and other platforms, but they are still making up an almost 2-decade deficit here.
But yeah, Visual Studio beats the pants off Netbeans and Eclipse, while functional, is very clearly what happens when you let an engineer design a UI, everything is possible and nothing is easy.
IMO the investment in VS Code basically signals VS has become too bloated and complex to innovate on so they're better off creating a new IDE from scratch with better plugin extensibility and ecosystem that's innovating and delivering features significantly faster than VS which comparatively looks like it's stalled.
So when you look at VS from the perspective of someone who's used to typical Unix or JS tooling, it's comprehensive. If you look it from the perspective of an old time Java developer, it's lagging behind.
As I recall, at the time, it seems that the Java ecosystem was mostly investing into writing code and declarative markup (usually XML), while Microsoft was most interested in visual designers and other ways to help devs on its platform avoid writing code. Thus, VS was far easier to get started with, but advanced coding was much better in Java IDEs.
I don't think the tooling caught up to the ease of not using the built in tooling until VS 2005 for me. Of course by VS2012, it felt like such a bloated slow mess, I don't think I've looked back much until relatively recently. Been doing a lot of Node work, which I tend to think of as very low friction.
These days, I absolutely love VS Code which tends to strike the balance of more than an editor, but not slow and bloated like a typical IDE. Integrated file tree + terminal are the best UX to me.
Maybe C# is really only fantastic on Windows with Visual Studio?
RIDER from JetBrains is fantastic IDE on all platforms.
VSCode is a good editor, when you want to write smaller (single file) C#/F# programs.
LinqPad is only for Windows but is nice companion editor to riff off small methods/functions or probing LINQ etc.
/p:CreateHardLinksForCopyFilesToOutputDirectoryIfPossible=true /p:CreateHardLinksForCopyAdditionalFilesIfPossible=true /p:CreateHardLinksForCopyLocalIfPossible=true /p:CreateHardLinksForPublishFilesIfPossible=true
It will give you a considerable speed-up for very large solutions, especially if there are lots of common project dependencies, as it will make hard links instead of copying entire files. This could save you gigabytes of file copying in very large solutions. Google for "hard link" if you don't get what I mean by that.
Note that dotnet core works differently and doesn't do copy local at every stage up the dependency tree when you build, instead copying dependencies directly into your top level application project only when you run the publish target, which is obviously cheaper than either approach.
Using hard links gives you most of the speed up, but without the attendant issues.
i.e. its been fully open source for 4 years https://mattwarren.org/2018/12/04/Open-Source-.Net-4-years-l... and is under the .NET Foundation rather than Microsoft https://dotnetfoundation.org/
I'd say it's only really in this last year that it's really started escaping its legacy and started really making sense as a non-microsoft stack.
inb4 "but EEE was only the 90s!"
According to the comments on the issue tracker, it was supposed to be OK because it was anonymized – but oops, there was a bug, so it wasn't totally anonymized. But it's OK because you can disable it if you happen to know about it – but oops, the disabling mechanism had a bug.
Things that are important to many free software users are not important to Microsoft. I was excited about .NET Core until I became aware of this stark misalignment of goals and priorities.
It is very uncommon in stand-alone software development of all sorts (shrink-wrapped, service development, commercial web apps, etc) for very obvious reasons. That doesn't make it underrated, there just happens to be a lot of other great platforms.
Since I have mostly been around enterprises, I can say it is pretty much appreciated.
This are however the kind of customers that will happily have WebSphere, SAP, cluster management with AD, SQL Server OLAP and so on.
There won't be any projects being published on github and getting software into the projects always requires some kind of change request.
Not the kind of shop many HNers like to talk about.
Regarding Java, as someone that works on both platforms, I still look forward that Valhalla comes to fruition.
Which is why I am usually against the "I rewrote X in Y", unless it holds a good business value story going for it.
Part of it is not necessarily the design F# took but that the TPL is incompatible enough that the mixing of TPL-centric .Net libraries becomes a problem. It might be wise for F# to support the TPL via computation expressions with something like `task { ... }` (there are a few implementations out there but a compiler supported state machine generator would be more ideal).
I'm not clear if you absolutely have to use TPL but CML is likely just a better model for tackling concurrency and Hopac is orders of magnitude more efficient than F#'s async.
Wait until you try goroutines :)
Here's a 40min talk explaining how Go's scheduler works:
Could even use the return `await Task.WhenAny` to tell you the specific one to check. Shouldn't be a very hard construct to make; to make it more select like.
It has the benefit that any number of tasks can be selected, but the efficiency is not good as hard-coded select blocks.
But it looks C# Task.WhenAny has much less use case variants than Go select block.
The holy grail is cooperative multitasking and always-on, opt-out async [0] if you ask me.
Such as?
The language is really good - it's one of my favourites. It's almost 2 decades old, but it's evolved naturally and is still a modern language.
Unfortunately, it's the shit around it that let it down... MSBuild, NuGet, VS - they're full featured, but very slow and clunky and hard to work with. Only popular because there's been no viable alternative.
Now, with dotnet core, there's no more reliance on Windows (for both dev and production). I can develop and deploy on my preferred OS, and there's a choice of IDE (Rider and VS Code).
> Paket is a dependency manager for .NET and mono projects, which is designed to work well with NuGet packages and also enables referencing files directly from Git repositories or any HTTP resource. It enables precise and predictable control over what packages the projects within your application reference.
The big change is solution-level dependency management instead of the nuget-default project-level management, so you always have the same versions of dependencies across all projects in a solution. It also uses a lockfile for these versions so that restores are idempotent. It also allows for fetching independent files from HTTP-accessible locations or git repos, which is nice in F# because the language is succinct and enables you to reuse modules without going through the rigamarole of making and publishing nuget packages.
And .NET is still very much Microsoft’s baby. Unlike an independent language like C or JS or Rust, MS could pull the rug out at any time.
Yes, Mono. But Mono is an unofficial port of a moving target. They have no control over the direction of .NET.
With open membership https://dotnetfoundation.org/blog/2018/12/04/announcing-net-... and election of its board https://dotnetfoundation.org/blog/2019/01/23/why-you-should-...
Maybe MS will in future cede all control over the language. Maybe in future 99% of code contributions won’t come from Microsoft employees.
But even then it would take years for the language to become more widely adopted outside Windows.
What you mean? C# is open source. And, here is the location - https://github.com/dotnet/csharplang
So in practice, 'pulling the rug out from under' Mono (or .NET Core) users would be pulling the rug out from under paying customers.
Unrelated, anyone know how I can get my Windows 10 Mobile phone to sync Zune songs to my Windows Media Center? My Xbox360 stopped working smoothly after the last few forced updates
Haven’t touched java since version 7 i think. But was pretty convinced they both have comparable type inference capabilities when it comes to parametric polymorphism.
The big difference between C# and java is the reification of the parameter values, inferred or not.
And the reification method choosen for C# gives you some extra metaprogramming capabilities, especially when combined with reflection.
My argument was that this can be provided design time instead (inference too) while retaining the extra safety of having theorems for free
Indeed, phantom types are wildly underappreciated. Long ago, I created an library [1] that ensures the type safety of any runtime generated programs you create using it. It does this by typing the various stacks that are in play at any given time, but every new generic type on the CLR ends up creating new type descriptors in global data structures (which aren't GC'd), so complex programs with deep stacks end up generating a lot of static, uncollectable data that just hangs around forever.
[1] http://higherlogics.blogspot.com/2008/11/embedded-stack-lang...
Something I'm curious about, how does C# handle parallelizing async code? Is it hard? Easy? How do you do it?
http://computer-programming-forum.com/29-pascal/c1ccf8167920...
The async/await implementation will never fall back to thread pool by itself. Tasks are "futures", and in that sense a thread/task pool may be used in async/await when you need to run tasks in parallel. But when a thread pool is used is always under the control of the programmer.
Task is a more basic concept than threads. Tasks are about asynchronous execution, thread about parallel execution. Parallel execution is inherently asynchronous, but asynchronous execution is not parallel.
Indeed, that it the whole idea behind async/await: Enable the asynchronous model without the overhead of multiple threads.
It does use a threadpool scheduler by default for a console app. Yes, I could override that if I wanted to.
In general it works pretty well until you need more than the defaults offer, then it becomes almost an exercise in frustration.
For UI threads (WPF, WinForms) it is essential that the code continues on the original thread. This the synch context used in WPF/WinForms will post the continuation on the original thread once it becomes available (thrugh the big message loop).
For ASP.NET threads, requests are processed from a thread pool. The ASP.NET synch context IIRC will schedule continuation on any ASP.NET managed thread.
So yes, you may see your code (esp. in console apps) executing on another thread after an async call, but that does not mean that .NET schedules your tasks on a thread pool. There is still only a single thread of execution at any one time, until you explicitly use a thread pool (e.g. Task.Run)
for (var i = 0; i < 1000000; i++) {
var unused_task_var = RunTaskAsync();
}
await RunMainMonitoringTaskAsync();
tl;dr If you call an async method and don't await on it, it will be parallelized - for a console app, at least.
Honestly, I don't find the MS docs on this to be that great. Not 100% sure I'm even doing it the right way here. Everybody says use Task.Run but that is for CPU bound tasks. I want to run a ton of IO waiting tasks.
edit: looks like I'm doing it right. See "Async Composition" @ https://blog.stephencleary.com/2012/02/async-and-await.html
I don't remember Turbo Pascal ever having similar to coroutines and I used all versions up to Turbo Pascal for Windows.
Async/await makes concurrency bubble up. This is a great article that explains this issue: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
It's also why I tried Golang. Once you use goroutines it's hard to go back, since the code is synchronous code.
(I use JavaScript with async/await in my day job)
The nice thing about async/await is that it's just a wrapper around futures, which are themselves a composable wrapper around callbacks (semantically; the implementation can be more efficient, of course). So any language that can express function callbacks as first-class values can represent a future, and any language that can represent a future can interop with the async/await world. Which is why you can have JS code doing await on C# code doing await on C++ code in a Win10 UWP application, and it all works. And you can take existing libraries and frameworks that use explicit callbacks (often written in C), and wrap that into futures such that it's all usable with await.
This is a spot-on. The only language I know that did this all right is Haskell, where most of your code doesn't need any thinking of async operations (either runtime gets you covered, or function takes a callback as a parameter, instead of any await magic), and when you need them -- you have `async` library that gets all you need.
Laziness is not Async.
You explicitly provide instructions which expressions get turned into async expressions in Haskell.
- either Haskell gives you API which is done "right", without any Async types. For example, `bracket` function
- or runtime gives you lightweight threads by default, so you can just `fork myComputation` and it'll run in a lightweight thread which "just works"
- or finally, in rare situations of interleaving different computations with complex dependencies, you just use the `async` library, which is not a special language construct but a library, which lets you "await" and all that
I'd say the more important concern with c# is to be careful you're not accidentally calling a "really blocking" function from an async method, or you will lose scalability. The lesser issue is the mundane task of changing all your function signatures in the chain to async.
I too would use Go if it didn't regress in every single area for me, other than concurrency, and make me sad.
Other than that, I do agree, I really like C# a lot and am glad the effort that's been put into making sure Core works cross platform. I still shutter every time I have to work in VS (not Code) though.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Can someone more knowledgeable give me some perspective on how representative these benchmarks are? At this point would it be wrong to say that in general the C# and .net environment is more performant than Java? If so, will there be any changes to Java to bridge any gap?
C# has a number of features (like `Span<T>` and value types) which Java doesn't currently have, which enable programs to run more efficiently, which might explain the difference. IIRC there are plans to add value types to Java, but they're not ready yet.
For allocation-heavy workloads that can't use .NET's lower-level memory tools, I think the JVM is still a bit ahead with its better GC and profiling HotSpot JIT compiler.
How much more memory did you use?
> i didn't bother running it
https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...
`nqzero` says "the test harness is difficult to configure and use" — but does not show any example of what is supposed to be difficult about using the bencher script.
`nqzero` says "the tests are not representative of common programming tasks" — but does not show any example common programming tasks and does not show the tests are not representative.
`nqzero` says "there's no attempt to account for JIT warmup, and many of the tasks are too short to ever warm up" — but admits that "it is plausible" warmup costs are amortised and comparison will show miniscule difference.
`nqzero` says "maintainers are opinionated in terms of what code they'll allow, effectively choosing the winners" — but (again) does not show any example.
`nqzero` says "doesn't appear to allow for jvm options to be included" — but seems not to have looked.
`nqzero` says "the test cpu is from 2007 and is not necessarily representative of current cpus" — That at-least is true!
https://github.com/dotnet/corefx/tree/master/src/Common/src/...
On the other hand, C# has features like structs, non-virtual methods (by default at that), and reified generics, that make for faster code without any JIT magic.
And, depending on the exact code being tested, one or the other factor can easily dominate.
In terms of .NET performance, we've made significant improvements [1] with each release. If there was a gap between C# and other languages before, it is likely that it is much smaller now due to our efforts.
We have a balanced view on performance. We are investing in application throughput, latency, memory usage and disk footprint. Most .NET users care about multiple of those things. We also hear from users who care disproportionately about just one of them. This motivates us to care about all of these things, although throughput and memory usage is where the biggest gains are.
I have this (not very good) joke that many .NET developers until recently would not have been able to accurately describe what structs were (as opposed to classes). To a large degree this was because we used them in very narrow ways in the products. That has changed a lot in the last few years. ValueTuple, ValueTask and Span are all good examples. The culture of the .NET has changed and so is the .NET community around us. This will result in higher performance code more generally within typical .NET applications (as opposed to some theoretical outcome). If this happens, and I do believe it will, .NET will be forever changed in a pretty radical (or at least "rad") way.
[1] https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performan...
Java won't go away any time soon but C#/.NET seems to be under better and more determined leadership.
Do any examples come to mind? I thought Microsoft did a pretty thorough job of adding async support to nearly all of the BCL in .NET 4.5. Not saying there aren't gaps, I'm just curious. Sockets' non-blocking model is an excellent candidate for async/await-ifying.
The biggest thing is memory management. I never had trouble with GC in dotnet, Java locks up with full GCs WTF.
Looking at this another way: you need >20x more memory to achieve the same level of performance as native code in C#. Suddenly the benchmark doesn't look that great anymore.
I threw this benchmark together in a couple of hours pretty easily. The most annoying part was just measuring the RAM :-)
But yes, everything is a tradeoff. If you want safety, you pay more - either in RAM, or in cognitive load.
It's more like, you need 10x more memory with 100x more productivity than C/C++.
If you don't care about productivity, however, you can actually write C# as you'd write C, and with a very similar perf profile. You can put everything into structs to avoid heap allocations, for example. You could use stackalloc, which basically gives you fixed-size non-bounds-checked stack-allocated arrays, exactly as in C. You can have pointers that GC knows nothing about, and you can even do arithmetic on them like in C. You can even have type punning unions. And then you can put an API on top of all that which makes it usable with async/await - and write the rest of your code in high-level C#.
The new official C# compiler - Roslyn - was released in 2014. It's open source and cross-platform. It was followed up same year by .NET Core, which is the new primary distribution of .NET with support for Windows, Linux, macOS and a handful of [other] BSD derivatives.
Sources:
https://github.com/dotnet/roslyn https://github.com/dotnet/coreclr https://github.com/dotnet/corefx
Binaries:
C# compiles to Common Intermediate Language (CIL) which is then assembled into a form of bytecode.
So Microsoft got the luxury of being able to go back to the drawing board and try to "do Java right". At least with the knowledge gained from developing Java in the 90s.
Arguably it came full circle in Java 8, which was a big update to the language.
But I dislike some of the stuff being done in .NET Core, for example the compatibility flags instead of using semver. And integratig GDPR? IN CORE?
VS just feels like a big fat 32-bit legacy application with no support for long filenames. Its very hard to do improvements for them, that's for sure. Just look at NuGets package manager UI. Surely there are so many improvements one could make. (Compare that with the Kaizen feeling you get with each VS Code update)
I feel MS marketing has too much to say and pushes unnecessary stuff into the UI. Bring in clippy already!
The tooling for Razor is so extremely buggy, automatic indentation is broken, try copying pasting imports, changing model type requires reopening of window, dependent on folder-local web.config to give correct analysis (but still may compile at runtime)
Also, Im afraid of the frequent updates should something break. (Best to wait them out a few weeks.)
Then you have the seemingly impossible task of uninstalling it. Better just reinstall windows itself.
That being said, I guess I feel like they're doing their best on many points. The code base must really be huge and they are no doubt pouring in lots of resources improving vs. I was even called once from the US by a womam asking me for ideas on how they could improve the break-on-exceptions experience while debugging! I mean who would do that.
And some areas are totally wonderful and unheard of in other platforms, for example sourceview with full integration with github. I dont think many know how far ahead .net is on so many levels!
I was puzzled by this comment. From what I can tell, the GDPR stuff is an optional templating feature in the ASP.NET Core, not a feature of .NET Core.
https://docs.microsoft.com/en-us/aspnet/core/security/gdpr?v...
Vs 2017 is currently broken when you reload a project because it shows multiple tabs for the same file: https://developercommunity.visualstudio.com/content/problem/...
They already said that it was fixed in version .3 while it was not true. I still didn’t bother to check in version .4.
Several times I had my VS crashing for out of memory. Is it possible in 2019 to have a 32 bit IDE????
On the resharper side performances have been abysmal with the latest release and debugging unit tests has become a blood bath for a really nice bug that makes the unit tests unable to run in the test runner because the dll of your project is somehow lost sometimes. This bug was still not fixed last time that I checked.
Maybe you have been lucky or you never worked with very big projects, but VS is quite a shit show.
ReSharper is a pile but you can’t blame VS for that as it’s a 3rd party add-on.
Never even had a machine with 30gb of RAM but also never had VS eat it all.
Test runner difficulties almost always boil down to one of a few things: test explorer targeting the wrong process architecture, configuration inconsistencies betweeen projects/solution, and the rare occurrence I’ve seen involved some project level settings that had become corrupted. Obviously if you can’t build a dll then test explorer won’t find your tests.
Really I’m not even close to alone in arguing VS is the best IDE on the market—I never said it was perfect. Still, I prefer it over both XCode and IntelliJ IDEA (and really any of the other JetBrains IDEs, ever had to sit and wait for your IDE to finish “Indexing files” so you can try to build?! Ugh), both of which I have used full-time. Visual Studio’s only real rival to me is another editor made by Microsoft: VS Code.
VS Code + the dotnet CLI has been a pretty good experience for me so far. Maybe try that?
Wat? That never even happened.
> (Compare that with the Kaizen feeling you get with each VS Code update
> Also, Im afraid of the frequent updates should something break
Sorry, do you want frequent updates, or infrequent updates?
> Then you have the seemingly impossible task of uninstalling it
That used to be a problem, prior to VS 2017 - since then you can even have a side-by-side install of the preview version, and it works great.
> The tooling for Razor is so extremely buggy,
Eh? I've been working with Razor in VS since it first existed, and I just haven't experienced this.
BTW, I'm not saying VS is not without bugs (some of which have existed for years), but IMO it's still the best IDE that's available anywhere (and yes, I've tried Rider).