How I write HTTP services in Go after 13 years • Hacker News Board

Re: How I write HTTP services in Go after 13 years

#191

Post by [deleted] » Sat, Feb 10, 2024, 2:15 PM UTC

DandyDev wrote: post #185

randomdata wrote: post #131

Earlier quoted context omitted.

> Except for all those times you're the consumer of someone else's library and there's no way for them to indicate that creating a zero-valued struct is a bug. Nonsense. Go has a built-in facility for documentation to communicate these things to other developers. Idiomatic Go strongly encourages you to use it. Consumers of the libraries expect it. > Sometimes it's nice to work with a type system where designers of li…

You manage to present a strawman and produce a No True Scotsman fallacy all at once in this comment thread. Nobody is suggesting that Coq should be used, so stop bringing it up (strawman). And yes, Coq might have an even stricter and more expressive type system than Rust. But nobody is asking for a perfect type system (no true Scotsman). People are asking to be able to prevent users of your library to provide illegal…

[deleted]

Re: How I write HTTP services in Go after 13 years

#192

Post by jopsen » Sat, Feb 10, 2024, 2:19 PM UTC

xyzzy123 wrote: post #97

dilyevsky wrote: post #66

Earlier quoted context omitted.

The problem with this approach is writing openapi by hand from scratch is incredibly tedious process. Writing Protobufs, capnproto or any such similar idl feels much more productive

Its a bit icky but LLMs / copilot can speed up the creation of openapi specs a lot. Agree it doesn't fix the "root" problem that the overall syntax is not ergonomic.

My point was that writing an openapi, or other IDL is faster than writing the code to manually do these things.

And more accurate than LLMs.

Feels like whenever an LLMs could code it, you'd be better of not having the boilerplate code at all.

Re: How I write HTTP services in Go after 13 years

#193

Post by randomdata » Sat, Feb 10, 2024, 2:20 PM UTC

DandyDev wrote: post #185

randomdata wrote: post #131

Earlier quoted context omitted.

> Except for all those times you're the consumer of someone else's library and there's no way for them to indicate that creating a zero-valued struct is a bug. Nonsense. Go has a built-in facility for documentation to communicate these things to other developers. Idiomatic Go strongly encourages you to use it. Consumers of the libraries expect it. > Sometimes it's nice to work with a type system where designers of li…

You manage to present a strawman and produce a No True Scotsman fallacy all at once in this comment thread. Nobody is suggesting that Coq should be used, so stop bringing it up (strawman). And yes, Coq might have an even stricter and more expressive type system than Rust. But nobody is asking for a perfect type system (no true Scotsman). People are asking to be able to prevent users of your library to provide illegal…

> People are asking to be able to prevent users of your library to provide illegal values. [...] and Typescript

Typescript, you say?

   const bar: Foo = {} as Foo

Hmm. Oh, right, just don't hold it wrong. But "sometimes it's nice to work with a type system where designers of libraries can actually prevent you from writing bugs."

Your example doesn’t even satisfy the base case, let alone the general case. Get back to us when you have actually read the thread and can provide something on topic.

Re: How I write HTTP services in Go after 13 years

#194

Post by DandyDev » Sat, Feb 10, 2024, 2:26 PM UTC

randomdata wrote: post #193

DandyDev wrote: post #185

Earlier quoted context omitted.

You manage to present a strawman and produce a No True Scotsman fallacy all at once in this comment thread. Nobody is suggesting that Coq should be used, so stop bringing it up (strawman). And yes, Coq might have an even stricter and more expressive type system than Rust. But nobody is asking for a perfect type system (no true Scotsman). People are asking to be able to prevent users of your library to provide illegal…

> People are asking to be able to prevent users of your library to provide illegal values. [...] and Typescript Typescript, you say? const bar: Foo = {} as Foo Hmm. Oh, right, just don't hold it wrong. But "sometimes it's nice to work with a type system where designers of libraries can actually prevent you from writing bugs." Your example doesn’t even satisfy the base case, let alone the general case. Get back to us…

But that is not an accident, is it? It’s someone very deliberately casting an object. It’s not the same and you probably know it.

Re: How I write HTTP services in Go after 13 years

#195

Post by randomdata » Sat, Feb 10, 2024, 2:43 PM UTC

DandyDev wrote: post #194

randomdata wrote: post #193

Earlier quoted context omitted.

> People are asking to be able to prevent users of your library to provide illegal values. [...] and Typescript Typescript, you say? const bar: Foo = {} as Foo Hmm. Oh, right, just don't hold it wrong. But "sometimes it's nice to work with a type system where designers of libraries can actually prevent you from writing bugs." Your example doesn’t even satisfy the base case, let alone the general case. Get back to us…

But that is not an accident, is it? It’s someone very deliberately casting an object. It’s not the same and you probably know it.

