Disqus - Latest Comments for thomashabets

Re: No way to parse integers in C

Thomas Habets — Wed, 15 Oct 2025 20:19:17 -0000

I meant what I said, in that I read it as POSIX not using undefined behavior (UB) the way the C standard does. Because that would make no sense. UB on a valid text buffer input, that happens to contain a value that can't be represented? That would make atoi() and friends just about as impossible to use correctly as gets(), which would be crazy. They even removed gets() from C11 for this reason.

… and now I checked C17, which has the exact same wording.

WTF? You are technically correct. I cannot imagine any implementation actually taking advantage of this UB, but you're right. Another reason atoi() and friends is useless.

Re: Dropping privileges

Thomas Habets — Fri, 19 Sep 2025 03:29:31 -0000

Yeah your edit should work. You don't need the parent to die, though, it can just wait for the child. This would be necessary for anything interactive to work.

Re: Go is still not good

Thomas Habets — Thu, 18 Sep 2025 02:56:21 -0000

Wow, you're just doubling down on explaining my own blog post to me, now with almost twice as much explanation.

This is really weird if you. I wrote the post. I don't know how you think I'm able to write a blog post without understanding it.

It's also ironic that you're doing this while using a very non-standard capitalisation of the name of the language.

I'm not asking what Go is doing. I'm saying that what Go is doing stupid and bad.

This is as if I'd written a blog post about how in perl "$foo" is not the same variable as "@foo", and if I print "@foo" that's the second variable and when I print "$foo" it's the former. But to get the the first element of "@foo" I use "$foo[0]", which has nothing to do with "$foo".

If I say that's bad, it doesn't mean I'm saying I don't understand it. It means I'm saying it's bad.

You don't need to explain to me when to use $ and when to use @ in perl.

Re: Go is still not good

Thomas Habets — Wed, 17 Sep 2025 18:07:26 -0000

I'm not sure why you're mansplaining my own blog post to me.

I am aware. I wrote the post.

Re: Bug Reports & Feedback: Did my site get deleted?

Thomas Habets — Wed, 03 Sep 2025 10:45:18 -0000

A follow-up: I contacted support, and they recovered my deleted site. They don't know how it got deleted. Which is… uh… very strange.

Re: Bug Reports & Feedback: Did my site get deleted?

Thomas Habets — Tue, 02 Sep 2025 06:29:47 -0000

Thanks again!

I've emailed them. I'm very curious if someone from reddit managed to get it deleted because I wrote a post critiquing the Go programming language. :-/

Re: Bug Reports & Feedback: Did my site get deleted?

Thomas Habets — Tue, 02 Sep 2025 06:08:31 -0000

Hi Kieran.

I can't find a site named "blargh" in my admin panel. I only see two other sites, shortnames "synscan" and "habetspp".

Per the troubleshooting page you linked (thank you), I have added habets.se and blog.habets.se to both sites I have in the admin panel. But since they're not "blargh", I'm not surprised that it didn't help.

I have now also registered the shortname, by creating a new site. That made disqus load again. But all the comments are gone!

Could you confirm whether or not my site was deleted? I think someone must have deleted it. How else could I have been able to create it now with the same shortname?

It is possible to restore the deleted comments?

Re: Go is still not good

Thomas Habets — Wed, 27 Aug 2025 10:38:47 -0000

That's almost by definition. The present tense self version of being wrong is a contradiction.

Given arguments I can become wrong past tense. But most disagreeing arguments seem to be "you're stupid and/or new to Go" or "you must be miserable". Those are not exactly learning opportunities. Others agree with me.

Re: Go is still not good

Thomas Habets — Mon, 25 Aug 2025 14:48:26 -0000

I'm not the hero you deserve, just the hero you need.

Re: Go is still not good

Thomas Habets — Sun, 24 Aug 2025 12:52:23 -0000

You don't need to explain my own blog post to me, thanks. I'm complaining about shitty interface decisions. So clearly I understand them.

They're working as intended, but the intentions are bad.

You have no idea what I know about memory. It's not in this post, or any other post of mine.

