News for hackers. Stuff that matters.
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by danudey on Monday June 24, 2024 @05:13PM (#40780864)
I hate writing code in golang, because I have to pepper every single function call with `if err != nil`, but then I think about how much C code I've seen that doesn't do that and I wonder how much of it should.
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by hot_gril on Monday June 24, 2024 @08:00PM (#40782617)
Golang's error handling is safer than C's, but it's more cumbersome than it needs to be. Rust chose a good in-between (the "?" unwrapping syntax).

In high-level code, nearly every func you write can return an error, and 99% of the time you're just going to pass the error up. Webserver will catch all and send 4xx or 5xx, for example. Exceptions are a lot more convenient and encourage solid error handling. In mid-level code, maybe you want something a little more explicit like Rust's way.

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by pjmlp on Tuesday June 25, 2024 @03:25AM (#40785499)
Every now and then I think about forking Go and adding something like ?, and Pascal/Modula-2 like enumerations.

However then I realise, why bother, and go back into using C#, Java, D instead.

Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by hot_gril on Tuesday June 25, 2024 @02:35PM (#40791910)
The only thing I seriously plan to use Golang for is implementing a scripting language in my spare time. Its threading model (greenthreads flexibly mapped to OS threads) is attractive for that.
Re:More Memory Safety for Let's Encrypt: Deploying ntpd-rs by SAI_Peregrinus on Monday June 24, 2024 @07:03PM (#40782073)
Lots!

Also lots of C code that doesn't properly check `errno` for things like `strtol` to check for errors that aren't returned directly from a function.