Comment by devjab | Hacker News Reader

Comment by devjab | Hacker News Reader

Parent Full thread

We do, in the few things we haven’t yet migrated away from C#. I’m curious as to why you wouldn’t, it’s much cheaper than deploying on windows since you’ll likely need a license for that.

We use it for a range of things. Mostly related to the legacy software of when our developers were mostly C# developers. Which isn’t how things are now, as C# has often stood in the way of our ability to deliver business value at a rapid pace while keeping maintainable systems. Not so much the languages fault as how Microsoft manages a lot of the libraries. Like how the model builder for EF and OData (both official Microsoft libraries) don’t work together and how you need to extend basically any standard library to do any real work with them. So while it’s actually a decent language, if a bit verbose, and .NET is sort of solid these days, we honestly have very few success stories with it.

Some of our AD (now Entra ID I guess) integration operates on it while we slowly migrate it to Powershell (which is .Net but runs in Azure Automation). Some of our APIs run with it. We have a few azure function apps (in containers and isolated) which are being migrated to other techs, and non-function apps. So it’s not like it’s not “working” for us, it’s just that it works a lot less great than its alternatives, even despite a it’s huge leap forward in recent years. Honestly it feels like Microsoft mostly keeps C# around because it sells licenses to medium sized stagnating companies, considering how “half-finished” a lot of the libraries are and how poorly so many of them function together.

I agree that many of MS’s “open source” libraries (eg EF, OData) are half-assed, badly run projects.

I’m also still mad at them for competing against amazing stuff like ServiceStack (a real OSS project from the community, and the best way to run REST APIs I’ve ever seen) with “official” but worse stuff like ASP.NET Web API. They do this a lot, some OSS gets popular but instead of embracing it, they make a half-assed ripoff, proudly proclaim it “official” on conferences and all the C# devs jump off the cliff like lemmings, and the original OSS project dies/stagnates. MS might have officially embraced Open Source but they’re absolutely awful at fostering an OSS community.

But .NET itself is amazing! There’s this weird misconception in Microsoft land that if you choose .NET you must also use all MS’s half-assed libraries. Just use Postgres! Use a lean ORM like Dapper, use Redis, use whatever you want from the wider OSS ecosystem. There’s nothing about C# that forces you onto Entity Framework. Get out of that red polo shirt and look around, there’s a lot of cool stuff out there.

to be fair though, using Entity Framework at least for migrations has worked really well in my experience (and doesnt prevent you from using any of those other OSS tools you mentioned!)

still have yet to learn / try dapper

Calling ServiceStack OSS is disingenuous since it comes with quite a heavy price tag for commercial use.

Not back in the day. IIRC it was mostly FOSS and the author gradually shifted to a more commercial model when MS waltzed all over it with ASP.NET Web API. I’m quite impressed he made it through actually, and I can’t fault someone for going full commercial when a giant moloch whose ecosystem you’re supporting pulls the rug under you like that.

To be fair ASP.NET Web API was just the natural progression of ASP.NET MVC which is based on Monorail more than anything else. You're making it sound like the community was set on ServiceStack and then MS reeled them back in, but the truth is not many people were using ServiceStack back then, they were using ASP.NET MVC which had things like JsonResult and whatnot that would get you a long way.

That said, ServiceStack has transitioned to payware a long, long time ago and I'm pretty sure that is what's caused its demise, not ASP.NET Web API. As a single anecdotal data point, it's definitely the reason I'm not using it.

Yeah and they don't get how that is damaging for the ecosystem, regardless of how many marketing posts get written, like the recent ones about the value of .NET.

I have had two projects where the customer paid to rewrite their .NET Framework applications into Java, instead of the more sensible idea to migrate to .NET Core, as they saw it was more valuable to them to move completely away from Microsoft stack.

I agree with everything you said, except for this part:

> There’s this weird misconception in Microsoft land that if you choose .NET you must also use all MS’s half-assed libraries.

