neonsunset's comments

On: JavaScript's New Superpower: Explicit Resource Management

[neonsunset]

In C# nothing stops you from doing `var t = Task.Run(() => ExpensiveButSynchronous());` and then `await`ing it later. Not that uncommon for firing off known long operations to have some other threadpool thread deal with it.

Unless you literally mean awaiting non-awaitable type which...just doesn't make sense in any statically typed language?

[dang → neonsunset]

Please see https://news.ycombinator.com/item?id=44026655.

On: Java at 30: Interview with James Gosling

[neonsunset]

Don't bother: https://news.ycombinator.com/item?id=43396171

These people could not care less about engaging with the subject, they are here because they feel obliged to engage in a moment of hatred of what they think is an enemy tribe.

[mrcsharp → neonsunset]

Wow what a thread!

[LtWorf → neonsunset]

I mean… I provided justifications and links. The fact that you choose to disregard all of that is on you.

And the bit where you got angry because I didn't reply quick enough on an internet forum shows that perhaps you need to improve your manners.

On: Java at 30: Interview with James Gosling

[neonsunset]

We've had this conversation before, it's likely a waste to reply but, well, my mistake.

For those interested as to why: https://news.ycombinator.com/item?id=43396171

A few more arguments while we're at it:

https://dotnet.microsoft.com/en-us/platform/telemetry (Linux leads with 77% of all systems invoking .NET CLI commands)

https://github.com/dotnet/runtime/blob/main/src/libraries/Sy... (first-class epoll/kqueue integration with async, much like the one Go has with goroutines via netpoll)

https://github.com/dotnet/runtime/blob/main/src/coreclr/gc/u... (GC implementation is cgroups-aware, unlike Go)

On: JavaScript's New Superpower: Explicit Resource Management

[neonsunset]

using var stream = GetStream(); does not introduce new (lexical) scope, avoiding use means that the type system either has to understand move semantics (in case the stream is returned or move elsewhere, but then, what about sharing?) or have full-blown borrow checker which will emit drop.

On: JavaScript's New Superpower: Explicit Resource Management

[neonsunset]

> parts of the more modern C# is also a confusing mess

Do you have any examples?

[mrweasel → neonsunset]

For me, personally, heavy use of the => operator (which happens to coinside with my main complaint of a lot JavaScript code and anonymous functions). You can avoid it, but is pretty standard.

Very specifically I also looking into JWT authentication in ASP.NET Core and found the whole thing really tricky to wrap my head around. That's more of a library, but I think many of the usage examples ends up being a bunch of spaghetti code.

[neonsunset → mrweasel]

Wait, what? The => operator is just for lambdas, short-form returns and switch expression arms, which is as common as it gets!

Have you never worked with any other language which lets you do these?

    var say = (string s) => Console.WriteLine(s);

or

    struct Lease(DateTime expiration)
    {
        public bool HasExpired => expiration < DateTime.UtcNow;
    }

or

    var num = obj switch
    {
        "hello" => 42,
        1337 => 41,
        Lease { HasExpired: false } => 100,
        _ => 0
    };

You'll see forms of it in practically every (good) modern language. How on Earth is it confusing?

Authentication is generally a difficult subject, it is a weaker(-ish) aspect of (otherwise top of the line) ASP.NET Core. But it has exactly zero to do with C#.

On: New high-quality hash measures 71GB/s on M4

[neonsunset]

Same here. And I’m not aware of quality issues with GxHash either. For large(r) inputs I’d expect it to be easily competitive. And it’s better than XXH3 on my M4.

On: New high-quality hash measures 71GB/s on M4

[neonsunset]

If whatever you are doing is heavy on hashmap lookups (and you are ok with not rewriting into something more bespoke+complicated) - the faster hash function and the cheaper baseline cost of calling it - the better (i.e. XXH3 can have disadvantages, with its popular impl. for dispatching to the necessary routine).

This looks like an interesting potential alternative to GxHash. GxHash is nice but sadly I found AES intrinsics to have somewhat high latency on AMD's Zen 2/3 cores, making it a loss on short strings (but until I measured it on our server hw, M4 Max sure had me fooled, it has way better latency despite retiring more AES operations!).

[xkcd1963 → neonsunset]

Question, what do you do if there is a collision? I saw the github table also mentioned collisions

