4 ms·

> Straight up, I want you to explain the complete before and beneath of your favorite tech stack or this is problematically hypocritical. I can answer this one

> Straight up, I want you to explain the complete before and beneath of your favorite tech stack or this is problematically hypocritical. I can answer this one. I could explain to you every aspect of go's net/http package and database/sql package. The interface is compact, and even the source is very legible and easy to digest. You don't need all the extra bullshit to build API and run CRUD operations. I am a former RoR developer. I have lost no speed in just using simple tools and simple packages. Also, I can have a junior or associate developer from any background get up to speed in a matter of days. Where as when I was at the Rails shop, you specifically had to hire a "rails guy/gal" and even then still took them days to get started. (Don't mean for this to be a "go is great" rant, I am sure there are equally simple tools out there - Dropwizard is another one that comes to mind -- just a bunch of jars glued together)

RangerScience 9y ago
> every aspect of go's net/http package and database/sql package Nice! That sounds really appealing; I want to learn Go, I just haven't felt like I've identified a problem I want to solve that's best solved in Go. That said, the obvious direction this questioning is going is... Well, but either you're relying on the database and networking magic, or you need to understand the before/beneath of the database and networking; and it keeps recursing down until you get to the point of electrons in silicon, and then the switch is "magic of the scientific method". How do you draw the line of "this magic is fine" and "this magic is not fine"? It sounds like maybe the line isn't "do you know" but rather "what does it take to learn", and that Go makes it easy to learn the before / beneath?
sjellis 9y ago
I suspect that you learned a lot from Rails, though. For example, your applications probably have a thought-out directory structure, you clearly understand how the applications are layered, you probably pay attention to having good names, and think about testing. It is possible to learn good practices without seeing well-structured applications that you can use as "role models", but it's really hard (I know, I had to read how to structure n-tier applications from books, and then apply it to a deficient platform that my employer had standardized on). The "just use standard library" argument often seems a bit deceptive to me, though. For example, how are you managing schema updates?
- treehau5 9y ago
  > I suspect that you learned a lot from Rails, though. For example, your applications probably have a thought-out directory structure [..] Absolutely, not saying my experience doesn't translate. However directory structure doesn't exist like you think in go. Files are the primary organization, and the only thing that goes in subfolders are different packages. It's actually quite nice, now I don't need to dig into 4-6 folders to get to the important stuff like I did in my Java/RoR days. > The "just use standard library" argument often seems a bit deceptive to me, though. It is absolutely a mantra in the go community. No deception here. > For example, how are you managing schema updates? Use your favorite tool! So funny you mention, I have a RoR background and I loved active-record migration, so I use standalone active record migration https://github.com/thuss/standalone-migrations https://github.com/thuss/standalone-migrations, but you can just as easily use any other schema migration tool like Liquibase. But what I am learning more and more these days is to just write sql. Write your migrations in plain sql. It's always easier for everyone involved. SQL is a ubiquitous language.

RangerScience 9y ago

> every aspect of go's net/http package and database/sql package Nice! That sounds really appealing; I want to learn Go, I just haven't felt like I've identified a problem I want to solve that's best solved in Go. That said, the obvious direction this questioning is going is... Well, but either you're relying on the database and networking magic, or you need to understand the before/beneath of the database and networking; and it keeps recursing down until you get to the point of electrons in silicon, and then the switch is "magic of the scientific method". How do you draw the line of "this magic is fine" and "this magic is not fine"? It sounds like maybe the line isn't "do you know" but rather "what does it take to learn", and that Go makes it easy to learn the before / beneath?

sjellis 9y ago

I suspect that you learned a lot from Rails, though. For example, your applications probably have a thought-out directory structure, you clearly understand how the applications are layered, you probably pay attention to having good names, and think about testing. It is possible to learn good practices without seeing well-structured applications that you can use as "role models", but it's really hard (I know, I had to read how to structure n-tier applications from books, and then apply it to a deficient platform that my employer had standardized on). The "just use standard library" argument often seems a bit deceptive to me, though. For example, how are you managing schema updates?

treehau5 9y ago
> I suspect that you learned a lot from Rails, though. For example, your applications probably have a thought-out directory structure [..] Absolutely, not saying my experience doesn't translate. However directory structure doesn't exist like you think in go. Files are the primary organization, and the only thing that goes in subfolders are different packages. It's actually quite nice, now I don't need to dig into 4-6 folders to get to the important stuff like I did in my Java/RoR days. > The "just use standard library" argument often seems a bit deceptive to me, though. It is absolutely a mantra in the go community. No deception here. > For example, how are you managing schema updates? Use your favorite tool! So funny you mention, I have a RoR background and I loved active-record migration, so I use standalone active record migration https://github.com/thuss/standalone-migrations https://github.com/thuss/standalone-migrations, but you can just as easily use any other schema migration tool like Liquibase. But what I am learning more and more these days is to just write sql. Write your migrations in plain sql. It's always easier for everyone involved. SQL is a ubiquitous language.