I'm sorry for what my blog post did to you or your family.

(oh, this post made it to reddit? That would explain the these low quality comments. Although I see on reddit someone says "Typed nils are one of the worst design outcomes in the language". I suggest you go argue with them there, instead)

Re: Go is still not good

Thomas Habets — Sun, 24 Aug 2025 02:59:30 -0000

I hear C# is like java but better. Considering that I've hated every minute I've spent in Java, I'm sceptical.

Re: Go is still not good

Thomas Habets — Sat, 23 Aug 2025 16:12:47 -0000

but most of this seems like petty bitchin

You don't have to read my blog if it triggers you.

But sure, it may sound like petty bitchin. But these small things add up to a bad language. It's not easy to describe why a language is bad on a high level. Like people can throw PL theory words at it, but theory is just theory. Or you can mention these "petty" examples. But also that can be discarded with "well just don't do that, then", or "everyone knows to not do that".

Which just raises the question of if PL theory isn't an argument, and examples isn't an argument, is there even such a thing as a bad programming language?

And why would people who believe there's no such thing as a bad programming language even read a blog post about a programming language being bad?

Amazon apparently wrote its first version by translating XML to HTML using XSLT. Is XSLT a good programming language? Can't argue with results. AMZN is doing great!

Re: Go is still not good

Thomas Habets — Sat, 23 Aug 2025 16:06:23 -0000

With a username like that I don't expect you to agree with me, hehe. And that's fine.

I disagree that Rust's solution complicates things. In fact, I think that Go's choice of not having arrays be first class citizens (by that I mean that it's very rare for Go code to work with arrays directly, instead it's all just subtext when dealing with slices) complicates things much more.

Rust puts the truth right there, whereas Go has a steep learning curve for new people specifically with regards to slices because arrays are core to them, and yet they're rarely mentioned. They become new people's spooky action at a distance.

Once you learn it, you know it. But so it goes for everything.

"Programmer problem" is another word for "sounds like a skill issue"? Sure. But I disagree that "just never make a mistake" is a viable strategy in a large codebase with a varied set of skilled people. Which is Go's audience.

Go has no excuse for creating these footguns. C++ does. (age, mostly)

Sounds like you don't consider the things I list as problems, because "just don't do that, then". I enjoy coding C++, it has many things one could also say "just don't do that, then" (like non-virtual destructors on class hierarchies, delete on a new[]'d array, or raw new/delete in most places at all).

Re: Go is still not good

Thomas Habets — Sat, 23 Aug 2025 15:54:57 -0000

Don't take language disagreements personally, and lash out. I think my critique makes it clear I know exactly what interfaces, yes. Deleting your comment.

Re: Go is still not good

Thomas Habets — Sat, 23 Aug 2025 04:52:41 -0000

Did you comment twice, or copy paste the other comment?

See other reply for which language I prefer.

I don't know why people (this comment and ones on hacker news) seem to think that one can only critique and criticize if one is miserable. I can write my own opinions on my blog, and be happy at the same time.

It seems a bit ad hominem and weird.

You don't have to stop using Go. You're free to even like it. But I'm not wrong.

Re: Go is still not good

Thomas Habets — Sat, 23 Aug 2025 04:46:44 -0000

Rust. I have a draft about where it feel it's shortcomings are, but they are miniscule compared to Go.

And Rust's problems are fixable. Go's are inherent, from its very core.

Re: Go programs are not portable

Thomas Habets — Fri, 22 Aug 2025 13:40:50 -0000

One problem though is that select() is affected by this, and you can't really subprocess that.

So if one had any illusions of Go being a systems language, that kills it.

Re: Go programs are not portable

Thomas Habets — Fri, 22 Aug 2025 13:16:22 -0000

It's true. The cross compiling story is pretty good.

But this article is about writing the code to be compilable for the platform in the first place, so it's a separate issue that still needs to be solved, or cross compiling won't work.

Re: Exploring RISC-V vector instructions

Thomas Habets — Tue, 01 Apr 2025 18:50:07 -0000