[lights0123 → xkcd1963]

They're extremely common in hashtables. You follow standard open addressing or separate chaining procedures: https://en.m.wikipedia.org/wiki/Hash_collision

[LoganDark → lights0123]

Non-mobile link: https://en.wikipedia.org/wiki/Hash_collision

[Xorakios → LoganDark]

Do people still use mobile devices? I thought that was like original star trek?

[LoganDark → Xorakios]

I don't know, all I know is that in my experience some HN commenters don't remove the `.m` from their Wikipedia links. Probably because that's inconvenient to do on mobile devices.

[meindnoch → xkcd1963]

Open any data structures textbook and look for "hash map" in the table of contents.

[saagarjha → xkcd1963]

Fall back on secondary hashes or do probing

On: Java at 30: Interview with James Gosling

[neonsunset]

Quite a few languages "loved" by "Linux communities" tend to have rather rudimentary integration with Linux kernel's facilities or worse packaging story.

For example, Go does not understand cgroups limits and needs an external package to solve this. .NET can read and accommodate those natively. It also ships with excellent epoll-based socket engine implementation. It's on par with Go (although I'm not sure which one is better, but .NET performs really well on high-throughput workloads).

On: Java at 30: Interview with James Gosling

[neonsunset]

Most of the features that require Apache or community packages in Java ship out of box in .NET (or via extension packages).

They also tend to be of higher quality and provide better performance.

On: Java at 30: Interview with James Gosling

[neonsunset]

IIRC all previous conversations about checked exceptions here ended up with the swift conclusion that they are heavily discouraged throughout Java code.

[breadwinner → neonsunset]

> they are heavily discouraged throughout Java code

That's so ignorant. Read the article please.

[neonsunset → breadwinner]

Let's revisit past conversations:

- https://news.ycombinator.com/item?id=43226624

- https://news.ycombinator.com/item?id=43584056

- https://news.ycombinator.com/item?id=36736326

And more. I'm not sure what you found in (checked) exceptions. If you'd like explicit error handling, we have holy grail in the form of Rust which beautifully solves it with implicit returns, error type conversions and disambiguation between error and panic model. I'd prefer to use that one as it actually reduces boilerplate and improves correctness, the opposite to the outcome of using checked exceptions.

[bigstrat2003 → neonsunset]

> I'd prefer to use that one as it actually reduces boilerplate and improves correctness, the opposite to the outcome of using checked exceptions.

Reducing boilerplate is not a valuable goal in and of itself. The question is, does the boilerplate buy you something? I think that with checked exceptions it does. Having an explicit type signature for what errors a function can raise improves correctness a great deal because the compiler can enforce the contracts of those functions.

I agree that the Rust approach is good too, though I don't agree it has any strong advantages over the way Java does things. Both approaches are equally respectable in my view.

[breadwinner → neonsunset]

> I'm not sure what you found in (checked) exceptions.

I could copy/paste the entire article here... but it would be easier if you could take a gander: https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...

Summary:

Crashy code: You have no compiler-enforced way to know what exceptions might be thrown from a method or library.

More crashy code: If a method starts throwing a new exception, you might not realize you need to update your error handling.

Dead code: If a method stops throwing an exception, old catch blocks may linger, becoming dead code.

[Kwpolska → breadwinner]

None of those arguments are convincing. In many cases, you can't handle errors more reasonably than just crashing or telling the user something went wrong. Java has RuntimeExceptions, which do not have to be declared in the function signature. Division by zero, or trying to index an array out of bounds, and the dreaded NullPointerException, are some examples of RuntimeExceptions.

[breadwinner → Kwpolska]

What about the ones you can recover from? You don't want to crash the entire application every time there's an exception!

[Kwpolska → breadwinner]

You usually wouldn’t crash the entire application, the request that causes the issue will return a 500 error. (Or equivalents for non-web environments.)

[breadwinner → Kwpolska]

Some exceptions are not recoverable and may cause 500 error. Others such as FileNotFound are recoverable, for example by reading the file from an alternate location.

[mrkeen → breadwinner]

> You have no compiler-enforced way to know what exceptions might be thrown from a method or library.

Always assume exceptions will be thrown from a method or library.

[breadwinner → mrkeen]

Which ones? That's the issue.