6 ms·

>In Golang, dependencies are minimised. Everyone tries to stick to the standard library as much as possible. i don't understand this. yes net/http is nice but

>In Golang, dependencies are minimised. Everyone tries to stick to the standard library as much as possible. i don't understand this. yes net/http is nice but there's no router, there's no orm (yes i know that's not really possible at all because of strong typing), yes database/sql exists but you know most everyone uses at least sqlx and e.g. lib/pq. yes html/template is nice but we're all doing SPAs now anyway. okay there's logging but e.g. no websockets. so in what sense is the stl really complete? what modern web app could you write with just the stl?

marcus_holmes 9y ago
You don't need a router (especially for an SPA with client-side routing). If you've got less than 20 or so routes, then a big switch statement is all the routing you need. Learning to write "proper" logic around routes instead of parsing them with regexes was a learning milestone for me. You don't need an ORM. Mapping database tables to objects directly is a really bad idea. Write SQL, it's easy, simple and cheap. Yes, you'll repeat yourself. Golang generally prefers some repetition to some dependency. You don't need middleware. Once you get used to handling routes as logic, then the need for middleware kinda vanishes. You can use the semi-official google websockets package [0]. It's borderline whether this could be considered part of the standard library or not (I use the google uuid package all the time for the same reason). I believe there's an intention to include these packages in the standard library at some point, probably Go v2. Try it out, it's liberating. 0: https://godoc.org/golang.org/x/net/websocket https://godoc.org/golang.org/x/net/websocket
- akmittal 9y ago
  I see Go community pushing for no framework everywhere. I agree Go std library is good enough but some people prefer the framework magic because they want the stuff done faster. Community should better be saying try std library if you find it verbose try framework(router+ORM)
  - dithering 9y ago
    > some people prefer the framework magic because they want the stuff done faster. Those people should try being maintenance programmers sometime /curmudgeonly-grumble
- jjoonathan 9y ago
  I still remember the first time I had to pick apart a gigantic chunk of java code and found a big switch statement at the center instead of a web of introspectively discovered implicitly wired reactively chained bean factory factory factories or some such nonsense. The relief was almost palpable.
- yur83838 9y ago
  You don't need a router, but it is much more readable with one. You don't need middleware, but it is much more readable with r.Use(jwtVerify) then writing a deeply nested half router with logic. If you're running a single endpoint, then the router is adding zero value.
  - dithering 9y ago
    Readability is, I think, a function of your expectations. If you're used to seeing a particular incantation, it's readable. Personally (emphasis on the personally, which is my point), I don't think it gets much more readable that a great big switch statement.
- leaveyou 9y ago
  I agree with everything you said except the websocket.. the best websocket lib for golang until now is https://github.com/gorilla/websocket https://github.com/gorilla/websocket
  - marcus_holmes 9y ago
    It's getting to the point where the Gorilla packages could be considered part of the standard library ;) I agree, but the point is that you can do this with just the "almost official" package. It's not like you have to use the gorilla package because there's no standard library package.
