Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I write HTTP services in Go after 13 years

grafana.com

Post reply on HN
Print view View original

101–110 of 259 posts

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

#101

Post by xboxnolifes »

munk-a wrote: post #98
xboxnolifes wrote: post #36

Earlier quoted context omitted.

Crazy that actually using your type system leads to better code. Stop passing everything around as `string`. Parse them, and type them.

As a PHP developer I am frankly disappointed you think that we only do that with strings. I've got an array[1] full of other tools. 1. Or maybe a map? Those keys might have significance I didn't tell you about.

I originally typed out `int` and wanted to do more, but I try to keep my comments as targeted as possible to avoid the common reply pattern of derailing a topic by commenting on the smallest and least important part of it. If I type `string`, `int`, `arrays`, `maps`, `enums`... someone will write 3 paragraphs about enums are actually an adequate usage of the type system, and everyone will focus on that instead of the overarching message.

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

#103

Post by kcrwfrd_ »

devjab wrote: post #72
cogman10 wrote: post #40

Earlier quoted context omitted.

The issue is DRY often comes to wreck this sort of thing. Some devs will see "Hmm, Username is exactly the same as just a string so let's just use a string as Username is just added complexity". I've tried it with constructs like `Data` and `ValidatedData` and it definitely works, but you do end up with duplicate fields between the two objects or worse an ever growing inheritance tree and fields unrelated to either o…

One of the major issues with a lot of the outdated concepts in programming is that we still teach them to young people. I work a side gig as an external examiner for CS students. Especially in the early years they are taught the same OOP content that I was taught some decades ago, stuff that I haven’t used (also) for some decades. Because while a lot of the concepts may work well in theory, they never work out in a w…

It’s a balancing act, but deletable code is often preferable to purely-DRY-for-the-sake-of-DRY, overly abstracted code.

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

#106

Post by randomdata »

stouset wrote: post #91
the_gipsy wrote: post #83

Earlier quoted context omitted.

It's not guaranteed at all, that's where go's zero-values come in. E.g. nested structs, un/marshaljson magic methods etc. How do you deal with that?

Every struct requiring its zero value to be meaningful is probably one of the worst design flaws in the language.

There is no such requirement. Common wisdom suggests that you should ensure zero values are useful, but that isn't about every random struct field – only the values you actually give others. Initialize your struct fields and you won't have to consider their zero state. They will never be zero.

It's funny seeing this beside the DRY thread. Seems programmers taking things a bit too literally is a common theme.

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

#107

Post by chubot »

Animats wrote: post #73

I just run Go servers under fcgi. You get orchestration and crash recovery with a very simple interface. Fcgi will launch server processes as needed, feed them events, and shut it down when there's no traffic. Performance is good, and you can run on cheap hosting.

Which hosting do you use? I use fastcgi with python on Dreamhost and it works fine, but I’m sorta worried that they’ll turn it off because it seems kind of niche and under-documented

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

#108

Post by stouset »

randomdata wrote: post #106
stouset wrote: post #91

Earlier quoted context omitted.

Every struct requiring its zero value to be meaningful is probably one of the worst design flaws in the language.

There is no such requirement. Common wisdom suggests that you should ensure zero values are useful, but that isn't about every random struct field – only the values you actually give others . Initialize your struct fields and you won't have to consider their zero state. They will never be zero. It's funny seeing this beside the DRY thread. Seems programmers taking things a bit too literally is a common theme.

> Initialize your struct fields and you won't have to consider their zero state.

“Just do the right thing everywhere and you don’t have to worry!”

You can’t stop consumers of your libraries from creating zero-valued instances.

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

#109

Post by whimsicalism »

mtlynch wrote: post #25

> The Valid method takes a context (which is optional but has been useful for me in the past) and returns a map. If there is a problem with a field, its name is used as the key, and a human-readable explanation of the issue is set as the value. I used to do this, but ever since reading Lexi Lambda's "Parse, Don't Validate," [0] I've found validators to be much more error-prone than leveraging Go's built-in type check…

the fact that this is some special “technique” really shows how far behind Go’s type system & community around typing is
Post reply on HN