Yukihiro Matsumoto: “Ruby is designed for humans, not machines”

> From my perspective, choice of language matters very less compared to the number of experienced programmers you can get at x price.

That's fair. But exactly how much you ought to worry about the hiring landscape depends on your situation. At the beginning of a lot of software projects, there is "you" and "your laptop" and "no money." In these cases you should pick the tool that is going to help you get off the ground fastest. You can worry about the hiring landscape if/when you're lucky enough to get there.

> If I want to write software that is going to be used for a long time, then I am going for strongly typed compiled language that will have certain percentage of developers 10 years later than focusing on how beautiful the language is syntactically or how it reasons well. Binaries are easy to distribute and can still be used after source code is no longer available for odd reasons.

Roughly speaking I agree. However, two comments:

1. This is a very broad critique. You can say exactly the same thing about python, bash, perl, etc. It applies to Ruby, but it's not endemic to Ruby.

2. Not everyone is looking at the same time scale. If you are building software for an enterprise that's been around for a few decades, I can totally see the argument for eg Java. But in many cases, the landscape 10 years from now is the wrong thing to optimize for. For some, building a software product that actually lives long enough to have dependency issues is an amazing problem to have.

> I want to solve problems and reach goals. Syntax doesn't provide enough value on its own in a general programming language.

I could have been more explicit in my original post. What I'm lauding about Ruby is more than pretty syntax. I'm arguing that the the whole language dovetails really well with the application framework, both in terms of routing and in terms of db operations. Particularly the latter. There was a recent thread here that was something like "What should I learn in 2020?" and hands-down the winner was "Learn how to use a DB." I think that Rails is a powerful way to approach this.

I honestly think there's a sweet spot. I have seen brilliant people expertly build massive systems in Java, but there is no doubt in my mind that if they had attempted those in almost any other popular high level language, they would have been more productive. I know I've been very productive in Clojure, for things that I can afford to write in it (performance-wise), and much more productive than I have been in languages I have a lot more experience with.

I think this is the first part of the insight needed.

The second part, which by far the most productive full stack web dev I know has got completely nailed, is that mostly the right answer to that is to push back on the business/requirements with a good alternative to what they _think_ they want that _is_ in "the blessed path".

A good Ruby dev who has the ability/skill/respect to do that is maybe the closest thing I've ever seen to the mythical "10x engineer" on a consistently repeatable basis...

And this goes for other things besides RoR too, I've got a Python/Django guy who can build amazing stuff in weeks, but he'll tell me why I am not getting what I asked for but this other thing that does the same job (sometimes better) because "that's the right way to do it with Django".

As a Rails developer for over 10 years now, I definitely agree that going off the rails (see what I did there?) is nearly always painful. Especially if Rails doesn't totally click for you. I can see why that would drive a lot of people totally nuts.

I think that if Rails really clicks for you then it's possible find a way to solve those problems within the same sort of way of thinking that Rails is coming from. But not everyone works the same way, and that's ok!

> Also as far as the natural-language-like syntax, I find that Swift offers a similar benefit, with the added benefit of strong compile-time checks.

Life is short, if at all possible write code in whatever language makes you happy. If that's Swift for you, well then cheers!

I have never liked the idea of (framework-enforced) CoC.

First of all, RoR isn't as CoC as it claims; many things can be configured, which defeats the purpose entirely, and all that remains is the a CoC philosophy.

If Rails would actually enforce CoC, it'd be too restrictive to build anything new with it, so true framework-enforced CoC is not really viable in the real world.

So what people really mean when they say is "Convention over Configuration" they really just mean that the framework doesn't generate a default configuration, but instead the defaults are all encoded within the framework code and its documentation. This is bad. The only benefit is that an empty project looks less cluttered, but that is really only an aesthetic advantage to draw in new users.

The downside is that the project loses documentation. Ideally, I want to jump into a new project, open a config file and be able to have a look at all of its configurations. In Rails I can't do this; I have to either memorize or look up the defaults and then check if they're changed in the current project.

