Hacker Newsnew | past | comments | ask | show | jobs | submit | mrsmrtss's commentslogin

That's not how TDD works. You test the whole chain and all the components with tests and you can move from top to bottom with TDD, it's actually how you should do it.


There's a disconnect between TDD using all sorts of tests (unit, integration, hardware-in-the-loop, in-field, etc.) and TDD using unit tests only. Unit tests provide the least value/line of test code of all types of tests. They're important, since they can catch bugs earlier than other sorts of tests that can't be caught by a type system, but not sufficient to catch most bugs.


It is however how most software testing is done.


"Most" is a gross exaggeration.


> while if you wrote it exactly like Java, you'd probably end up with slower code.

That's not the case for some time already, at worst you get similar performance with Java and with a little effort you can get significantly better performance.


I don't get what the big problem is with function coloring. You basically only need async when doing IO, and you had better know when a function does it, or you may have a bad surprise at some point in the future.


That! Okay, in 2026 this could be a LSP feature with some editor fanciness but this is a real benefit. My nitpick is that we do not have a depreciation on the non async ones


Agreed, async function coloring makes for better structured code because it incentivizes keeping IO code near the edges while having a synchronous core.


Maybe startup time was a problem before AOT?


So you try to say that Java gets to be more semantically sound by making bad choices early on? That does not make sense. Those choices are very difficult fix today and many of them can't be fixed. Say what you want but semantically more sound Java won't be. And the boxing with C# unions can and will be addressed later, this was a deliberate choice by the team to bring unions earlier.


> and many of them can't be fixed... And the boxing with C# unions can and will be addressed later

No, they won't. C# already got itself into a corner with 32 bit arrays and 32 bit spans. And if unions are introduced as reference only that will never be fixed due to binary compatibility requirement.


The new C# unions are not reference-only. The attribute/interface allows implementing custom union types by writing `TryGetValue`-methods instead of a single `object? Value {get;}`. The compiler handles this transparently.


For almost 10 years now, we have not published anything .NET to the Windows platform. .NET is more performant on Linux today than Windows, and I would say development is also better there (using Rider). However, we do still have devs who prefer Windows. We have built many critical systems on .NET and they just work, so they may be boring to some of the folks who like to have more excitement from their systems.


As if C# is Windows only? Today C# runs also almost everywhere.


C# (.NET) would probably be the winner here. Go standard library is rather minimalistic compared to it.


Fun it is not.

    if err != nil
It's amazing how they managed to design a new language with all the flaws of '90s languages.


Even that is fun. A little tedious, but straighforward, no compiler magic.


Well, C# has more powerful pattern matching, only compiler exhaustiveness on types is missing today. In Java, sum types (sealed interfaces/classes) require all members to have the same parent, so they can be used only in very narrow cases.


As opposed to C# that doesn't have any form of sum types?


C# will have more advanced sum types this year, it's currently in preview.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: