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

REST Servers in Go: Part 1 – standard library

eli.thegreenplace.net

Post reply on HN
Print view View original

71–80 of 149 posts

Re: REST Servers in Go: Part 1 – standard library

#71

Post by Ingon »

laverya wrote: post #41
swirepe wrote: post #31

Earlier quoted context omitted.

>I've had this a few times, most recently with "how do I add this data file to my binary". At least that one made it to master now, and will be in 1.16! Wait, how?? I've done some unholy things.

The best example for the new '//go:embed' directive I've seen so far is this: package main import ( "embed" "net/http" ) //go:embed assets/* var assets embed.FS func main() { fs := http.FileServer(http.FS(assets)) http.ListenAndServe(":8080", fs) } For the next month, the list of options here [0] will have to suffice. 0: https://go.googlesource.com/proposal/+/master/design/draft-e...

Or you can just use the 1.16beta compiler

Re: REST Servers in Go: Part 1 – standard library

#72

Post by zemo »

alchermd wrote: post #20

I'm an API developer working with Python and Django. I did dabble with Golang for quite some time, but I just can't seem to justify the effort (in terms of lines of codes and static typing) of writing a ReST API with Go when I can build a similar one with Django and co (DRF, Swagger, etc). Can someone chime in? There must be an obvious advantage that I might be missing.

running python servers is annoying, you have to have a menagerie of stupid little parts and things to get it all to fit together. I haven't done this in years but I always wound up with some mess of virtual envs, pip, gunicorn, nginx proxying, something to start the services, and that's _before_ writing any of my own code. With Go I just compile a static binary, rsync it to a server and turn it on and call it a day. The only other part I often use is nginx as a reverse proxy because it's easier to harden. Way easier to operate and way easier to not break once your project gets beyond a few kloc.

Re: REST Servers in Go: Part 1 – standard library

#73

Post by scrose »

qudat wrote: post #50
ithrow wrote: post #35

Earlier quoted context omitted.

Some prefer clear, flexible easy to debug code instead of coding to 15 layers of abstraction. For an HTTP API you have to discard more than half of Rails anyway.

I agree so hard on this. Anyone recommending rails as some sort of elevation of a restful API is puzzling to me. It’s easy to get started for people that don’t want to code. Instead they want to spend all of their time memorizing the cascade of configuration objects where you have to learn the exact phrase to get rails to do what you want it to. I know this is all opinion and I have colleagues who are excellent engin…

I wouldn’t call Rails ‘easy to get started’. The learning curve is steep, but once you get over it, you can hop into nearly any Rails application and immediately be able to contribute. I prefer Rails for most things work related for that very reason.

Having worked a couple places where Python or Go microservices were hyped up, but every installation, DB schema, and folder structure seemed to be built with a different idea in mind, and or debated, I have a strong appreciation for right standards around convention. Especially when I don’t have to get into debates like whether DB table names should be plural or singular.

On the side I really do enjoy working with Go though, and wouldn’t hesitate to use it if it seemed like the right tool for the moment.

Re: REST Servers in Go: Part 1 – standard library

#74

Post by pm90 »

qudat wrote: post #50
ithrow wrote: post #35

Earlier quoted context omitted.

Some prefer clear, flexible easy to debug code instead of coding to 15 layers of abstraction. For an HTTP API you have to discard more than half of Rails anyway.

I agree so hard on this. Anyone recommending rails as some sort of elevation of a restful API is puzzling to me. It’s easy to get started for people that don’t want to code. Instead they want to spend all of their time memorizing the cascade of configuration objects where you have to learn the exact phrase to get rails to do what you want it to. I know this is all opinion and I have colleagues who are excellent engin…

I suspect you will see a lot more of rails (and rails like frameworks) being used just because they are so simple to use and beginners can use it without understanding too deeply. Having more people who can understand/build/fix will always win out, and rails is what most coding bootcamp teach. So there’s just going to be too many folks who will choose rails over more suitable languages.

I’m not super convinced that’s a bad thing though. The software industry has always suffered a perennial shortage of engineers. What I predict will happen is that an ecosystem of tools will spring up around rails and there will be serious investment in improving performance rather than the framework being abandoned.

Remember how kubernetes changed infrastructure development to managing config files? It’s what I see happening to most areas of software development. The more experienced software engineers will then be responsible for optimizing/bug fixing/ scaling.

Re: REST Servers in Go: Part 1 – standard library

#75

Post by zemo »

usually for stores like this I just do this:

    type Store interface {
        GetTask(*Task) error
    }
