7 ms·

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 fo

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?

geodel 9y ago
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.
ovao 9y ago
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 https://github.com/stretchr/testify
rufugee 9y ago
You realize that bundler isn't a part of Ruby, correct? You're comparing apples to oranges.
- LukaD 9y ago
  Does Go have a comparable tool that is as widely adopted as Bundler is?
  - collinvandyck76 9y ago
    It looks like `dep` will be this tool for Go.
- dwaite 9y ago
  FYI, bundler was planned to be integrated into Ruby 2.5, but will now likely be in the following ruby release.
JelteF 9y ago
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 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 https://github.com/GetStream/vg
- jjuel 9y ago
  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.
  - JelteF 9y ago
    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.
dboreham 9y ago
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.
- ozim 9y ago
  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.
didip 9y ago
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.
eikenberry 9y ago
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.
- jdc0589 9y ago
  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)
megaduck 9y ago
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.
jeremiep 9y ago
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.)
dualogy 9y ago
> 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.. =)

geodel 9y ago

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.

ovao 9y ago

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 https://github.com/stretchr/testify

rufugee 9y ago

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

LukaD 9y ago
Does Go have a comparable tool that is as widely adopted as Bundler is?
- collinvandyck76 9y ago
  It looks like `dep` will be this tool for Go.
dwaite 9y ago
FYI, bundler was planned to be integrated into Ruby 2.5, but will now likely be in the following ruby release.

JelteF 9y ago

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 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 https://github.com/GetStream/vg

jjuel 9y ago
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.
- JelteF 9y ago
  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.

dboreham 9y ago

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.

ozim 9y ago
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.

didip 9y ago

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.

eikenberry 9y ago

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.

jdc0589 9y ago
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)

megaduck 9y ago

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.

jeremiep 9y ago

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.)

dualogy 9y ago

> 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.. =)