Some Go web dev notes • Hacker News Board

Re: Some Go web dev notes

#151

Post by zaptheimpaler » Wed, Oct 02, 2024, 9:43 PM UTC

cle wrote: post #85

zaptheimpaler wrote: post #81

I've been using go for a month now in a new job and hate it. It feels like they learned nothing from the past 20 years of language development. Just one huge problem is that they REPEATED Java's million/billion dollar mistake with nulls. The usual way to get HTTP Headers using Go cannot distinguish between an empty header value and no header at all because the method returns "nil" for both these cases. They could've…

> The usual way to get HTTP Headers using Go cannot distinguish between an empty header value and no header at all HTTP headers in Go are maps, which have a built-in mechanism for checking key existence, which distinguishes b/t empty and missing. No nils involved. if vals, ok := headers["Content-Length"]; !ok { // no content-length header was passed }

It looks like this idiom is specifically for maps, but the recommended way (by their own docs) to access Headers is using the `.Get` method, which canonicalizes header names before looking at the map. This method predictably does not support the idiom, because they made a stupid special case idiom that applies only to maps instead of using an Option type that would work in all cases, including custom types that might have similar requirements.

Like this doesn't work:

    nonexist, ok := req.Header.Get("X-Custom-Header")

Re: Some Go web dev notes

#152

Post by zaptheimpaler » Wed, Oct 02, 2024, 9:46 PM UTC

WuxiFingerHold wrote: post #89

zaptheimpaler wrote: post #81

I've been using go for a month now in a new job and hate it. It feels like they learned nothing from the past 20 years of language development. Just one huge problem is that they REPEATED Java's million/billion dollar mistake with nulls. The usual way to get HTTP Headers using Go cannot distinguish between an empty header value and no header at all because the method returns "nil" for both these cases. They could've…

Go as a language is not fun at all. Nor very good. Weaker type system and less language features that increase productivity and readability than C#, Java, Kotlin and Typescript, no null checks. Go as a runtime is outstanding. Go's tooling, stability and governance are very good. Nothing is perfect. Enter into your compromise.

I understand the pragmatic point of view but that doesn't mean I can't point out its flaws or that this was some necessary compromise - it was a choice. There's no reason the Go platform couldn't be as stable as it is and also not be a braindead language from the 90s.

As an example Rust has its flaws but it does have all the modern language niceties with great tooling, build system and a solid platform.

Re: Some Go web dev notes

#153

Post by codegeek » Thu, Oct 03, 2024, 4:34 PM UTC

theshrike79 wrote: post #147

kolja005 wrote: post #28

Earlier quoted context omitted.

I'm curious in what sense you find Python difficult to deploy? My company has tons of Python APIs internally and we never have much trouble with them. They are all pretty lightly used services so it it something about doing it on a larger scale?

Deploying a Go application: copy executable to server, done. Deploying a Python application: 1) Install python globally (oof) 2) figure out which venv system to use 3) copy project to server 4) install project to venv 5) figure out how to run it inside the venv so that it'll find the correct package versions from there instead of using the global ones.

Yea. I have worked with Python and Ruby just a little to know that deployments are a pain with those 2. Go is a breeze. You do need to setup systemd etc to run the binary but thats it.

Re: Some Go web dev notes

#154

Post by cle » Fri, Oct 04, 2024, 5:22 PM UTC

zaptheimpaler wrote: post #151

cle wrote: post #85

Earlier quoted context omitted.

> The usual way to get HTTP Headers using Go cannot distinguish between an empty header value and no header at all HTTP headers in Go are maps, which have a built-in mechanism for checking key existence, which distinguishes b/t empty and missing. No nils involved. if vals, ok := headers["Content-Length"]; !ok { // no content-length header was passed }

It looks like this idiom is specifically for maps, but the recommended way (by their own docs) to access Headers is using the `.Get` method, which canonicalizes header names before looking at the map. This method predictably does not support the idiom, because they made a stupid special case idiom that applies only to maps instead of using an Option type that would work in all cases, including custom types that might…

Sounds like you're actually just mad that it didn't have generics from the beginning. That horse has been beaten to death for years.

I don't think it's fair though to characterize different points on a tradeoff curve as "stupid". If you're mad that you're forced to use a language with inappropriate tradeoffs for your context, then the right person to blame would be whoever picked it for your project to begin with.