instead of having "GetTaskByID" and "GetTaskByTag" and whatnot. Then in the caller you just do this:

    task := store.Task{ID: 5}
    if err := db.GetTask(&task); err != nil {
        // wahtever
    }
^ that gets the task by ID

    task := store.Task{Tag: "foo"}
    if err := db.GetTask(&task); err != nil {
        // wahtever
    }
^ that gets the task by tag.

Re: REST Servers in Go: Part 1 – standard library

#76

Post by volkk »

mhh__ wrote: post #46
alchermd wrote: post #20

I'm an API developer working with Python and Django. I did dabble with Golang for quite some time, but I just can't seem to justify the effort (in terms of lines of codes and static typing) of writing a ReST API with Go when I can build a similar one with Django and co (DRF, Swagger, etc). Can someone chime in? There must be an obvious advantage that I might be missing.

Static typing buys you correctness now . Go isn't really a poster child of language design, to be blunt - but it's better to find out now rather than in production. Compiled code is also significantly faster in many cases.

i see your point and i know OP asked about why Go instead of python, but having a statically typed language isn't limited to only Go. you could replace everything you wrote with Java/C++/C# and still have a similar answer (minus language design i guess which is a different argument)

Re: REST Servers in Go: Part 1 – standard library

#77

Post by SergeAx »

anderspitman wrote: post #8

I think I've managed to get by with less dependencies in Go than any other language. It somehow walks the line between JavaScript leftpad and Python "stdlib is where modules go to die". I don't think there's been a single instance where I've thought "why can't stdlib do this?" nor "why the heck is this in stdlib?"

There is an almost (?) official set of Go Proverbs: https://go-proverbs.github.io/ One of them is "A little copy is better than a little dependency". I like that one very much.

Re: REST Servers in Go: Part 1 – standard library

#78

Post by throwaway894345 »

permille42 wrote: post #67
throwaway894345 wrote: post #61

Earlier quoted context omitted.

Agreed. It seems silly to call "invoking constructors" "boring" but doing all of the same work in XML is somehow more interesting? It seems like you're just adding in a layer of indirection that does nothing besides exchange Go/Java/etc for XML/Groovy/etc at the expense that one must be familiar with the DI framework to understand how the DI files are loaded, linked together, and mapped to your application code.

The main benefit of constructing objects and tying them together via DI is to allow polymorphic handling of responsibilities. It is more complex than simply "I just make an interface and make everyone agree on that interfere". Everyone agreeing on the interface to use is very unlikely. The underlying data in different implementations will be different. This is something Golang fails terribly at because it doesn't hav…

> The main benefit of constructing objects and tying them together via DI is to allow polymorphic handling of responsibilities.

This is already provided by interfaces, as previously discussed. To be clear, dependency injection makes sense; however, dependency injection frameworks don’t make sense to me.

> The underlying data in different implementations will be different. This is something Golang fails terribly at because it doesn't have polymorphism.

Go definitely has always had polymorphism; that’s the whole point of interfaces.

> The way Golang works, and the reccomended patterns for Golang are somewhat anti-DI.

DI (assemble your object graph in main() instead of distributing it across dozens of constructors a la OOP) is idiomatic Go; DI frameworks are not.

Re: REST Servers in Go: Part 1 – standard library

#79

Post by sagichmal »

virmundi wrote: post #68
sagichmal wrote: post #57

Earlier quoted context omitted.

> Many say, "Pass the database connection in the params." ... How can you write tests for logic without having to instantiate a DB? You define and use an interface to model the DB, and use that as the mock point. Basic stuff.

I aware of making an interface for that. I advocate that. What I see people on r/golang saying, and even in HN, is to just pass the DB connection either explicitly or in the context. I hate this. It makes things bound to DBs.

Some people say this, but when they do, other more senior people quickly interject and say it's a bad idea.

Re: REST Servers in Go: Part 1 – standard library

#80

Post by franklyt »

hardwaresofton wrote: post #32
ankurpatel wrote: post #23

Looking at such articles makes me feel we are going back in time rather than improving efficiencies for developers to build RESTful server. If you look at Ruby on Rails you can build the server shown here in one min that is scalable and backed with database. I know people will complain about speed of execution of language and framework but do you really care if you are not expecting Google like traffic.

What you're pointing to is the need for better abstractions and Go is not the language for that (it will be more-so when generics arrive). There is a language that has faster-than-go speed and better abstractions, but HN seems to be somewhat decided on whether they think it's awesome or terrible, and there was recently an blog post on front-page about how it was bad for APIs (which I heavily disagree with but I am bi…

Are you talking about Haskell? That’s a hard sell.
Post reply on HN