Ultimately, its idea of CoC makes rails easier for starters to get into, but a total pain for people who don't care to get into it and just want to make some specific change and for anyone with a specific goal in mind that doesn't align neatly with how the framework thinks you should do things.

1. NumPy is really fast and has a lot of features. Even if they don't need all of them they feel more at ease knowing that they can use them should the need arise.

2. Python is very familiar to them, their professors know it, they know it, it's easy to teach to new people in the team so everybody just goes with the flow.

As much as I think the bigger IT area is in a desperate need of innovation... I can actually agree with those two points. Tinkering should be left to us the programmers and sysadmins. Everybody else has a job to do and they cannot and won't spend a lot of time evaluating all tech possibilities.

That's okay. It's our job to tempt them with something irresistible. :)

>It's very capable in terms of making DSLs.

Which is a double edged sword. Too many DSLs means you have to learn and remember a lot more to write code.

After a few different options such as Octave, numerical computation in the free software space coalesced around Python.

The Python ecosystem - it's change and release processes (PIPs etc) - thorough API documentation - make for a good target language, over other languages that simply do not have that infrastructure.

I don't know what the state of Ruby documentation is these days for instance, but back in the day, it was simply incomplete.

ISTM (supporting a system written in Ruby at the time) that a large number of the libraries were broken when used in concert with each other -- and that language experts knew how to monkey patch their way around these issues, but didn't bother documented these fixes.

I've been told that things are much more mature and stable now -- but that experience put me off the language.

I vaguely recall that Python documentation was generally much better at the time, and especially so the parts on writing extension modules. With Ruby, it felt like the English reference docs were largely an afterthought - you pretty much had to get a book on it to get far, and the more advanced sections (like extensibility) were especially lacking.

I worked on 3 smaller projects with Sinatra and Sequel and it was worlds better.

Commercially speaking though, there aren't many Ruby job offers that don't require Rails.

I still occasionally use Ruby when I don't trust bash/zsh with a slightly more complex automation flow but outside of that I find no uses for it.

Elixir and Rust do it all for me these days. I know I am getting biased and I am not fighting it. I need to get jobs done and at certain point always searching for a new tool gets very unproductive, not to mention stressful and soul-draining.

As such, you'd gut large parts of the language if you stopped evaluating code on require.

But, man, the Python import system is so vastly superior to Ruby's "invisible distributed magic" way of handling the same thing.

The sad part is that there is no reason a good language could't have the good parts of both languages. But here we are...

I so much want to agree with you here but I can't. 99% of all business people I've ever met are all about "Alright! We got the perfect idea! Let's have the first iteration done next week!" -- has been the sad reality of most of my bootstrapping conversations. Even if they aren't a young-ish enthusiastic bunch they still are going to go to whoever promises them the fastest delivered MVP.

IMO to this day Rails is a big winner in the MVP area -- although I will immediately agree that nowadays there are no small amount of other technologies that can give you a pretty good-looking and well-working MVP (mostly in JS land I think). But a lot of business people just managed to memorise that Rails is the way to go for MVPs. Their mind isn't easily changed. Now those several whom I talked with in the last 1-2 year were like "yeah yeah, you techies always chase the newest thing" -- and sadly they are often correct. So the hope of breaking free from Rails' "monopoly" on making MVPs looks pretty slim lately, to me at least.

I fully understand the business people's desire for things not to change often. But they vastly overestimate the viability of most of the tech out there. Or maybe it suits their bias. No clue.

Oh please. I like python and use it a lot, but it's readability can be awful.

Constructs like 'delimiter_string'.join( list_var ) may have logic behind them, but the readability for someone accustomed to OOP paradigms is backasswards.

Comprehensions are quite powerful, but ironically they're nearly incomprehensible.

Lambdas are a sad sad attempt at closures/anonymous functions.

There are many conventions in python made early on that have not aged well in regards to readability.