It might be an accident. Someone uninitiated may think that is how you are expected to initialize the value. A tool like Copilot may introduce it and go unnoticed.

But let's assume the programmer knows what they are doing and there is no code coming from any other source. When would said programmer write code that isn't deliberate? What is it about Go that you think makes them, an otherwise competent programmer, flail around haphazardly without any careful deliberation?

Re: How I write HTTP services in Go after 13 years

#196

Post by stouset » Sat, Feb 10, 2024, 2:43 PM UTC

randomdata wrote: post #182

the_gipsy wrote: post #179

Earlier quoted context omitted.

You don't have to go as far as Coq. Rust manages "parse, don't validate" extremely well with serde. Go's zero-values are the problem, not any other lack of its type system.

> You don't have to go as far as Coq. No, you do. Anywhere the type system is incomplete means that the consumer can do something the library didn't intend. Rust does not have a complete type system. There was no relevance to mentioning it. But I know it is time for Rust's regularly scheduled ad break. And while you are at it, enjoy a cool, refreshing Coca-Cola. > Go's zero-values are the problem "Sometimes it's nice…

This insane perspective of “nothing is totally perfect so any improvements over what go currently does are pointless” whenever you confront a gopher with some annoying quirk of the language is one of the worst design flaws in the golang community hivemind.

Re: How I write HTTP services in Go after 13 years

#197

Post by randomdata » Sat, Feb 10, 2024, 2:49 PM UTC

stouset wrote: post #196

randomdata wrote: post #182

Earlier quoted context omitted.

> You don't have to go as far as Coq. No, you do. Anywhere the type system is incomplete means that the consumer can do something the library didn't intend. Rust does not have a complete type system. There was no relevance to mentioning it. But I know it is time for Rust's regularly scheduled ad break. And while you are at it, enjoy a cool, refreshing Coca-Cola. > Go's zero-values are the problem "Sometimes it's nice…

This insane perspective of “nothing is totally perfect so any improvements over what go currently does are pointless” whenever you confront a gopher with some annoying quirk of the language is one of the worst design flaws in the golang community hivemind.

Tell us, why you hold that perspective? It's an odd one. Nobody else in this thread holds that perspective. You even admit it is insane, yet here you are telling us about this unique perspective you hold for some reason. Are you hoping that we will declare you insane and admit you in for care? I don't quite grasp the context you are trying to work within.

Re: How I write HTTP services in Go after 13 years

#198

Post by randomdata » Sat, Feb 10, 2024, 2:53 PM UTC

the_gipsy wrote: post #186

randomdata wrote: post #182

Earlier quoted context omitted.

> You don't have to go as far as Coq. No, you do. Anywhere the type system is incomplete means that the consumer can do something the library didn't intend. Rust does not have a complete type system. There was no relevance to mentioning it. But I know it is time for Rust's regularly scheduled ad break. And while you are at it, enjoy a cool, refreshing Coca-Cola. > Go's zero-values are the problem "Sometimes it's nice…

Any language without zero-values (or some equally destructive quality) can do "parse, don't validate". Go cannot. Rust is just an example.

Top of the hour again? Time for another Rust advertisement?

The topic at hand is about preventing library users from doing things the library author didn't intended using the type system, not "what happens if a language has zero-values". Perhaps you are not able to comprehend this because you are hungry? You're not you when you are hungry. Grab a Snickers.

Re: How I write HTTP services in Go after 13 years

#199

Post by vorticalbox » Sat, Feb 10, 2024, 2:53 PM UTC

BreakfastB0b wrote: post #124

mrklol wrote: post #95

Earlier quoted context omitted.

Why? You can easily call NewUsername inside NewAccount for example, just return the error. Or did I misunderstood?

Because go doesn’t have exhaustiveness checking when initialising structs. Instead it encourages “make the zero value meaningful” which is not always possible nor desirable. I usually use a linter to catch this kind of problem https://github.com/GaijinEntertainment/go-exhaustruct

I like this but in the examples would volume be calculated by width/length rather than being set?

Re: How I write HTTP services in Go after 13 years

#200

Post by zemo » Sat, Feb 10, 2024, 3:05 PM UTC

kubanczyk wrote: post #190

zemo wrote: post #172

Earlier quoted context omitted.

I used that pattern for a while but stopped using it. I first encountered it from this blog post: https://commandcenter.blogspot.com/2014/01/self-referential-... It's a lot of boilerplate to create something that's not actually immutable. It also makes it harder to figure out which options are available, since now you can't just look at the documentation of the type, you have to look at the whole module package to fi…

> you can't just look at the documentation of the type Sure you can. Option func is a constructor for option type, and constructors are auto-included above methods in the docs. PLS completion works for them as well.

The options for the thing being constructed are all separate types from the thing being constructed; the options aren’t a facet of the definition of the type they mutate.