Comparing a trivial <500 LoC program between languages doesn't tell you anything that's useful other than the terseness of the syntax. You might as well chain unix utilities together at that point.

Maintaining a 5k+ LoC java/c#/go/rust/crystal codebase is orders of magnitude simpler than standard ruby. Sorbet/RBS bridge that gap now, but are a pita to use compared to natively implementing a type system. I know with rust/go I get a simple binary at the end to copy over. Rust, unfortunately, has slow compilation times still compared to go, but I really can't stand error handling in go compared to rust.

That said, "ruthlessly productive" is an apt description. I just don't want to have to maintain a large rails codebase again without sorbet/rbs. I'm hoping phoenix/elixir or something in rust catches on.

That 5k line Java codebase is probably equivalent to the 500 line Ruby one. ;)

Yeah not really, for maintainability, I'll pick Ruby over Java any day. I've seen how the large java project tend to be and I want no part of that.

Is Ruby "ruthlessly productive" for building a fast, highly concurrent program that can be deployed to X platforms with minimal fuss? No.

Is Golang "ruthlessly productive" for interfacing with complex relational databases? No, not even with generics.

Tradeoffs, every language has 'em.

What mainstream programming language is good for interfacing with complex relational databases?

Rust is getting there, with sqlx[0] you can write plain sql and it gets validated at compile time.

[0]https://github.com/launchbadge/sqlx

Any language with metaprogramming like operator overloading so you can create an ergonomic ORM, basically.

For such a language to be reasonably productive you want to be able to overload "mystruct.myvar" to not simply grab "myvar" from memory, but smartly fetch it from a remote database, cache it, etc.

It will never be perfect (blah blah impedence mismatch) but a proper ORM is so much more productive and readable than writing crap like `Manager(mystruct).GetAttr("myvar")...` or bespoke SQL composition.

Elixir is great at it and becoming increasingly mainstream.

SQL. Typescript with library like pgtyped basically allows you to write raw SQL queries and then generates all the static typings for them.

F# by way of type providers. Many other languages could similarly bridge the gap with codegen.

> Is Golang "ruthlessly productive" for interfacing with complex relational databases?

neither is ruby lol.

> Ruby is just ruthlessly productive.

This is the best description of Ruby I've ever read.

+1. After working on Elixir for a long time I missed the simple ruby way to do things and found myself running in circles to troubleshoot some basic 3rd party libraries. Going back to Ruby for my next side project.

Having used both Ruby and Elixir, this is exact opposite of my experience. I would say Elixir/Erlang is one of the best language from observability/debugging perspective. Immutability, per process heap, ability to trace any module/function call in production (recon), remote shell etc make it trivial to debug most of the issues. I have found memory leak in production from 3rd party library in less than 30 minutes. Just looking at the process list sorted by memory will tell which library is leaking (in majority of the cases), as most of the processes has single purpose.

Strange. I like Ruby, but probably the biggest gain I got from moving to Elixir was the comparative ease of debugging.

Its immutability drastically reduces the search space.

Agree with your point about debugging being easier but in my case I ended up doing a lot of housekeeping for things that are easy in ruby. This time I'm only concerned about the speed of development and ruby to me is the winner

> Ruby is just ruthlessly productive.

Not disagreeing, but the nuance is productive for writing new code/features. It really feels counter productive once you have a large codebase/team and you need to refactor existing apps.

Spent 5 years at a Rails shop and it's crazy how much engineering effort was spent on keeping this app going. Adding typing seems like a nice step to help here.

Yeah, I disagree with "ruthlessly productive" as a blanket statement because of this. I tend to find that a huge chunk of the time I save at write-time in Ruby (Rails)/Python/etc., I end up repaying at either runtime (nil exceptions) or read/explain-to-other-dev/refactor times, sometimes in multiplicative form (chasing down why something became nil, or a string, or an elephant, but only if the ORM did X, Y, and Z to the DB response, etc. gets ridiculous quickly)

Well, the go one would compile to an easily deployable binary and actually be able to, you know, count a whole lot of words quickly. But the ruby one is much more terse and quicker to write.

I say we go back to awk and get the best of both worlds:

  '{num+=NF} END{print num+0}'

Ironically half that code (END...) is valid Ruby!

> Hoping new age compiled languages like Crystal & Nim fill the gap of performance, types & productivity.

Yes, go is verbose at times. But the go language server for example lets you not write a lot of the boiler plate you see there.

E.g. instead of typing out a for loop, i'd just (start) typing `foo.range!`, or for sorting `foo.sort!`.

I'm not going to argue that writing it in go even with those would be more terse, just that I think it looks worse than it is.

Yeah the go one looks terrible but then you take a look at it and it's just creating slices, looping over stuff and appending stuff to the aforementioned slices. The syntax is much less expressive, therefore very verbose, but it's basically doing the same thing, without the sugar of being able to inline some of the logic.

The Perl solution would be significantly smaller tho.

I dont know if toy examples prove anything about productivity. I never quite understood what makes Ruby more productive. Dynamic types?

I think is that is has a great standard library + with rails a lot of utilities out of the box, other than that some people just like the syntax.

So said that they standard library is huge, where other languages prefer to have slimmer ones and let the community build the utilities.

Principle of least surprise.