rqs 9y ago
First, I don't think net/http is nice, but you know what's good about Go? It's so modular that you can replace the builtin HTTP server with other one you like (gorilla/http for example) and your code _can_ just continue to work without modification. And, Go had many third-party Router, ORM, Websocket and Template Engine implementations out there, many of them are also proud to be ... independent, so you're less likely to end up in a Dependency Hell. Go standard library is not there to force people to use it, rather, it's there to setup a standard so different people can work together more effectively. So: > in what sense is the stl really complete? what modern web app could you write with just the stl? 1, It's huge, but not complete; 2, You can actually do it with just Go standard library (No third-party package) if you REALLY wants to. It's not very hygiene though, you will end up wrap many things up for better project structure (And resulting many packages that you might later proudly put on your GitHub page): Use net/http as HTTP server (Request handling and parsing); use net.Dial to connect database and cache (And write their protocol); html/template for outputting rendered HTML landing page; encoding/json for parsing and outputting API request and respond.
donatj 9y ago
There is totally a router, ServeMux, which while basic is enough for 90% of basic tasks if you structure your requests REST-y. As for ORM, you should basically never use an ORM, ever. They’re a crutch. Learn SQL, write some basic mappers and your SQL will be so much quicker and more optimized than an ORM can generate. An ORM is literally throwing money out the window. https://golang.org/pkg/net/http/#ServeMux.Handle https://golang.org/pkg/net/http/#ServeMux.Handle
- heroprotagonist 9y ago
  I've seen teams of Go developers shoot themselves in the foot so many times with their hand-crafted SQL. Yes, they should know SQL and be better. And if they think about it, and focus on it, they are. But it's the mistakes they don't anticipate making that end up causing impacts on their users. Then they create a fix, but the damage is done. I think the goal behind a good ORM is not to replace making SQL queries entirely. It's to stop stupid mistakes that result from an uneven distribution of expertise. And if they find some area where performance is particularly sensitive and the ORM is not optimal, they can drop down to raw SQL again. If your team members all have expertise and your test coverage and code review processes are very thorough, it's probably not necessary. An ORM is not a magic bullet for every team. In the same vein, the dogmatic advice to "always handcraft your SQL" is also not a magic bullet.
  - marcus_holmes 9y ago
    yeah, but... same for any code. A team of coders who don't know javascript will create buggy, insecure Node apps. There's nothing about SQL as a coding language that creates this. It's more that modern coders are used to not having to learn SQL and trusting the ORM to do the thing for them. So when they encounter actual SQL (usually because they need to break the object <-> table mapping) it's all scary and weird. Back in the day, of course, we had DBA's (DataBase Administrators) to make sure that application devs who didn't know enough SQL to not make a mess of things, didn't actually make a mess of things. And yes, we hated the DBA's because they were always telling us our SQL sucked. Great training though. So, yeah, your point is valid, but there's a better solution to that problem: hire a DBA
lloeki 9y ago
> yes net/http is nice but there's no router, there's no orm... yes database/sql exists but you know most everyone uses... yes html/template is nice but we're all... Three fallacies of dependencies: https://www.youtube.com/watch?v=yi5A3cK1LNA https://www.youtube.com/watch?v=yi5A3cK1LNA > what modern web app could you write with just the stl? Lots. You just have to change your frame of mind. > i know that's not really possible at all because of strong typing Once you realise the above, you also realise that most of the time you don't need all that fancy stuff and you just write super boring code that works.
- marcus_holmes 9y ago
  >> you just write super boring code that works. This. This is the essence of Go to my mind :)

marcus_holmes 9y ago

You don't need a router (especially for an SPA with client-side routing). If you've got less than 20 or so routes, then a big switch statement is all the routing you need. Learning to write "proper" logic around routes instead of parsing them with regexes was a learning milestone for me. You don't need an ORM. Mapping database tables to objects directly is a really bad idea. Write SQL, it's easy, simple and cheap. Yes, you'll repeat yourself. Golang generally prefers some repetition to some dependency. You don't need middleware. Once you get used to handling routes as logic, then the need for middleware kinda vanishes. You can use the semi-official google websockets package [0]. It's borderline whether this could be considered part of the standard library or not (I use the google uuid package all the time for the same reason). I believe there's an intention to include these packages in the standard library at some point, probably Go v2. Try it out, it's liberating. 0: https://godoc.org/golang.org/x/net/websocket https://godoc.org/golang.org/x/net/websocket

akmittal 9y ago
I see Go community pushing for no framework everywhere. I agree Go std library is good enough but some people prefer the framework magic because they want the stuff done faster. Community should better be saying try std library if you find it verbose try framework(router+ORM)
- dithering 9y ago
  > some people prefer the framework magic because they want the stuff done faster. Those people should try being maintenance programmers sometime /curmudgeonly-grumble
jjoonathan 9y ago
I still remember the first time I had to pick apart a gigantic chunk of java code and found a big switch statement at the center instead of a web of introspectively discovered implicitly wired reactively chained bean factory factory factories or some such nonsense. The relief was almost palpable.
yur83838 9y ago
You don't need a router, but it is much more readable with one. You don't need middleware, but it is much more readable with r.Use(jwtVerify) then writing a deeply nested half router with logic. If you're running a single endpoint, then the router is adding zero value.
- dithering 9y ago
  Readability is, I think, a function of your expectations. If you're used to seeing a particular incantation, it's readable. Personally (emphasis on the personally, which is my point), I don't think it gets much more readable that a great big switch statement.
