Hacker News Reader

Comment by zeeboo | Hacker News Reader

The standard library IP type has worked for numerous programs for a literal decade. Just because a specialized application can do a better job by leveraging, again, decades of real world experience with the language doesn't invalidate that or mean it's half-assed.

I think your statement reflects more on your own biases than reality.

View on HN

I am not saying that the type is unusable. Plenty of high profile software has been written with C strings too yet we almost universally recognize them today as a mistake.

What I'm saying is that the design flaws of net.IP, the absence of which would have benefited the whole ecosystem, fall into a familiar pattern that can be learned from. It is good to see that addressed, even if by third parties.

If you can look at any widely used API that has existed for an extended period of time and not find a single tradeoff or hindsight flaw, you aren't looking hard enough.

I think being able to compare or hash IP addresses is a pretty baseline feature for an IP address type. I don't think that's some kind of unpredictable hindsight or tradeoff.

Obviously, people routinely compare and hash IP addresses in Go programs.

I can't tell if your're being sarcastic but it's hard to find a program that uses UDP and doesn't at some point store IP addresses in a hashmap. Many more will do the same for per-IP rate limiting. I think those are reasonable use cases for go.

Yes, I ship several of those commercially. Like I said: obviously, people hash and compare IP addresses routinely in Go.

I think the comma made it sound sarcastic where a period would’ve made it clearer you were agreeing.

I don't understand. but I'll consider my commas and periods more carefully next time I comment,

Out of interest, how do you compare/store in a map? Do you convert to a string, or a [4]byte array (for IPv4), or some other comparable/hashable type?

Either strings or (in the common case where I know I'm dealing with v4) uint32's. In fact, I probably do v6 stuff with uint32s too (I'm never working with an arbitrarily large v6 prefix).

I think this post is right about net.IP, though I also think the solution they've reached is Lovecraftian. But I write Rust, too, and I'd take net.IP over Sockaddr any day of the week.

I assume you mean std::net::SocketAddr? Out of curiosity, what's wrong with it?

I'd assume the lackluster selection of operations and how deeply nested some of the information is within the type. Definitely not the most ergonomic thing.

My personal favorite is probably the python ones. Only annoyance is difficulty of creating modified objects from existing ones.

Just not using the built in IP type, which is stupid.

Brad Fitzpatrick isn't exactly a third party. He was on the golang team until 2020 and you'll find his contributions all over the language.

It wouldn't surprise me one bit if this ended up in the stdlib for Go 2.0.

That's great to hear! Hope you're right.

I think it's more likely that numerous programs have worked around the issues of the built in type for a decade and/or changed scope/modified functionality to avoid it.

I had to work around one of the issues here in my first use of the built in ip type - I needed to parse ip addresses and pass them to a command that needed a tcp4 or tcp6 flag depending on the address type.

Reply on news.ycombinator.com