61–70 of 114 posts
Earlier quoted context omitted.
What do you think is lacking in C# extension for VS Code vs TypeScript? I would expect a better experience with C# (in terms of tooling) because the language is typed.
It just doesn't work nearly as well - even on simple .NET core solutions created from CLI intellisense chokes up, refactoring doesn't work, it's nowhere near the quality level of TS.
Earlier quoted context omitted.
Can you now get the full .NET development experience in a Linux-only environment? I haven't used it in a while, but from using Unity (game engine) it seemed like C# on Linux was a bit crippled
Yes, JetBrains rider is IMO superior to VisualStudio these days, and I run a huge amount of C# code in production on Linux. It was definitely crippled in the past but it's a first class citizen in the .NET ecosystem now.
When you see how much effort it takes to C# and Java to optimize the runtime, there are a lot of people working on that. C# is fast but you see that it uses between 2 and 32 times the memory that Go needs. Overall you can see how fast Go is, it has little optimization compare to C# and it's as fast. Compare this: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... and overly complicated C# version: https:…
and afaik, .net has record types unlike the jvm (yet) which means java is even worse
I can't imagine a better setup for a language flame war :). I really like debating languages, so I hope it doesn't go that direction. One of the standard caveats with this particular benchmark game with respect to Go is idiomatic optimizations are prohibited. To use the btree example, Go's memory management is low latency and non-moving, so allocations are expensive--any Go programmer writing a performance-sensitive…
The point of the btree example is to test how good programming languages are at allocating tree-like structures that can't be preplanned. It's a valid argument that this is a rare real-world requirement, but it's not contrived to be slower.
Forcing allocations for every node isn't justified by a desire to demonstrate dynamically sized binary trees. A naive dynamically-sized tree would just keep a list of node buffers and allocate a new node buffer every time the previous one fills up (perhaps with subsequent buffers doubling in size). The benchmark is, by all appearances, contrived to be slower.
I say modern .NET is a marvel of features, development tools, interoperability, performance and even ships with its own cloud environment (Azure). Unfortunately developers who don’t know better judge it by it’s historical association with Windows rather than how powerful it is today.
Most applications I develop these days are web services. I write most things today in Go, but I used to work quite a bit with C#/Asp.NET applications.
Here's what I do to build a Go web application:
- go build .
Here's what I used to do with .NET:
- Open VS, wait about 30 seconds for it to finally start working
- Set the target, Rebuild All
- Publish to file, wait
- Eventually get a packaging error, predicated on some obscure tools dependency issue somewhere inside my 98KB .csproj file, which I have to fix by closing down VS, manually editing in Notepad, and re-opening VS
- Finally get a working build+publish, ok, let's take a look
- Oh, very nice, the publish directory weighs in at nearly a QUARTER GIGABYTE, and contains about 60 dll dependencies and a ton of entirely useless descriptor files.
- Well, okay, let's at least get this deployed to the test server to make sure it still plays nice with IIS, xcopy this over.
- Oh, IIS doesn't like this at all, now let's spend the next couple hours tracking down this insane .net framework dependency hell.
- Screw it, where's my whiskey?I can't imagine a better setup for a language flame war :). I really like debating languages, so I hope it doesn't go that direction. One of the standard caveats with this particular benchmark game with respect to Go is idiomatic optimizations are prohibited. To use the btree example, Go's memory management is low latency and non-moving, so allocations are expensive--any Go programmer writing a performance-sensitive…
> absolutely idiomatic and trivial optimization Which is not accepted for the C# programs either. sync.Pool is accepted — https://benchmarksgame-team.pages.debian.net/benchmarksgame/... > the Go version is expressly contrived to be slower The requirements were contrived in April 2008. afaict Go initial release was March 2012.
Because C# doesn't benefit from this kind of optimization. Its GC is generational, which means that it has very fast allocations at the expense of high latency. In most applications, lower latency is more important than slower allocations (not least of all because these batch-allocating optimizations are nearly trivial), but these benchmarks don't reflect that at all.
> The requirements were contrived in April 2008. afaict Go initial release was March 2012.
Contrived = "the rules artificially prohibit idiomatic optimizations". It doesn't require that the maintainers have a prejudice against Go (although as you point out, the maintainers have had a decade to revisit their rules).
I say modern .NET is a marvel of features, development tools, interoperability, performance and even ships with its own cloud environment (Azure). Unfortunately developers who don’t know better judge it by it’s historical association with Windows rather than how powerful it is today.
Not really. And the allure of Go over .NET has very little to do with performance. Most applications I develop these days are web services. I write most things today in Go, but I used to work quite a bit with C#/Asp.NET applications. Here's what I do to build a Go web application: - go build . What I get out of it is a single, statically-linked, self-contained ELF binary for which deployment is as simple as scp, if I…
Seems pretty simple. Though the binary size is definitely not on par with go.
Earlier quoted context omitted.
Yes, JetBrains rider is IMO superior to VisualStudio these days, and I run a huge amount of C# code in production on Linux. It was definitely crippled in the past but it's a first class citizen in the .NET ecosystem now.
Rider is incredibly fast and superior to VS in all aspects but one - its debugger is terribly broken. VS will break on my line of code that crashes. Rider will crash somewhere completely unrelated. My code is very much async, that might be what kills it. I ended up doing everything in Rider, but debugging in VS.
I say modern .NET is a marvel of features, development tools, interoperability, performance and even ships with its own cloud environment (Azure). Unfortunately developers who don’t know better judge it by it’s historical association with Windows rather than how powerful it is today.
> Unfortunately developers who don’t know better judge it by it’s historical association with Windows rather than how powerful it is today. Some of us actually got to experience the entire journey from the old to new world first-hand. We started out as a .NET 3.5 Framework solution (windows only), and are now looking at a .NET 6 upgrade (any platform). Over the course of 7+ years, we went through all of the following…
At the time I was hired, it was to modernize an Access application used internally, to try to sell it as a product.
.Net was still in beta at the time (this was early in 2001). I figured I might as well go with the flow and try it out.
It was a crazy ride, and I've since left the company ... but we went through every version from beta through 4.8 before I left.
I'm now using .Net 5 in Azure to power my new company's REST APIs.
Earlier quoted context omitted.
> Unfortunately developers who don’t know better judge it by it’s historical association with Windows rather than how powerful it is today. Some of us actually got to experience the entire journey from the old to new world first-hand. We started out as a .NET 3.5 Framework solution (windows only), and are now looking at a .NET 6 upgrade (any platform). Over the course of 7+ years, we went through all of the following…
Well, without starting a flamewar (.NET is an impressive runtime), the JVM is better at backwards compatibility, I think.
In the space we work in, a vast majority of systems are written for either Java or .Net