Live data from Hacker News

Minimal APIs at a glance in .NET 6

hanselman.com

111–114 of 114 posts

Re: Minimal APIs at a glance in .NET 6

#111
post #52

Earlier quoted context omitted.

In the OOP way you create controller classes. In the FP way you pass lambdas/functions. So yes, it’s not 100% functional. But probably 80%?

You're creating an instance of an app class, calling methods on it, and passing objects in that method (string and lambda are objects). I just feel like the term OOP can't win here. If it's concise people will just claim it's FP.

Off course there is still OOP involved. Also most FP languages support objects to some extent. Also records and their modules have some similarities to OOP. And even FP can be never completely pure, there always has to be state.

But this approach is just more functional than the one before.

Re: Minimal APIs at a glance in .NET 6

#112
post #66

Earlier quoted context omitted.

and wasteful. Starting up selenium et al is painfully slow compared to tests that run in <seconds.

While I do agree, then you don't have to run Selenium tests on your PC, but let it be done by e.g ci/cd Also depends how many pages do you want to test with Selenium - if you want to test e.g 5 pages, then it'll be fast enough I guess. There are a few tricks/configurations that make Selenium significantly faster - https://stackoverflow.com/a/57720610 A lot of is also on how do you write your "testing infrastructure"…

Relying on CI server to run tests is even slower :) Note I am not stating "don't use CI" as that is still an invaluable tool.

The waste I am referring to is time it takes to get that feedback whilst the work is being actively developed.

A simple feature of a controller (to borrow someone else's example) is to change the response based on an attribute's configuration. It is wholly astonishing that one needs a _web-server_ to test that.

Re: Minimal APIs at a glance in .NET 6

#113
post #108

Earlier quoted context omitted.

If it has a mock service behind it, how is that an integration test?

You test the integration of your code with the web framework. An integration test doesn't have to be end-to-end. It tests the integration between multiple components. In this case it would be your code with the integration of asp.net core. A controller usually doesn't contain any business logic, it does the HTTP part. So you test serialization, model binding, return codes, etc. So you use a mock to check, if the fram…

Interesting. I would still consider that a unit test (I don’t insist that a unit test must directly call the method it’s testing - it could be it needs to put it in some sort of test harness to get it executed)

Much how if a piece of code uses a regex, I wouldn’t mock the regex library when unit testing it, nor consider a test that uses the real regex library as an integration test that tests my code’s integration with the regex library, I wouldn’t consider my controller code’s interactions with a web framework as ‘integrations’ to test. They are part of how the unit is implemented.

But this is just a naming debate - I’m in agreement that that is a useful kind of test to write.

I just reserve ‘integration test’ for contexts where I am testing that multiple individually tested components of my own work together as they’re supposed to when combined - not that they integrate together correctly with something else I didn’t build.

There’s a danger if you go down that path of ‘testing the framework’.

Re: Minimal APIs at a glance in .NET 6

#114
post #15

Earlier quoted context omitted.

1. The web server component could be fronting a middle-tier written in C#. There are numerous advantages to doing this in .Net over Node. 2. Performance. 3. Native AOT is coming in 6.0. Meaning, you get a native platform specific app which can run without the framework - like golang. But with GC, so not like C/C++/Rust.

I don't get it why people always hated (tracing) GC. Unless you are working on a hard real time systems such as DSP or audio synthesizer, having some kind of GC is always the boon. Not only you can run code faster in some case (by suspending GC in some critical code and just do plain allocate and resume GC at a later time, and this is also how you make it more real-time compatible), it can also help curb fundamental…

There is definitely a terminology problem. "Automatic memory management" is a more precise term than "garbage collection". It refers to the more user visible trait, and pairs better with the antonym of "manual memory management" which is much more commonly seen. I would encourage people to use "AMM" as a term even if in their coding they do not use it. :-) "AMM" also begs the right questions such as "automatic -- in what sense, exactly?" It also tracks with the primordial C "auto" for stack variables (the automatically managed part of C - yes I am aware modern C++ repurposed it). It might even make some discussions have less talking past each other. This kind of oceanliner ship is hard to turn, though.

There are a few high profile prog.langs and environments like Java/Go/old Lisp stop-the-world/etc. style where (some) people struggle with "GC". These struggles often give AMM itself a bad reputation - while C stack variables (often coupled with what people call "value types" today) are often the way to be very, very fast (yes, because of mostly CPU-private stacks..even so).

Nim is very fast and has many choices in AMM from none to Boehm-Wiser to its own tracing variant to a new extremely low overhead ARC and ORC that have more Rust-ike aspects (but copying in some cases to be safe which is just about 10x easier to use in deviousmeters). With a TinyC/tcc backend Nim yields near Interpreter/REPL-like edit/compile/test cycles. It's really a joy to write code in most of the time. People should look into Nim more.

Post reply on HN