Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET 5.0

devblogs.microsoft.com

Post reply on HN
Print view View original

451–460 of 466 posts

Re: .NET 5.0

#451

Post by jolux »

mattmanser wrote: post #446
jolux wrote: post #344

Earlier quoted context omitted.

Indeed it would be but making unit tests easier to read, write, and maintain should force you to make the application easier to write and maintain. I agree that readability can suffer somewhat if you’re not careful though.

This is simply a dogma, if you want to follow that dogma, fine, but there's no reason to be forcing everyone else to.

I'm not going to force anyone else to, I am expressing an opinion. I would be pushing this position if I were on a team with you because it's not just a dogma, it reflects the best knowledge I have about how to build software well. You are free to build software as you see fit and have always been.

Re: .NET 5.0

#452

Post by seanmcdirmid »

WorldMaker wrote: post #441
seanmcdirmid wrote: post #356

Earlier quoted context omitted.

It isn’t really more advanced as it is different. What typescript achieves with structural typing it loses in terms of good error messages and the encapsulation benefits of nominal typing. I’ve gotten used to typescript, but I still enjoy using C#. Some things I really miss in C# (limited operator overloading) that will never come to typescript (not because of the type system, but because of javascript source compati…

Some things like conditional types and string template literal types start to get way out into abstract type land that is certainly more advanced than C#'s type system. Typescript is inching closer and closer to the Haskell-ish land of turing complete type systems where the type system itself is nearly it's own meta-programming language with each version. (A recent example was the "SQL engine" written using string te…

Typescript lacks the goal of soundness, which makes it much easier to introduce powerful features than in Haskell.

Re: .NET 5.0

#453

Post by MaKey »

FridgeSeal wrote: post #444
dustinmoris wrote: post #384

Earlier quoted context omitted.

My advice, stay the f*ck away from Azure as far as you can. It’s the biggest clusterfuck I have ever had to deal with. Unless you are a Microsoft Gold Partner and you simply buy every shit which your Microsoft Account Manager tells you then you have no reason to use Azure. Unlike the Google Cloud or AWS, Azure has not a single service which is unique or good in any particular way. On the other side, they have many se…

Oh my god Azure functions. What a pain they were, nevermind getting them running locally. AWS Lambda: run the code, because it’s easy to write code to be fully independent of lambda specifics. Azure functions: oh no you need to run this thing to simulate stuff. Oh you’re not on Windows? Uhhhh too bad, that doesn’t work. You’ll have to use this other, random beta software. Oh it failed to run now, because you didn’t p…

I had no trouble developing Azure Functions with VS Code on my ThinkPad running Ubuntu.

Getting them to run locally [0] or in your Kubernetes Cluster [1] isn't too difficult. With AWS Lambdas that isn't possible at all.

Regarding the storage for Kubernetes, as long as you don't provide details it looks like just another rant. I get that you like AWS more than Azure but your opinion may not reflect the actual experience someone else will have.

[0] https://docs.microsoft.com/en-us/azure/azure-functions/funct... [1] https://docs.microsoft.com/en-us/azure/azure-functions/funct...

Re: .NET 5.0

#454

Post by masterofmisc »

MaKey wrote: post #416
masterofmisc wrote: post #376

Earlier quoted context omitted.

Gee.. Sounds like you have had an awful time of it. Any chance you could speak more of some of the issues you encountered? We are looking at cloud providers and was kinda leaning towards Azure.

What kind of workloads are you looking to run in the cloud? Chances are you won't have major issues despite the rants on here making Azure sound like a dumpster fire.

Honestly our stuff is pretty pedestrian. We have a front end website and API service, a couple of application servers for our telemetry IoT outstations and of course a backend database server.

Re: .NET 5.0

#455

Post by aidenn0 »

jolux wrote: post #344
aidenn0 wrote: post #231

Earlier quoted context omitted.

Making software harder to read, write, and maintain in the name of making unit tests easier to read, write, and maintain is putting the cart in front of the horse.

Indeed it would be but making unit tests easier to read, write, and maintain should force you to make the application easier to write and maintain. I agree that readability can suffer somewhat if you’re not careful though.

Writing quality tests is often much harder than writing quality software, and I find quality unit tests to be significantly harder than e2e or integration tests, so if I can only write software for which I can also write quality unit tests, I am greatly reducing the space of quality software I can write.

Yes, one solution is to make the software more complicated in order to make the tests less complicated, but the other solution is to just use fewer unit tests. Note that I'm not advocating not testing (my motto with software is "If nobody tested it, then you can be certain it doesn't work."), but One good e2e test can often replace dozens of unit tests.

I find that E2E -> Integration -> Unit form a scale from "easy to write, hard to run" on the e2e side and "easy to run, hard to write" on the unit side.

There are exceptions; testing that you can sort N objects in M microseconds is a trivial test to write, and potentially a challenging requirement to implement, and a unit test might be completely appropriate there. However, for the general case, I find unit tests to be too often trying to make a square-peg fit a round-hole, and then saying "okay we'll shave the corners off a bit so that it's easier to fit in this hole" rather than saying "maybe we should use a square hole"