If I had to rank learning difficulty I've found various languages, I'd say Ruby was the easiest one I've ever encountered. It's very consistent, everything is an object, it's flexible and you don't need to learn anywhere near all of it to become productive with it.

Python is fairly beginner-friendly too, but it's less consistent, significant whitespace leads to a certain class of mistakes that are maddening for a beginner and at least when I used it pip was nowhere near as nice to work with as gems and bundler.

Both are much easier than JavaScript or anything where you manage your own memory, though!

I think python had already crossed that bridge, at least for webapps and ml (albeit not at the syntax level). Consider what you must bring in for a real webapps deployment: virtualenv, uwsgi, celery, nginx, at a minimum, probably rabbitmq for many apps. Deployment is a nightmare.

For ml, you'll need to pick your library, version it correctly (some ml models are even firmly stuck in python 2.7), probably manage it all in conda if you are testing different models, since your source is bound to different tensorflow/pytorch/python/cuda version dependencies, and deployment is a nightmare.

Maybe I'm missing some python best practices due to the places I've been (django/angular shops that don't write tests) but ultimately I think this is Not very beginner-friendly at all.

I don't doubt a lot of newer tech solves many lingering problems that are still present in older tech but that's the crux of the issue right there in your comment:

We work for money and we have to get stuff done in acceptable amounts of time. And our bosses want us to write with technologies they can hire for, in case we get fired or killed by a bus.

I can't speak for everyone but now, at 39, I already have a bit of a fatigue and burnout when it comes to trying new languages. I just want to sit down and fix a problem (or create a feature) without having to sift through a forest of competing tech for days or even weeks.

Please note that I am not berating Crystal in any way. I know absolutely nothing about it. I am simply unwilling to invest in learning my (I think) 9th language. Elixir and Rust do me pretty perfectly lately and this is going to be the case for a while.

That was probably ~80% of why I opted out as well (the rest ~20% are mutability and bad parallelism story).

> Feels too much like macros and C++ templates. I just don't want to be that smart.

I don't even view it as being smart. It's more like a specialised area of expertise that you need to grind through in order to be productive, and even when you're an expert it's still error-prone. Turns out though, a lot of other tech doesn't require that so, like you, I moved there.

> I keep going back to Bill Joy's goal of enabling working both in the big and in the small at the same time.

Admirable goal. I try to do the same but it's not an easy thing to achieve. What language would you recommend in this area?

> I could focus more on design and less on wrestling the compiler.

Depends what you mean. I am very okay to fight with Rust's compiler because that way I know I won't have dangling pointers or references and will not inadvertently try to modify the same piece of data from multiple threads. I am also very okay with fighting with OCaml's compiler because I often found myself not thinking properly about the types of my code.

But in C and C++, yeah, there the fight is kind of just "please compile and leave me alone" and it's not that much of "it's compiled, therefore you get guarantees X and Y".

> But I wish language (and stack) designers also removed features. Cull deprecated stuff. More generalizations. Fewer primitives. Fewer classes. Etc.

Absolutely! I wish more language designers/maintainers had the courage to do this. They also don't have to do it in a breaking way; they can just extract the deprecated (and removed) functionality into an optional dependency that people can use if they are so hell-bent on not using the officially sanctioned way from version X.Y and on.

But I guess even that would catch many people by surprise and provoke negative reactions so it's probably a very strong reason on why it isn't being done.

So what's left? A linter that's invoked like this: `idiomatic-rust --check --strict`?

I guess that's the only way out for now.

Oh Hell yes. I wish they have plan for depreciation. Trial, > Warning > Error > Removed. Push the whole language and ecosystem forward. That is 10 times easier then going to a new languages and making new ecosystem.

Do note that in OCaml explicit typing is rarely needed. The compiler is quite amazing at inferring the data types of your functions. In Ruby though, it seems the typing definitions will be the front and center of those suggested interface/header files.

IMO Rails -- and Ruby by extension -- are going through its first really mature phases: a critical look inward and trying to solve problems that the initial enthusiastic wave of adopters haven't found crippling... but many people after them did.

That's a good phenomena and I like it. And I am one of those people thinking that Ruby and Rails both benefited and suffered a lot from the huge popularity burst that they got.

Now is a good time to start making positive changes and to make the language (and the ecosystem) more long-term sustainable and I am glad that Matz is thinking about it.

With some technologies, like Erlang/Elixir, scaling is almost effortless though. Only the deployment platforms with very strict boundaries like Heroku make it pretty much impossible to shard and distribute load. With most VPS-es you just share one file between them, introduce a well-setup VPC, and you're done, your servers are distributing load and you spent like an afternoon on it.

Additionally, with very fast languages like Go and Rust (even Elixir but only on I/O bound projects, which is like most of them?) you delay your scaling measures that far in the future that most apps never even need to grow beyond one app server and one DB server, and the team never actually even thinks about scaling at all. Because let's face it, most apps will never exceed 500x - 5000x reqs/sec. A well-made Phoenix web app or API gateway easily achieves 500 reqs/sec even on a Raspberry Pi 4.

I used Rails for 6 years and deployed it on Heroku, company-rolled Dokku setups, AWS EC2, DigitalOcean droplets and GCP -- usually servers in the range of $25 - $100 per month (I usually work for small or medium-small businesses). I hated that beyond 10-20 reqs/sec we had to start beefing up the server or add others. It's just how Rails (or rather, ActiveRecord) is: very inefficient, optimised for human productivity, and to hell with machine resources. Many business still like it though and that's cool with me. They don't mind a mean response time of 300ms with the minority of responses (95-th percentile) going to 2500+ ms.

> Github, Gitlab, Shopify, Stripe, AirBnb, Crunchbase, Dribbble, Kickstarter, .. etc

I wish for that meme to die. Bigger players using it means absolutely nothing except that they have the budget to keep working with Rails even after it showed its warts (hard to maintain when the project grows and big hosting costs being the top 2).

Smaller players like Basecamp have very stringent policies on how to work with it. I've seen local companies utilise similar techniques mostly successfully. More power to them. I know it can be made to work with the right management techniques.

Half-related: do remember that Facebook preferred to make a PHP runtime and maintain it, as opposed to actually train programmers to use another backend language.

> I'm not sure how many more are needed for this meme to die.

You might call it a meme. I call it "I tried for years and eventually got frustrated and moved on".

Nothing against Ruby or even Rails. But they make me think of scalability much, much earlier compared to a "slow" dynamic language like Elixir (even though it maintains predictable lag even under very heavy load... and its Phoenix framework mean response time in identical setups as the Rails projects is between 5ms to 30ms).

Let's not even introduce Go or Rust web apps in this picture. If made well (although that takes much more effort than Rails or Phoenix so for me their human productivity tradeoffs aren't worth it!) they can easily serve anywhere from 5_000x to 30_000x reqs/sec on the cheap business VPS-es ($25 - $100 a month). In all fairness, those had to use a bit more expensive DB servers though ($250+) because the cheaper DB servers couldn't keep up with the demand.

