Hacker News Reader

Comment by Dirlewanger | Hacker News Reader

This is coming from a comparatively spoiled Rails developer, but: why would anyone bother using a language in production if it lacks fundamental things taken for granted like dependency management and stable testing frameworks/practices? Do people just not do enough due diligence and get blinded by a language's honeymoon period?

View on HN

While Go’s dependency management story isn’t an encouraging one, from a testing perspective I personally have few complaints with Go. Mocking with interfaces is straightforward, and despite the basic testing package, I find it quite easy and straightforward to both write and run Go tests — a testing “framework” is not required.

I do generally use the testify assert package for convenience[0], but it’s not strictly necessary.

[0]: https://github.com/stretchr/testify

Dep (which is very similar to bundler) really solves most of the problems with Go dependency management and is the official tool everyone is converging to now: https://github.com/golang/dep

For the problems it doesn't solve I've created virtualgo at my job, which is similar to rvm or virtualenv: https://github.com/GetStream/vg

I just discovered VG yesterday. I am super excited to really try it out. That is what I loved about Python was Virtualenv and not having to install packages globally. So I am really looking forward to trying VG out.

Always nice to hear :). Be sure to report any issues you have on GitHub btw, the setup and usage should be as painless as possible.

> why would anyone bother using a language in production if it lacks fundamental things taken for granted like dependency management and stable testing frameworks/practices?

That one's easy. Go is a brilliant low-level language. You hack on servers, tooling, IPC, batch pipelines, etc. Nothing that people endlessly keep pondering about, from "deps" to generics to gopath to "practices", really hinders the enthusiastic hacker much from just getting busy with it, and producing. A Go coder doesn't envy the "spoiled Rails developer" because he feels blessed by a low-level systems language that actually has prim types other than int, sane pointers, concurrency primitives, utf8, heck simply strings to begin with, fast compilation times, no header-includes mess, etc.. =)

I've worked with Eno (the OP) on the product that he's talking about (Cloud Foundry). It's worth noting that the first versions of Cloud Foundry were written in Ruby/Sinatra for the reasons that you're talking about.

We switched to Go because Ruby's concurrency model was obtuse/inefficient and scaling the codebase was challenging even with excellent developers and great engineering practices. The performance gains with Go were a really nice bonus.

If you're solving Google-style problems like writing a PAAS, then the benefits of Go outweigh the headaches. If you're writing a more straightforward CRUD-style Web API, then Rails might be a better choice.

To provide a historical context, once upon a time, Ruby and Rails community didn't have Bundler.

But that didn't stop early adopters to build libraries and push Rails to where it is right now.

The very same could be said of Rails. I for one absolutely hated working in Ruby and especially Rails because I'm incredibly spoiled from Clojure. Why would anyone bother using a language without live coding that has tons of syntax issues, a braindead ORM, inconsistent conventions, extremely noisy documentation, where most devs care more about pretty superficial things than actual simplicity and composition. Do people just not do enough due diligence and get blinded by a language/framework's honeymoon period?

(I don't mean to bash Ruby, just trying to put your argument in a different perspective.)

You realize that bundler isn't a part of Ruby, correct? You're comparing apples to oranges.

FYI, bundler was planned to be integrated into Ruby 2.5, but will now likely be in the following ruby release.

Does Go have a comparable tool that is as widely adopted as Bundler is?

It looks like `dep` will be this tool for Go.

While dependency management is still an ongoing pain, it is miles ahead of Rails just for the fact that they are compile time dependencies. Last time I was responsible for deploying a Rails app the standard deployment method was to pull and build the gems on the production system as part of the deployment. Before Docker solved this I always thought of dependency management as one of Ruby/Rails weaker points.

mocking with interfaces is so straightforward, it just kind of happens without much thought if it something you are used to in other languages. The first thing I did in my very first go project was mock the repository/DB tier out so I could learn go without focusing on learning a new DB at the same time (I was using dynamo for something ultimately)

Different perspective:

Often these things are done in a half-assed way that isn't well suited to production deployments (e.g. not secure, requires connections to random hosts on the Internet from production boxes).

"Testing" means many things to many people in the context of many different kids of software. Defining a fixed framework for same can be detrimental to some proportion of that space.

I can not imagine deploy to production where you pull dependencies on production box. You build it on build server or locally and then deploy compiled/bundled system.

But still starting project where you can pull dependencies for development with dependency manager and setup first thing in let's say 25% faster, I'd choose that.

For testing I would agree framework is not a must have.

Some applications require a higher efficiency in terms of resource usage e.g RAM, CPU etc. Go solution is better in that scenario. Cloud software vendor would use more efficient language especially if that application is not directly billable to customers.

Reply on news.ycombinator.com