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

How I Start: Go

howistart.org

Post reply on HN
Print view View original

31–36 of 36 posts

Re: How I Start: Go

#31

Post by enneff »

mononcqc wrote: post #30

Am I right in my understanding that the end of the last code snippet shows that the app will error out for the user every time any single one of the many APIs used is unavailable, rather than making an average of the remaining services (1 of them)? Isn't this approach making the service's downtime be the sum of the downtime (minus overlap) from all the APIs being called?

You're quite right. The mutliWeatherProvider should probably collect the errors and only error out if it doesn't get a single good response. Easy to do.

Re: How I Start: Go

#32

Post by dsymonds »

aaron-lebo wrote: post #8
aaronblohowiak wrote: post #7

Earlier quoted context omitted.

>couldn't think of a way that did not end up using reflection The builtin decoders (eg, json) use reflection. You don't lose any of the benefits of static typing as you are still decoding into your statically-typed object. I would separate form parsing from object validation. Use something like this: https://github.com/ajg/form to populate statically-typed go structs from form data, and then validate your objects.

There is a speed hit to reflection, though, right? Also, you do lose the benefit of static typing, for example, the following typo isn't picked up at compile time: type User struct { Name string `form:"nam"` } Tags are rather ugly and don't scale to many options well. What happens when your ORM, form validation library, xml library, and json libraries each need a separate tag? That's a slight exaggeration but you cou…

There's a significant speed hit to reflection, but it's going to get lost in the noise if you're making HTTP requests.

Re: How I Start: Go

#33

Post by cakoose »

aaron-lebo wrote: post #8
aaronblohowiak wrote: post #7

Earlier quoted context omitted.

>couldn't think of a way that did not end up using reflection The builtin decoders (eg, json) use reflection. You don't lose any of the benefits of static typing as you are still decoding into your statically-typed object. I would separate form parsing from object validation. Use something like this: https://github.com/ajg/form to populate statically-typed go structs from form data, and then validate your objects.

There is a speed hit to reflection, though, right? Also, you do lose the benefit of static typing, for example, the following typo isn't picked up at compile time: type User struct { Name string `form:"nam"` } Tags are rather ugly and don't scale to many options well. What happens when your ORM, form validation library, xml library, and json libraries each need a separate tag? That's a slight exaggeration but you cou…

You're example is not a static typing issue. It's a feature of the library that the struct field doesn't have to have the same name as the form field.

I think the issue is more of a DRY thing, which could maybe be fixed with something like:

    type User struct {
        FirstName string  `form:lowercase_hyphenated`
        LastName  string  `form:lowercase_hyphenated`
    }
This hypothetical syntax would instruct the library to look for the form fields "first-name" and "last-name".

Re: How I Start: Go

#34

Post by lfx »

andrewgleave wrote: post #24

I recently wrote a Go weather backend as part of a talk I did on React and hooked into Forecast's API (which the author mentions as an exercise). https://github.com/andrewgleave/react-weather It's very simple, but I'd be interested to hear feedback on making it more idiomatic Go.

Nice, thanks for sharing this. Will play around!

Re: How I Start: Go

#35

Post by sagichmal »

Intermernet wrote: post #28
sagichmal wrote: post #18

Earlier quoted context omitted.

> Don't use println() println() is nice because it doesn't require an import. For "the smallest possible program" I think it's a good match. > decoders also support simple maps in addition to tagged > structs I think it's a mistake to teach Go programmers to decode into map[string]interface{}. It's pretty rare that you actually want to do that.

Yes, but as stated above "it is not guaranteed to stay in the language". The functions from "fmt" are guaranteed to stay in the language. May as well start learning the language with best practices, even if it does involve an extra line to 'import "fmt"'.

I disagree. (shrug)

Re: How I Start: Go

#36

Post by VeejayRampay »

ahmett wrote: post #14

It's actually annoying Go is shown as a web language in many tutorials. It's simply not. If you use Go for systems programming and other stuff like creating daemons, services, you will fall in love with it more and will not go back to any other language. That's why I believe those Go start tutorials should not be showing the net/http side of things.

Still a fantastic tutorial.
Post reply on HN