Re: .NET 5.0

#456

Post by jolux »

aidenn0 wrote: post #455
jolux wrote: post #344

Earlier quoted context omitted.

Indeed it would be but making unit tests easier to read, write, and maintain should force you to make the application easier to write and maintain. I agree that readability can suffer somewhat if you’re not careful though.

Writing quality tests is often much harder than writing quality software, and I find quality unit tests to be significantly harder than e2e or integration tests, so if I can only write software for which I can also write quality unit tests, I am greatly reducing the space of quality software I can write. Yes, one solution is to make the software more complicated in order to make the tests less complicated, but the ot…

> Writing quality tests is often much harder than writing quality software

I personally believe that tests are how you prove you understand the code you’re writing, and the changes you’re making. If they’re harder to write than the software, you probably need to further clarify the behavior being tested, but they’re going to be hard sometimes, just as some software is hard.

> if I can only write software for which I can also write quality unit tests, I am greatly reducing the space of quality software I can write.

I follow TDD, so indeed I only ever write code that I know how to write unit tests for. I haven’t found that TDD restricts the kind of software that I can write, but sometimes it does mean I’m slower to get started in a particular domain. I do find that once over the initial hump my unit tests are a constant companion that make me more comfortable and productive in developing new software.

Realistically we both agree that testing software is important, we just disagree in the details. The problems I see with end to end testing are that good patterns for building extensible and loosely coupled end to end testing suites are not as widespread in the industry as they are for unit and even integration tests.

My theory as to why is that we assume that end to end tests are going to be slow to run and “heavy” in some sense, and that as such we aren’t running them often enough to force the improvements we need in those suites.

I always find it weird when discussions about unit tests become discussions about other kinds of testing, though. I think high (though not necessarily 100%, as that’s arbitrary) and increasing unit test coverage are an empirical sign of code that is being properly maintained. They are not the last word in testing and software QA, they’re closer to being an indicator like using CI and a proper build system instead of a thousand line shell script, and having quality well-maintained documentation. As I said in another comment, I am not going to say that unit tests are the only way to write good software. They’re a powerful tool that I have found helps me and my teams a lot. That’s as far as I will go.

Re: .NET 5.0

#457

Post by nexus2045 »

mattmanser wrote: post #23

So, on the plus side with the new .net, I recently made a .net core web app on Linux, and generally it's been pretty easy. I'm also impressed at just how fast asp.net core is compared to asp.net, the time it takes to open your site in debug mode has dropped dramatically, from what used to be 1/2 minute in asp.net to a few seconds in .net core. On the bad side? Mainly the asp.net core team and their push for Dependenc…

This is a pretty interesting comment section to read. I went from Node.js to .NET Core development for about a year, and got the impression that Microsoft had already figured out all the best practices, and shoving it down my throat was for my own good, so I didn’t question whether or not DI was good, as if it was dogmatic. My team thinks the same. I thought DI was pretty much the final conclusion to how software should be architected due to the collective trial-and-error of decades of OOP programmers.

In usual HN fashion, even the most seemingly obviously true points to me are being argued and refuted.

Re: .NET 5.0

#458

Post by branko_d »

recursive wrote: post #297
_acco wrote: post #258

The future is very bright for .NET. It has the right raison d'etre - .NET is part of the growth story for Nadella-Microsoft. They already have you programming in their editors (VS/Code) and pushing to their VCS (Github). They're even teaching you the C# type system with TypeScript :) If they can just convince you to use their stack, Azure will win you over from AWS every time. As a result, I really wanted to adopt .N…

The type system in typescript is a lot more advanced than the one available in C#.

Part of it is that TypeScript doesn't need to worry about memory layout - everything is basically a hashtable.

Re: .NET 5.0

#459

Post by mycall »

Netcob wrote: post #392
kumarvvr wrote: post #345

Earlier quoted context omitted.

Also, I find DI to be very useful. I dont know about small projects, but in any reasonable size projects, having a DI container is a god send. Easy to setup and use.

Yeah, I'm pretty shocked how much hate it seems to get. Maybe it just makes things easier for simpletons like me? The one issue I can see with DI in ASP.NET Core is that it doesn't really do DI correctly. The point of DI is that ultimately, you have complete control over how you build your dependency graph and you shouldn't be forced to use a container at all if you don't want to. With a DI abstraction the developers…

That is 4 years old, is it still relevant?

Re: .NET 5.0

#460

Post by MaKey »

masterofmisc wrote: post #454
MaKey wrote: post #416

Earlier quoted context omitted.

What kind of workloads are you looking to run in the cloud? Chances are you won't have major issues despite the rants on here making Azure sound like a dumpster fire.

Honestly our stuff is pretty pedestrian. We have a front end website and API service, a couple of application servers for our telemetry IoT outstations and of course a backend database server.

I think you'll be fine with Azure then. You should use the pricing calculator beforehand to not be surprised by the costs and figure out how to reduce them but this applies to any cloud provider.
Post reply on HN