Comment by Carpetsmoker | Hacker News Reader

Comment by Carpetsmoker | Hacker News Reader

Parent Full thread

I've been using a lot of Go to write web applications the last three years, and I find it's a very smooth experience.

I don't have a hate-on for Ruby on Rails; my last job was as a Rails dev and I liked it. I still like, even though I haven't used it in a while (simply because I have no need). It also definitely has some advantages over Go.

But Go offers some great advantages: type safety; still fairly productive; boring understandable Just Works™-kind of language, and has most required components in stdlib (you need a few external dependencies, but not many, although how many depends a bit on your approach as well).

The biggest downside is that there's no standard web framework, and that a lot of Go devs seem to eschew them, too. There are some good reasons for that in some contexts (RoR is not a solution for everything either, that's why Sinatra exists), but it has the effect that a lot of organisations crank out their own internal semi-frameworks. Basically it's Greenspun's tenth rule.

Go-buffalo is probably the closest thing to Go, but I haven't had the opportunity to check it out in depth yet. There is also Revel, but that has some unfortunate design decisions IMHO, and isn't something I would recommend.

Is Go a complete drop-in replacement for all RoR use cases? No; not yet anyway. But I think it is for a lot of cases.

>I've been using a lot of Go to write web applications the last three years...

> ... The biggest downside is that there's no standard web framework

I hate to say it, but this why I feel justified in earning 50% higher pay than the younger devs on my team who are more passionate, more ambitious, faster, and put in more hours, yet always want to rewrite the boring web code in whatever is the new cool language of the year.

I mean if you feel it's worth it to stay late and work weekends in order to reinvent the same old boring code to deal with marshaling HTTP to types, process forms render templates and Json, etc - precisely the things that were mature and battle tested in dozens of other frameworks years ago - I guess that's fine if at least you're learning why it's such a bad idea (unless your job is to wrote such a framework instead of actual business requirements).

But your managers and especially your customers could care less that you did so.

I never advocated rewriting anything. If you have a RoR/Django/PHP/Java app and it works well: keep on truckin'!

But I've also found that writing new applications in Go has some good benefits over e.g. RoR. Things like processing forms and whatnot is all in the standard Go library. No need to reinvent anything.

I understand some people feel frustrated with "new tech of the yeah, yawn" (JS frameworks being the canonical example), but I don't think that standing still is a good option either. There is probably some reasonable middle ground.

How's testing in go? What about unit tests when you want to hit the database, do you wrap that in transactions?

Check out https://gobuffalo.io/en/docs/testing/

Coming from a rails background, this was the closest out of the box testing experience. Tests are generally handled within a transaction and also offer fixtures and other goodies. Definitely recommend giving it a test drive.

Not quite sure what you are looking for but Go was one of the first languages about 7-8 years ago that had unit testing, benchmarking and code coverage built into the standard library and tooling.

The unique implementation of automatically satisfied Interfaces and first class functions (ie. easy to inject dependency) in particular makes testing very easy and designing code using these abstractions for testability also improves modularity.

For database, generally you just use the standard library to access and well tested database drivers provide the actual access mechanics. So if you want you can actually decouple tests checking the business logic side of database (eg. instantiate and hit an in-memory dB locally during testing - or even use a completely different driver if you're not using a weird "flavor" of SQL) from actual connectivity testing (where you wrap things into a transaction in a real mirror dB)

here is some code from various Go codebases I work on. I had to anonymize some stuff because it's work related and the indentation is all borked, but this is the gist. I tend to wrap things like this up in closures. I almost completely use the go stdlib. In case you were curious.

https://gist.github.com/kyleterry/55468cb4ff9ce2e9f0156491c4...

Yeah; I use https://github.com/DATA-DOG/go-txdb

Works pretty well.

I like go but there is nothing like RoR

You may want to try Phoenix

I believe that is elixir :)

Reply on news.ycombinator.com