leaveyou 9y ago
I agree with everything you said except the websocket.. the best websocket lib for golang until now is https://github.com/gorilla/websocket https://github.com/gorilla/websocket
- marcus_holmes 9y ago
  It's getting to the point where the Gorilla packages could be considered part of the standard library ;) I agree, but the point is that you can do this with just the "almost official" package. It's not like you have to use the gorilla package because there's no standard library package.

rqs 9y ago

First, I don't think net/http is nice, but you know what's good about Go? It's so modular that you can replace the builtin HTTP server with other one you like (gorilla/http for example) and your code _can_ just continue to work without modification. And, Go had many third-party Router, ORM, Websocket and Template Engine implementations out there, many of them are also proud to be ... independent, so you're less likely to end up in a Dependency Hell. Go standard library is not there to force people to use it, rather, it's there to setup a standard so different people can work together more effectively. So: > in what sense is the stl really complete? what modern web app could you write with just the stl? 1, It's huge, but not complete; 2, You can actually do it with just Go standard library (No third-party package) if you REALLY wants to. It's not very hygiene though, you will end up wrap many things up for better project structure (And resulting many packages that you might later proudly put on your GitHub page): Use net/http as HTTP server (Request handling and parsing); use net.Dial to connect database and cache (And write their protocol); html/template for outputting rendered HTML landing page; encoding/json for parsing and outputting API request and respond.

donatj 9y ago

There is totally a router, ServeMux, which while basic is enough for 90% of basic tasks if you structure your requests REST-y. As for ORM, you should basically never use an ORM, ever. They’re a crutch. Learn SQL, write some basic mappers and your SQL will be so much quicker and more optimized than an ORM can generate. An ORM is literally throwing money out the window. https://golang.org/pkg/net/http/#ServeMux.Handle https://golang.org/pkg/net/http/#ServeMux.Handle

heroprotagonist 9y ago
I've seen teams of Go developers shoot themselves in the foot so many times with their hand-crafted SQL. Yes, they should know SQL and be better. And if they think about it, and focus on it, they are. But it's the mistakes they don't anticipate making that end up causing impacts on their users. Then they create a fix, but the damage is done. I think the goal behind a good ORM is not to replace making SQL queries entirely. It's to stop stupid mistakes that result from an uneven distribution of expertise. And if they find some area where performance is particularly sensitive and the ORM is not optimal, they can drop down to raw SQL again. If your team members all have expertise and your test coverage and code review processes are very thorough, it's probably not necessary. An ORM is not a magic bullet for every team. In the same vein, the dogmatic advice to "always handcraft your SQL" is also not a magic bullet.
- marcus_holmes 9y ago
  yeah, but... same for any code. A team of coders who don't know javascript will create buggy, insecure Node apps. There's nothing about SQL as a coding language that creates this. It's more that modern coders are used to not having to learn SQL and trusting the ORM to do the thing for them. So when they encounter actual SQL (usually because they need to break the object <-> table mapping) it's all scary and weird. Back in the day, of course, we had DBA's (DataBase Administrators) to make sure that application devs who didn't know enough SQL to not make a mess of things, didn't actually make a mess of things. And yes, we hated the DBA's because they were always telling us our SQL sucked. Great training though. So, yeah, your point is valid, but there's a better solution to that problem: hire a DBA

lloeki 9y ago

> yes net/http is nice but there's no router, there's no orm... yes database/sql exists but you know most everyone uses... yes html/template is nice but we're all... Three fallacies of dependencies: https://www.youtube.com/watch?v=yi5A3cK1LNA https://www.youtube.com/watch?v=yi5A3cK1LNA > what modern web app could you write with just the stl? Lots. You just have to change your frame of mind. > i know that's not really possible at all because of strong typing Once you realise the above, you also realise that most of the time you don't need all that fancy stuff and you just write super boring code that works.

marcus_holmes 9y ago
>> you just write super boring code that works. This. This is the essence of Go to my mind :)