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

Programming language comparison by reimplementing the same transit data app

github.com

Post reply on HN
Print view View original

61–65 of 65 posts

Re: Programming language comparison by reimplementing the same transit data app

#61

Post by jolux »

Someone wrote: post #59
int_19h wrote: post #39

Earlier quoted context omitted.

Regarding C#: > The "billion dollar mistake" is important to me, and while C# has non-nullability sugar in its typesystem (i.e. with ? after a number of types), the type system wasn't as rigorous as I was maybe hoping. I'm genuinely curious if you have any examples? Nullability checks may be bolted on, but once you enable them, they should consistently prevent you from dealing with any null values that you haven't ex…

> I'm genuinely curious if you have any examples? Nullability checks may be bolted on, but once you enable them, they should consistently prevent you from dealing with any null values that you haven't explicitly allowed. I’m not the one you asked, but there’s a difference between you no longer having to deal with null checks and your program no longer having to deal with null checks. The CLR will still do the null ch…

> I also don’t think C# will prevent you from forgetting to do a if null check in cases where you expect values to sometimes be null.

It should throw a warning in situations where a non-nullable value is not clearly non-null when it’s dereferenced. So you won’t get a warning in the body of a method declaration with a non-billable parameter, for example, but you will get a warning if you attempt to pass null into it.

Re: Programming language comparison by reimplementing the same transit data app

#62

Post by super_flanker »

andreygrehov wrote: post #15

According to the results, Go and Rust pretty much beat every other language. While Rust is the clear winner, it has a steep learning curve. When it comes to Rust vs Go, I always choose Go, because it still beats all the other languages and at the same time an extremely simple language to learn / read / write. This triplet has a greater weight in my books.

Would never choose Go unless I'm paid for me. Rust is so much better to work with, pattern match and algebraic data type just makes the programming so much fun.

Re: Programming language comparison by reimplementing the same transit data app

#63

Post by int_19h »

Someone wrote: post #59
int_19h wrote: post #39

Earlier quoted context omitted.

Regarding C#: > The "billion dollar mistake" is important to me, and while C# has non-nullability sugar in its typesystem (i.e. with ? after a number of types), the type system wasn't as rigorous as I was maybe hoping. I'm genuinely curious if you have any examples? Nullability checks may be bolted on, but once you enable them, they should consistently prevent you from dealing with any null values that you haven't ex…

> I'm genuinely curious if you have any examples? Nullability checks may be bolted on, but once you enable them, they should consistently prevent you from dealing with any null values that you haven't explicitly allowed. I’m not the one you asked, but there’s a difference between you no longer having to deal with null checks and your program no longer having to deal with null checks. The CLR will still do the null ch…

You're describing C# as it was before nullability tracking. For several years now, it does have a mode in which every reference that can be null must be explicitly checked to be non-null first before you can use it, very similar to Kotlin.

https://learn.microsoft.com/en-us/dotnet/csharp/nullable-ref...

So yes, "will require you to properly handle them" is exactly what I meant.

Re: Programming language comparison by reimplementing the same transit data app

#64

Post by Someone »

int_19h wrote: post #63
Someone wrote: post #59

Earlier quoted context omitted.

> I'm genuinely curious if you have any examples? Nullability checks may be bolted on, but once you enable them, they should consistently prevent you from dealing with any null values that you haven't explicitly allowed. I’m not the one you asked, but there’s a difference between you no longer having to deal with null checks and your program no longer having to deal with null checks. The CLR will still do the null ch…

You're describing C# as it was before nullability tracking. For several years now, it does have a mode in which every reference that can be null must be explicitly checked to be non-null first before you can use it, very similar to Kotlin. https://learn.microsoft.com/en-us/dotnet/csharp/nullable-ref... So yes, "will require you to properly handle them" is exactly what I meant.

FTA, emphasis added: “Nullable reference types refers to a group of features enabled in a nullable aware context that _minimize_ the likelihood that your code causes the runtime to throw System.NullReferenceException.”

That approximates it, and likely gives you most of the benefits, but it isn’t the same as strict enforcement of necessary null checks.

There will be cases where the programmer can prove a value isn’t null, but the compiler can’t, and thus, the programmer can choose to ignore the warning.

That’s similar to how Java tries to prove that a variable is initialized when being read. (https://docs.oracle.com/javase/specs/jls/se9/html/jls-16.htm...).

Java makes the safe choice, though. It refuses to compile such programs, thus guaranteeing that every local variable and blank final field will be initialized before first use.

Re: Programming language comparison by reimplementing the same transit data app

#65

Post by int_19h »

Someone wrote: post #64
int_19h wrote: post #63

Earlier quoted context omitted.

You're describing C# as it was before nullability tracking. For several years now, it does have a mode in which every reference that can be null must be explicitly checked to be non-null first before you can use it, very similar to Kotlin. https://learn.microsoft.com/en-us/dotnet/csharp/nullable-ref... So yes, "will require you to properly handle them" is exactly what I meant.

FTA, emphasis added: “Nullable reference types refers to a group of features enabled in a nullable aware context that _minimize_ the likelihood that your code causes the runtime to throw System.NullReferenceException.” That approximates it, and likely gives you most of the benefits, but it isn’t the same as strict enforcement of necessary null checks. There will be cases where the programmer can prove a value isn’t n…

That's exactly why I asked for specific examples of when nullable enforcement does not catch a potential null reference at compile time. I can't think of any such case so long as all the code has it enabled (if not, it's like safe Rust calling into unsafe).

And if you ignore the warnings, that's a deliberate opt-out; why even bother with nullability checks then?

Post reply on HN