The way I see it, it's more the opposite really. People chose .NET (or more specifically C#), because, they want to use it's tooling and if you're not going to use it, then why would you pick C#? .NET on it's own is excellent, I'm not sure if I think it's as good as the JVM, but it's definitely gotten very good in the recent years, but why would you pick it if you didn't plan on using the "official" tooling?

I'm sure there are some good answers to that question. We just haven't found any.

> why would you pick C#?

Because it’s a great language with amazing tooling. It’s fast, robust, easy to debug, easy to refactor, and so on.

It’s also very easy to learn for novices and experienced programmers alike because it’s kind of the middle ground between many popular programming paradigms, and it has few surprising gotchas. It’s a fast way to get a heterogeneous team productive.

> Because it’s a great language with amazing tooling. It’s fast, robust, easy to debug, easy to refactor, and so on.

I agree but I also think the main issue with this is that you could've said it in reference to most programming languages in 2023. I'm sure people can have a lot of debate on that, but aside from the fast bit, most programming languages are frankly in excellent places today, and fast is sort of irrelevant for us specifically as we tend to use c/c++ for that.

I see your point and I agree. At the same time, our current backend is Elixir because the BEAM is a fantastic match to our product. It’s been the right choice but I miss C# every day. Never having typos, point and click debugging, renaming stuff in a second instead of 15 minutes of careful grepping, etc. I recognize eg the JVM has all this too but plenty other popular languages do not.

I was helping some friends with F# homework, and being a Rust programmer, I had to ask: your project file is XML, and the order you list the project files matter, and it won’t tell you that you listed them wrong?

Compile errors are super long lines and don’t show an excerpt of the code with underline under what went wrong with suggestions on how to fix it?

I know I’m asking a lot here, but that level is available with Rust and Elm.

> and the order you list the project files matter

What do you mean by this?

The FSharp compiler reads the source code in a sequential linear way and throws an error if you reference something defined later. This also includes separate files, which is why the order matters. If file A is read earlier you cant reference in it anything from file B which will be read later.

You do have some tooling support for ordering files in VS and VSCode using Ionide. It is also not always the case that there is a right way to order the files and checking all permutations would get expensive fast. Basically, in F# that is part of the design process and helps you a lot later since you can just read the code in a linear way the same way the compiler does and not miss anything.

You do get the same information in the IDE from intellisense.

I’m not impressed by this design choice.

When order of declaration matters, it ceases to be declarative. “Let there be a function” is instead “make me a function”.

It’s entirely unnecessary, and even JavaScript can let you run a function that gets declared later.

The advantage when order does not matter inside the module is that you can list big things at the top of the file and the smaller things it’s made of below, rather than opposite.

The advantage when order does not matter outside the module system is that you can have mutually recursive modules.

You are touching upon some of the reasons why C# is unproductive for us. Because aside from when its "included batteries" decide to in-fight, there is also the parts where the "magic" breaks. This is more anecdotal, however, since it's going to depend a lot on who you and your team are. The guy I was discussing with made a point about C# being very easy to on-board new developers in, which is probably true for them. It has been the opposite experience for us. But I say this as someone who comes from a team where we have very good results on-boarding new developers into our Typescript environment, and I doubt you'll find many people saying that this is a common feat of the JavaScript language.

I didn't particularly mind the new way project files are made up in .NET. It used to be a lot worse too. But at the same time, it can be cumbersome as you point out here and for whatever reason, it's these small annoyances that so rarely get fixed by Microsoft allowing them to pile up. I mean, I just said it used to be worse, and it really did, but then when they made it better they didn't make it great. Which is something I'll just never understand, especially because they did it recently, so it's not like they couldn't have taken inspiration from other languages and done it right.

> it's not like they couldn't have taken inspiration from other languages and done it right

That’s literally it: they couldn’t.

It’s hard to duplicate good effort and make it profitable. So many people make either valuable or well-made things.

> It’s hard to duplicate good effort and make it profitable. So many people make either valuable or well-made things.

Explain? This isn't an assembly line, it's not a question of scaling handmade artisanship.

Parent is talking about two issues in F# which are not present in C#.