LOL! Funnily put.

This did offend some in this here mini thread but I indeed gradually -- with business and personal usage -- came to that conclusion by myself.

Nowadays I am pretty hopelessly hooked to Elixir. Parallelism and concurrency basically solved, extremely fast for a dynamic language, FP, compile-time macros (so basically code generation without the boilerplate source code), several very solid and customisable frameworks (web/API/GraphQL, DB data mapper), predictable lag even under extreme load, and I am just in love.

Now only thing left is Rust to emulate the BEAM's runtime. :)

If we were to have a vote for a language with which you replace a slightly more complex bash/zsh scripts however, I'd vote for Ruby. It's very terse, it's fast enough (without Rails I mean) and it mostly reads well. Or I dunno, maybe Tcl/Tk or OCaml.

You could do filter(want, map(school.Lesson, api.downloads()) in Python.

Blocks are not objects. So much for "everything is an object". At least, this is my understanding, I may be wrong?

I'm in the same boat about RoR. I just find its size to be overkill for most uses. Hanami is considerably smaller and lightweight, but not to the point where it's more of a micro-framework (like Roda). I've been happy with it for a number of microservices and some larger websites.

I have pretty much 1:1 the same struggle and it was (is?) starting to knock my confidence - wondering if I’m just a bad developer for not “getting” it.

I often put off development tasks because I know it will all move at a snails pace trying to drudge through endless magic, having no idea where any of it comes from, getting very little back from Google, and giving up.

Dismissing performance concerns because you're designing a language “for humans” is actually glossing over a quite large number of other “humans” (i.e. non-programmers) who do have a stake in the choice, but not so much say in it besides “why is my computer so slow lately”. Well, it's slow because you thought type checking is for know-it-all ivory-tower academics and pedantic asshole compilers, so you chose JavaScript (or whatever “forgiving” language is in vogue these days; the OP is about Ruby, but it doesn't really matter), and so the user has to wait until the JS engine finishes JITting your code over and over again to infer type information that should have been available at compile time in the first place. Rinse and repeat for each app, and now they have to replace their laptop every few years to catch up with ever-growing (for no good reason!) RAM requirements.

Claiming that a programming language is “designed for humans” much too often amounts to saying “my (programmer's) convenience and satisfaction is more important than yours (user's)”. And that is an incredibly arrogant thing to say, as superficially gentle as it may seem at first glance.

I'm not arguing against high-level languages; I'm arguing against disregarding performance in the name of programmer convenience. It's quite possible to design a high-level language in a manner that doesn't stand in the way of making its implementations performant. There are some recent developments on that front.

But if you ignore them, then it's not the “machine's” resources that you're wasting. It's the user's resources.

There's one syntax for half-open ranges and another syntax for closed ranges.

You can index an array any number of different ways: "get me the 5th element". "Get me the element three back from the end". "Get me elements 5 through 8 (inclusive)". "Get me 0 through 6 (exclusive)". "Get me the 3-length subarray starting at index 2".

A hash table returns nil by default when you access a key that isn't stored. But you can change the default value as a property of the table itself. Users now don't need to remember to supply their own default value when they're looking in the hash table. Even more, you can specify a function that gets called when a nonexistent key is accessed, to do whatever is appropriate.

All of those are great things. It's easy to translate your algorithm that says "take a stretch of three elements starting from i" into an access that looks like array[i..i+2]. But the semantics of your algorithm start slipping away as you make adjustments like that. If what you're doing is taking substretches of 3 elements each, there's a gain from being able to express it as array[i, 3], as semantically distinct from taking a substretch between two independent bounds that happen to be i and i+2.

But the flip side of this is that if you're not regularly immersed in the language, it's really easy to lose track of precisely which bit of syntax does what.

“Properties”, in most languages that have them, are an way to make method access look like access to data members (no parens, getters just use the name, setters use name + = with the new value on the right of the = instead of in parameter position.)

You seem to confusing “properties” with “data members” which, it is true, Ruby does not permit external access to except via method calls. But properties are a way of calling methods with a syntax that looks like direct member access, not actual direct member access.

However, I'd say for practical purposes, it still leaves me with the problem that in my day to day coding I'm left with the same ambiguity. I don't know if I'm calling a simple-assignment auto-generated method that is setting a property, or a method that does all sorts of stuff under the hood.

While I'm still fond of Ruby, I've come to prefer less ambiguity. I like to be able to see at the calling site whether what I'm doing is calling a method or setting a property, and parentheses are a great way to signal that.

As an aside, one thing I didn't like about Elixir was that it also made parentheses optional. Once I realized why this was necessary, and once the formatter was added and enforced parentheses as a default, it stopped being a problem. Still, every language I've used where they're optional have caused weird little problems that never seemed to be outweighed by the convenience (CoffeeScript comes to mind).

But all that said, it's not too high on my list of things to hate on :).