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

81–90 of 149 posts

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

#81

Post by sbergot »

throwaway894345 wrote: post #15
dastx wrote: post #14

Is there a reason to prevent concurrent reads? Seems rather .. Silly considering the db should handle all that stuff. Also, one thing I'm still waiting for is a decent non-complex di that works using go generate. I'm aware of google's wire (?) But I've looked at it multiple times and I still struggle to understand it.

I've never understood the value proposition of a DI framework. Why would I want one when I can initialize my objects in main()? Is XML or JSON or whatever really that much more pleasant than wiring together Go objects?

You can initialize your object with main. But if you are reusing some implementation in multiple object you will start to repeat yourself a lot in the initialization.

A DI framework allows you to set conventions to avoid repeating yourself in the initialization phase. (ie if a class requires a parameter 'foo', look for a class named 'FooImpl').

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

#82

Post by pjmlp »

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.

That is the whole ethos of Go community, at least they had something modern like a GC from the get go.

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

#83

Post by scns »

franklyt wrote: post #80
hardwaresofton wrote: post #32

Earlier quoted context omitted.

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.

He means Rust.

https://news.ycombinator.com/item?id=25798008

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

#84

Post by franklyt »

scns wrote: post #83
franklyt wrote: post #80

Earlier quoted context omitted.

Are you talking about Haskell? That’s a hard sell.

He means Rust. https://news.ycombinator.com/item?id=25798008

I was hoping even less that was the case, feels like a very out of touch comment, but I’m willing to listen.

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

#85

Post by lenartowski »

hit8run wrote: post #58

I’ve written a full stack web app with payment integration multi tenancy etc. in plain go. I learned a lot on that journey and what I learned made me value full stack frameworks like rails again. If you want to build something competitive you will need to write lots of things in plain go that you wouldn’t need to bother with when using rails or something similar with sane conventions.

Out of curiosity, is your app shared on github?

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

#86

Post by lenartowski »

skjfdoslifjeifj wrote: post #29
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.

He could build it in Go much faster just by using a couple of additional libraries but he's purposely limiting himself to just the standard library for the purpose of these articles. > 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. If you don't care that's fine, but there are lots of us that do. This is subjective, bu…

What languages/framework do you use when performance/memory usage is key?

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

#87

Post by theshrike79 »

lenartowski wrote: post #86
skjfdoslifjeifj wrote: post #29

Earlier quoted context omitted.

He could build it in Go much faster just by using a couple of additional libraries but he's purposely limiting himself to just the standard library for the purpose of these articles. > 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. If you don't care that's fine, but there are lots of us that do. This is subjective, bu…

What languages/framework do you use when performance/memory usage is key?

Not OP, but I'd go with Go or a fresh version of .NET Core depending on where it would need to integrate to.

If we're talking real time sub-millisecond performance, then Rust.

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

#88

Post by valenterry »

sbergot wrote: post #81
throwaway894345 wrote: post #15

Earlier quoted context omitted.

I've never understood the value proposition of a DI framework. Why would I want one when I can initialize my objects in main()? Is XML or JSON or whatever really that much more pleasant than wiring together Go objects?

You can initialize your object with main. But if you are reusing some implementation in multiple object you will start to repeat yourself a lot in the initialization. A DI framework allows you to set conventions to avoid repeating yourself in the initialization phase. (ie if a class requires a parameter 'foo', look for a class named 'FooImpl').

Could you give a more concrete example? How would you "repeat" yourself?

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

#90

Post by RobertKerans »

pm90 wrote: post #74
qudat wrote: post #50

Earlier quoted context omitted.

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…

Putting aside that your post kinda reads as if it were written ten years ago (most bootcamps do not teach Rails and it's vanishingly unlikely it'll reach the position it was ten years ago: cf JavaScript), I take some issue with

> beginners can use it without understanding too deeply...So there’s just going to be too many folks who will choose rails over more suitable languages.

It's not about "beginners" or "more suitable languages". You need an ability to build highly specialised software and you need general frameworks that will not be optimised for {specialised thing} but can do most of the things that you need for a certain task without having to hand write everything. Without the latter, all that happens is constant yak shaving and reinventions of the wheel. Rails (for example) is highly suitable for many things, getting clever points for not using it is great, but it's not very practical.

Post reply on HN