It seems pretty undocumented. Maybe easier to find for someone who can read Chinese.

But I think lscpu gives you the info you want:

```
$ cat /proc/cpuinfo processor : 0 hart : 0 model name : Ky(R) X1 isa : rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zfhmin_zca_zcd_zba_zbb_zbc_zbs_zkt_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt mmu : sv39 uarch : ky,x60 mvendorid : 0x710 marchid : 0x8000000058000001 mimpid : 0x1000000049772200 [... other cores ...] $ lscpu Architecture: riscv64 Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Model name: Ky(R) X1 Thread(s) per core: 1 Core(s) per socket: 8 Socket(s): 1 CPU(s) scaling MHz: 100% CPU max MHz: 1600.0000 CPU min MHz: 614.4000 Caches (sum of all): L1d: 256 KiB (8 instances) L1i: 256 KiB (8 instances) L2: 1 MiB (2 instances) $ lscpu -C NAME ONE-SIZE ALL-SIZE WAYS TYPE LEVEL SETS PHY-LINE COHERENCY-SIZE L1d 32K 256K 4 Data 1 128 64 L1i 32K 256K 4 Instruction 1 128 64 L2 512K 1M 16 Unified 2 512 64 $ lscpu -e CPU SOCKET CORE L1d:L1i:L2 ONLINE MAXMHZ MINMHZ MHZ 0 0 0 0:0:0 yes 1600.0000 614.4000 1600.0000 1 0 1 1:1:0 yes 1600.0000 614.4000 1600.0000 2 0 2 2:2:0 yes 1600.0000 614.4000 1600.0000 3 0 3 3:3:0 yes 1600.0000 614.4000 1600.0000 4 0 4 4:4:1 yes 1600.0000 614.4000 1600.0000 5 0 5 5:5:1 yes 1600.0000 614.4000 1600.0000 6 0 6 6:6:1 yes 1600.0000 614.4000 1600.0000 7 0 7 7:7:1 yes 1600.0000 614.4000 1600.0000
```

Re: VisionFive 2 quickstart

Thomas Habets — Thu, 07 Nov 2024 05:47:10 -0000

What's GNAT? And you mean ADA the language? I don't see why not.

Re: AX.25 over D-Star

Thomas Habets — Sun, 06 Oct 2024 16:52:10 -0000

The idea seems interesting, at least. But if we make something incompatible I'd say we can do better. VARA FM proves how fast it can go, even over audio modulated FM. But it's closed source, so I'm waiting for something better.

Well, I say waiting, but am trying to build something better, but likely something like NinoTNC will be the standard winner in not too long. I hear it's managed to do 19.2kbps over an audio channel, at least in testing. VARA FM maxes out (according to the manual) at 25kbps.

In other words, I don't think D-Star is the future of amateur packet radio / AX.25.

We'll see about 1.2GHz, but I fear long term we'll lose 1.2GHz to GNSS. :-(
(but sure, there's also 2.3GHz, 2.4GHz, and up)

Re: Dropping privileges

Thomas Habets — Fri, 13 Oct 2023 06:30:47 -0000

As I mentioned, "root" is mostly just a set of capabilities. You can grant the right to bind to a privileged port without giving full root. E.g. see https://stackoverflow.com/q...

Another option is to bind to a higher port, and then use DNAT to redirect incoming packets to the unprivileged port.

Re: No way to parse integers in C

Thomas Habets — Mon, 10 Jul 2023 11:29:37 -0000

Yeah. But this is writing half the integer parser myself.

Re: Decoding FSK

Thomas Habets — Mon, 03 Jul 2023 06:56:28 -0000

Happy to help!

I appreciate the feedback!

Re: RISC-V optimization and -mtune

Thomas Habets — Tue, 18 Apr 2023 09:21:06 -0000

1. Thanks! Fixed

2. It seems like a safe default for any architecture is to avoid adjacent write-read stalls though, due to latency, right? In the case of the U74 it's in-order, so no "magic". Maybe you're saying that the optimizer by default assumes OoO?

(this comment thread is also on https://www.reddit.com/r/RI...