But yes .. when you step out of the well-defined area in .net you have an "Apple moment" where trying to do something they didn't anticipate or actively dislike becomes wildly, unreasonably difficult and you get pushed down a hacking rabbithole. I'm quite proficient at MSBuild now but I shouldn't have to be.

I believe they view the file order as a feature. It forces a certain style/thought process in how you design your project.

It's also part of the ocaml legacy (I believe file order matters in ocaml as well).

> I agree that many of MS’s “open source” libraries (eg EF, OData) are half-assed, badly run projects.

Just as a counterpoint to this, I have found Entity Framework (Core) to be an extremely nice and very productive dev experience, with a lot of constant improvements in every release. MS don't always get it right, but I definitely wouldn't call EF a "half-assed, badly run project" by a long stretch. (Though there are probably other MS projects I might be more inclined to describe as such!)

That said, they were pretty brutal in cutting off legacy support for those still using .NET Framework and trying to migrate. Through luck, I didn't have to suffer too much pain, but the migration story from .NET Framework to the new world of .NET (including EF to EF Core) has not been the smoothest for some scenarios.

OData is particularly atrocious, even the latest version (8.x). Entity Framework is getting better... EF8 may be the first version that achieves feature parity with (legacy) Entity Framework 6.x.

If you're still using .NET Framework at this point, that's your own fault (or, more likely, your org's). They have been communicating for _YEARS_ that .NET Framework was on its way out, and provided support for .NET Standard 2.0 as a stepping stone to .NET Core & beyond (i.e. .NET 5+). There are some apps & frameworks that don't really have a modern .NET equivalent, but you won't find me shedding any tears over the lack of a direct upgrade path for Windows Communication Foundation (WCF). =P

I think .NET-s unique strength comes from its batteries-included approach, very useful in enterprise environments where every piece of software needs to be audited.

That means Microsoft strives to provide a first-party library for every business case.

That said, you can still use ServiceStack and Newtonsoft.JSON if you wish to.

This is a great point actually. It's amazing how far you can get in a .NET project these days without a single third-party (Nuget) dependency.

Compared to my projects that (begrudgingly) use Node.js...

If you have done any Gov work, it is God given stack because audits are so much simpler.

What language and frameworks has your business shifted into? How has that better fit the goals of speed of development and maintainability?

We’re switching into Powershell for operations. With azure automation.

We’re switching to Go for concurrency. C and C++ for computation (though to be fair, we were already doing this with C# and the integration between them has always been great).

Our generalist language has become TypeScript however. Not because it’s great technically, but because it lets us share resources better which in term has made us much more productive in meeting our business needs.

I don’t think C# is bad, I also think it’s much better today than it used to be. If your use of it remains within what works well I think it’ll be hard to find a language with better tooling, but if your needs go beyond that you’re going to have to fight it a lot.

What does Go offer that C# does not? Both have actors, channels, threads, etc.

> What does Go offer that C# does not?

Nothing. This often happens when people don’t know .net to begin with. Better they go to go than complain about non existent issues in. .net.

Do C# channels offer lightweight concurrency ? The defining feature of Go is only matched by Erlang/Elixir and now Java. AFAIK C# has nothing like it.

C# approach to concurrency has always been better since its introduction. It does have Channels which offer more focused pattern for SPSC, MPMC, etc. scenarios but neither Java nor Go offer a comparable level of ease of use as C#’s hot-started tasks:

    // The tasks will run in parallel
    var data = service.GetData(id);
    var user = service.GetUser(name);

    Handle(await data, await user);

Re: the above comment on switching to Go for concurrency - probably one of the most ill-informed things I have read in the last few days. Doing this borders on incompetence due to the lack of analysis of the utilized technology - Go's GC offers far worse throughput and its concurrency story at best is "on par" with C#.

There is no async coloring in Go. In the example you cited above, service.GetData can be a plain synchronous function in Go. You don't need to distinguish between sync/async as this is defined by the caller and not by the callee. Any function can be made asynchronous without changing its signature. That's one of the critical advantages of having first-class concurrency. There is no "function coloring".

The simplicity of this approach and the advantages this brings to code structuring and easy refactoring simply cannot be understated.

Deferring to function coloring terms usually indicates a skill issue of not understanding that types are meant to represent what the code actually does.

Task-returning method indicates an asynchronously produced (deferred/delayed) result, a promise. If a language hides this fact (that the returned value needs to be awaited), it is grossly misdesigned - at most it can offer not blocking a thread, completely missing the point and leaving 20 years of improvements other programming languages have on the table.

But it's not as bad, yet instead in many other languages you are forced to manually schedule and then block/join until all of your tasks/promises/goroutines finish. Not in C#, that makes it as easy as it gets, which you can see in my example.

On top of that, you always pay for concurrency in Go, even when you don't use it, it is by definition always "colored" which further contributes to the overhead.

Also, in my example, the tasks will run in parallel. They won't in Go.

> Task-returning method indicates an asynchronously produced (deferred/delayed) result, a promise. If a language hides this fact (that the returned value needs to be awaited), it is grossly misdesigned ..

Very hard disagree. This depends on your computing philosophy. Go was designed based on the principles of CSP in mind and that code is produced by humans for humans first. The CSP architecture has proven to work and fit well for high-concurrent middleware. Not just for Go either.

You are not forced to block until goroutines finish as you claim. You can do other work or yield to the go scheduler. All the necessary busy work is taken care of by the runtime - which is terrific for folks who don't want to fiddle with low level details.

> On top of that, you always pay for concurrency in Go, even when you don't use it, it is by definition always "colored" which further contributes to the overhead.

And that is a completely fair compromise. Supporting easy concurrency natively in the runtime was an excellent design tradeoff since the computing world is moving to more and more cores. There are fewer and fewer uses for non-concurrent software.

> Also, in my example, the tasks will run in parallel. They won't in Go.

You appear to be confusing Go with NodeJS. If you have more than one core and GOMAXPROCS > 1, the tasks can indeed run in parallel.

> You appear to be confusing Go with NodeJS. If you have more than one core and GOMAXPROCS > 1, the tasks can indeed run in parallel.

What would the Go code look like that achieves identical behavior to the example above (tasks are dispatched concurrently and executed in parallel)?

Async coloring is a good thing (imo)

Your example is not concurrency though, it’s parallelism. You’re consuming two different services at the same time and waiting for the result. What you would want to showcase is how you handle two different consumers calling a single service. The difference is rather important once you have many consumers calling a lot of services and your computation needs to be done on the right state.

As a side note I really don’t think C# does parallelism better than Java.

It is both, please do not misconstrue this.

If two callers call the same method concurrently, whether it requires any synchronization or a more advanced primitive like Channel (for which C# has well-written implementation) or nothing at all is a case-by-case choice.

Java's parallelism by definition cannot be better because they had to retrofit a green threads design onto existing ecosystem, only ever addressing the hardware thread blocking issue with all the ceremony and bloat to do the most basic actions concurrently and/or in parallel still remaining in place.

Java requires far more steps to achieve comparable behavior for what C# requires you doing nothing or a method call at most. Dispatching array elements to a consumer in parallel? call .AsParallel(), and no, Java's Stream API requires more work. Want to fire off two asynchronously completing methods? Just use the example above, neither Java nor Go can hold a candle to this. Methods are CPU-bound and blocking? Easy - just use Task.Run to achieve the same.

> It is both, please do not misconstrue this.

I’m sorry, but it’s really not the same thing. You appear very confident, and sort of rude, in your argumentation, but there is just such a huge difference between parallelism and concurrency I don’t even know where to begin. I mean, you’re talking about (a)synchronous calls, tasks, and, what not, but what you need to solve is when two thousand sensors want to update the same data through the same service all at once. And they want to do this fairly often.

In reality it’s even more complex than this because a lot of the sensors carry data on behalf of each other so often you’ll receive the same data multiple times and so on, but there isn’t much need to get into that.

But hey, you do you, if C# works for you, great.

What are you using instead?

Reply on news.ycombinator.com