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

Go 1.14

blog.golang.org

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Go 1.14

#21

Post by sk0g »

marcrosoft wrote: post #14
sk0g wrote: post #8

Earlier quoted context omitted.

I constantly see this sentiment and don't get it. It's perfectly fine in GoLand, and has been for the year I've been using it. What's broken for you?

VScode: * Function renames * Function references across packages * imports on save Some of this can be fixed by restarting gopls (experimental) ever 20m: https://github.com/Microsoft/vscode-go/wiki/Go-modules-suppo...

VS Code is a text editor not an IDE, right? That's what its proponents always boasted in the beginning at least.

I just got work to pay for a GoLand licensed for me. The VSC experience was slower, more RAM hungry and not as full featured, so it didn't really make sense to stick with.

Re: Go 1.14

#22

Post by majewsky »

Townley wrote: post #16

Any Go developers with past experience in "heavier" frameworks have thoughts on giving it a try? I enjoy working with "batteries included" frameworks currently, and value the approach of "Here's an ORM... here's a template language... here's an auth system... use or remove them as you see fit" I've been told that the Go standard library is fully-featured enough that it can be considered a framework in its own right,…

I have written several HTTP-based services in Go. When you only expose an API, net/http is 99% of what you need. There are some useful addons like https://github.com/gorilla, and you'll probably pull in a library for auth.

For services with a web GUI, net/http is not comparable to the likes of Rails or Django. There is a templating library, but it's pretty barebones and you'll have to put quite a lot of boilerplate (or additional libraries) on top to make it work for anything beyond hello-world scale. Also you need libraries for all those secondary concerns that are usually handled on the framework level, like CSRF protection.

Re: Go 1.14

#23

Post by ptman »

Townley wrote: post #16

Any Go developers with past experience in "heavier" frameworks have thoughts on giving it a try? I enjoy working with "batteries included" frameworks currently, and value the approach of "Here's an ORM... here's a template language... here's an auth system... use or remove them as you see fit" I've been told that the Go standard library is fully-featured enough that it can be considered a framework in its own right,…

There's revel, which is rails-inspired. And beego, and aah and buffalo. But after those I'm looking into stdlib + chi and libraries over frameworks.

Re: Go 1.14

#24

Post by ptman »

majewsky wrote: post #22
Townley wrote: post #16

Any Go developers with past experience in "heavier" frameworks have thoughts on giving it a try? I enjoy working with "batteries included" frameworks currently, and value the approach of "Here's an ORM... here's a template language... here's an auth system... use or remove them as you see fit" I've been told that the Go standard library is fully-featured enough that it can be considered a framework in its own right,…

I have written several HTTP-based services in Go. When you only expose an API, net/http is 99% of what you need. There are some useful addons like https://github.com/gorilla , and you'll probably pull in a library for auth. For services with a web GUI, net/http is not comparable to the likes of Rails or Django. There is a templating library, but it's pretty barebones and you'll have to put quite a lot of boilerplate…

you might not need more advanced csrf protection than a cookie samesite policy.

Re: Go 1.14

#25

Post by zadokshi »

zchrykng wrote: post #19
Townley wrote: post #16

Any Go developers with past experience in "heavier" frameworks have thoughts on giving it a try? I enjoy working with "batteries included" frameworks currently, and value the approach of "Here's an ORM... here's a template language... here's an auth system... use or remove them as you see fit" I've been told that the Go standard library is fully-featured enough that it can be considered a framework in its own right,…

> ... Go standard library is fully-featured enough that it can be considered a framework in its own right... Maybe compared to writing a server in C/C++... ORM doesn't exist in the standard library. Templating is okay. Auth doesn't exist.

People choose go to escape the world of bloated ORM tools.

SQL sprinkled with a little bit of prudent caching works pretty well in go.

Re: Go 1.14

#26

Post by zadokshi »

ptman wrote: post #24
majewsky wrote: post #22

Earlier quoted context omitted.

I have written several HTTP-based services in Go. When you only expose an API, net/http is 99% of what you need. There are some useful addons like https://github.com/gorilla , and you'll probably pull in a library for auth. For services with a web GUI, net/http is not comparable to the likes of Rails or Django. There is a templating library, but it's pretty barebones and you'll have to put quite a lot of boilerplate…

you might not need more advanced csrf protection than a cookie samesite policy.

Then throw a hidden input field with a CSRF token in your form and your done.

Not sure what the big deal is here.

Post reply on HN