Hacker News Reader

> But I never found good use of it outside of small projects. Any serious business work becomes very painful to maintain and stay on top of for bigger projects.

It's the ultimate irony reading statement like these, when ruby powers some of the largest web applications on the web today and handling millions of users and requests.

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

I'm not sure how many more are needed for this meme to die. Is ruby perfect? absolutely not, but to neither is any other language. You will always have to tweak things regardless of the tool you chose, because scaling is difficult.

> You will always have to tweak things regardless of the tool you chose, because scaling is difficult.

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.

> It's readable...

when you start to learn a new programming language, you look up what people are doing. ruby let programmers write incomprehensible and unfriendly code. my experience is that it has been a huge turn off for beginners. there was a rush to make popular websites in the rails era, but that ended quickly.

as another example, cpp used to be a cool language to read and write in. they even taught it as first programming language. since then, they added some crazy stuff that made the language very unfriendly when put in the hands of some people. it is now very beginner unfriendly.

the syntax of python will remain a great inspiration for readability if they don't make the same mistakes. it always amazes me to see people from all levels read python the first time and get it.

> there was a rush to make popular websites in the rails era, but that ended quickly.

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.

>the syntax of python will remain a great inspiration for readability if they don't make the same mistakes. it always amazes me to see people from all levels read python the first time and get it.

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.

In my experience with Python, these were minor annoyances. The real problem was the amount of decorators and monkey patching in libraries like Flask, FoundationDB, Gunicorn, or Celery. Using gevent didn’t help...

I found Ruby a bit easier to read and much easier to learn than Python as a beginner. In fact, I'd say it's the most beginner-friendly language I've seen, especially with great resources like Chris Pine's Learn to Program.

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!

> the syntax of python will remain a great inspiration for readability if they don't make the same mistakes... it always amazes me to see people from all levels read python the first time and get it.

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 think the parent was speaking specifically about the language, not the ecosystem. More "if I open up this Python file, can I understand what it's doing," not "can I execute this application easily." I think Python is excellent at the former—Syntax is simple and explicit, "clever" code is discourages by both the language and the community.

Packaging is a known pain-point in Python and does make the language less approachable. But beyond that I don't understand your criticisms. uwsgi, celery, nginx, RabbitMQ are all useful tools that are oftentimes used in web applications. What language are you using that magics away the need for tools like these? All these same tools or their equivalent still exist in the Rails ecosystem.

I don't have much hands on experience with ML, so I guess I can't comment on that. Is there something about Python that exacerbates the issues you've laid out?

Eixir/Phoenix at least makes those dependencies go away, but some use nginx (I have) and you might use rabbitmq but only if you want to run a queue that other languages participate in.

We must be reading different versions of Python as the magic double underscore, weird bolted on OOP is in my opinion a lot more unreadable than some code golf rubiest go for.

Ruby could use a proper module system as well. Ruby's require evaluates Ruby code and changes global interpreter state. Python's modules are so much better. Javascript's require is so simple: a function that returns a module object.

As someone who codes in Ruby daily this is my by far biggest issue. Ruby's performance is pretty good (I do not use Rails or ActiveRecord) and while the state of concurrency is not ideal it is not really an issue in practice for me, but the lack of a proper module system forces me to invent unnecessarily long and convoluted names.

That would be a very jarring change. Ruby class definitions are executed to define a class. There is no way to statically define a class in Ruby. This is frequently used. E.g lots of Ruby libraries add class methods that are executed during the definition of a class to mutate it during definition. This is Ruby's alternative to macros.

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

Yep, but that's a post factum worry. It's not an inherent trait of being a dynamic language that automatically surfaces during its development. Ruby's creator(s) simply chose to do it like that and now, of course, it's too late to do any sort of revolutionary changes.

Hi btw! Just now noticed it's you. :) Was thinking to write you an e-mail very soon. Which one do you prefer?

Yes, of course it could have been done differently from the start, but as you say it's now impossible to change. Though my Ruby compiler project (that seems like it will take the rest of my life at this point...) would have been far easier if it was more static. That said, I think it's less of a problem in practice - most code does things that can be fairly easily statically determined and/or that isn't actually doing anything particularly nefarious to other classes. A lot of the worst abuses that are possible with Ruby are also things I've never seen done intentionally in the wild other than as examples, and where deprecating and explicitly breaking them wouldn't do any harm.

> Hi btw! Just now noticed it's you. :) Was thinking to write you an e-mail very soon. Which one do you prefer?

Sure :) Same old e-mails (also on my HN profile page).

Isn't the real problem that Ruby's "magic" a lot of the time relies on monkey-patching stuff?

I mean, Javascript's modules also are dynamically executed and then returned as a singleton module object (also cached, so only the first require actually runs the code before the module export). This means you can make a module which requires other modules and monkey patches methods inside them (this is how mocking actually works), wrecking havoc amongst all other dependencies, but library authors just don't.

The more in-your-face monkey-patching went out of favour many years ago. Most newer Ruby libraries make you explicitly "opt in" to changes by e.g. including a module and/or contain any monkey-patching in separate files that needs to be explicitly require'd if you want that behavior. It's rarely a problem in practice.

The code evaluation is not the problem. The fact all evaluation takes place in a single global interpreter context is the problem. When a file that defines a class A is required, the A constant of the Object class gets set to a new instance of Class:

  # a.rb
  class A
  end

  # irb
  require 'a'

  Object::A.new

All code evaluation modifies global interpreter state. Honestly it's not much better than the C preprocessor's #include directive.

A better design: files are always evaluated with a clean interpreter state and they can return values just like methods.

  # a.rb
  class A
  end

  A

  # irb
  a = require 'a'

  a.new

This makes all state local to each script by default. Users will only have access to the returned value which can contain anything or nothing. If a module needs to modify existing classes, they could return modules that can be mixed in or metaprogramming methods that perform the modifications when called with the targeted class as parameter. Perhaps existing classes could even be passed as parameter:

  require 'extensions', Object, Kernel

Of course, these changes would break compatibility with all existing gems. The result would be a completely different language that happens to also be called Ruby.

Most of the code that changes global interpreter state does so in predictable ways that are perfectly fine, so I don't think what you're suggesting would actually make much change.

Most modern Ruby code avoids monkey-patching "unasked" unless that is an explicit purpose of the project and using the gem is explicitly "asking for it" in the first place. Providing modules to include or making you explicitly call methods or explicitly require files documented to do optional monkey-patching has been the idiomatic way of handling it for years.

Adding the ability to explicitly provide guarantees that the required code is sandboxed might be useful and might particularly help tooling reason better about the code, but it would have quite little practical effect on most modern Ruby.

Yeah, having gone from Ruby to Python, it's a downgrade in most ways. Clumsy, ugly language.

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

> having gone from Ruby to Python, it's a downgrade in most ways. Clumsy, ugly language.

Python 3 is a much better language than Python 2. More consistent and much better designed.

I miss the Ruby standard library though. All those string, array and hash methods make things so easy. I often get stuck looking for Python equivalents.

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

There is: backwards compatibility. Most of the time it's impossible to fix a language because the result would be two different languages that have the same name. Python broke compatibility with version 3 and it is still competing with version 2 to this day. Ruby also did the same thing in version 1.9 but thankfully the scale was much smaller.

Doesn’t Python’s `import` evaluate code in the same way as Ruby’s `require`?

I think so, here is the article about it:

https://www.benkuhn.net/importtime

Good points.

Personally, it's a bit puzzling to me why the ML community ran with Python and why there isn't a popular alternative for Ruby. It's very capable in terms of making DSLs.

My hunch is that the number-crunching libraries were better in Python (numpy etc).

I spoke with several data scientists and students in the last 2 years and the consensus was basically two central points:

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

But those are reasons that are valid afterwards. Why weren't the good numerical libraries developed for Ruby?

Maybe the watershed moment was when MIT switched from Scheme to Python? I don't know.

Really good question. And I have no clue.

But I believe (can't prove) that you are correct on the outset: some big org switched, then a lot of people went like "oh well, Org X can't be wrong", and the rest is history.

This isn't how I remember it. I remember that prior to the scientific python stack, you had to pay for Matlab or mathmatica licenses. The scientific python stack meant that for essentially free, you no longer had to justify licenses at any financial or educational institutions. You could just load up your code and run it against your data. In academia this meant that every student could do their homework on their desktop or laptop (if they were motivated). Even in financial companies, the decision was often made to limit the number of licenses - and in most cases they weren't used to actually run production jobs. Quants had to translate their work to another language with the help of their developers.

With the scientific python stack you entered a new world with unlimited seats, you could at least try to run the same experimental/exploratory code with minimal changes in a production environment, etc.

So in short it didn't need some tentpole user/customer/exemplar. In almost any situation it was free and it started making money as soon as it was downloaded installed and run.

Well, I believe that the native memory model of Python is relatively welcoming to just doing your own thing, but also Python just got there first: NumPy was first released the same year as Ruby on Rails. So Western developers were discovering Ruby while Python was merging two existing scientific programming projects.

My recollection is that Perl had numerical libraries that were crash-prone, and in at least the finance company where I worked that was the backbone for some models for a while. In the early-mid 2000s numpy/scipy got a lot of commercial support, and as I recall the ffi support for this was broader and more unified than anything else - the unifying idea of the numpy array and the ability to load it with data and pass it to everything in the ecosystem just made it work.

At the same time, I saw no substantial interest in persuing the same dedicated effort at the same scale in any other ecosystem. Rails was what everyone did in Ruby (aside: recalling that the ffi changed between 1.x and 2.x and it wasn't a trivial API change, and how the only documentation seemed to be the code, would have broken any prior work... I can't imagine putting long-term effort in this direction), java and jvm hosted languages didn't seem to gain any traction from users for these problem spaces (maybe the inability to easily dynamically allocate more heap on demand in user code made this unfeasible?)

Looking back I think the fact that numerical work has found success being built on a huge foundation of stable libraries that are glued into a dynamic interpreted language and which is then often treated as a finished artifact, I can't think of another major language that is more appropriate than python.

Specifically relative to Ruby: at its core Ruby is matz's place to experiment about ideas in programming languages. If you are going to build your business around a few million lines of glue code that relies on the internals of a language, you want to have strong guarantees about the stability of what you're building on.

Looking back I think the python 2 to 3 transition period actually made this better for python by providing a very stable foundation in python2 while experiments and destabilizing changes were mostly pushed to 3, which kept ahead. When finally transitioning to 3, the needs of the scientific python community and ecosystem were so well known and represented that it was unlikely to simply get forgotten, left out, or left behind.

Pretty good analysis and recollection. Thank you.

Ruby was relatively unknown until Rails made it popular. Python had a head start.

Numpy was working fine and effectively for a long time, ruby had narray but it wasn't as good (less documentation and such). Then scipy was the same. Then pandas etc etc.

Looking at Tiobe, in the early 2000s Python was a lot more popular than Ruby although neither was very popular. Then RoR took off but that only made Ruby on parity with Python as Python's popularity was also growing. Or in other words, 90% of Ruby talk became about RoR while Python wasn't. If you're making a quick local program or library, would you pick the language where people only seem to do web dev or one that seems to have broader adoption?

edit: Which lines up with my recollection, Ruby was synonymous with Rails and web dev while Python wasn't type cast yet.

Ultimately, it's probably that Python is older and it's use in the English-speaking world is substantially older. Python is around 5 years older than Ruby and the first book about Ruby in English came 10 years after Python existed.

It's 1995. Python has been around for 5 years. Guido is working with the scientific community and adding better complex number, array, and matrix support to Python. Ruby has just started and everything is in Japanese. Scientists and Engineers at US universities and FFRDCs (Federally Funded R&D Centers) keep plugging away at Python for scientific purposes. Finally in late 2000, the first book about Ruby is published in English. Ruby is still pretty unknown. In 2005 Rails hits the scene and the English-speaking world notices Ruby. But this is 10 years after the scientific community starts investing in Python and 15 years after the Python language came out. By this time, the community had Numeric, numarray, and finally NumPy to unify their efforts.

Ultimately, Python's BDFL started working with the scientific/numeric community before Ruby existed. It would be 10-15 years after Python that Ruby would start making inroads in the English-speaking world and by that time there was already good numeric/scientific tools in Python. Scientific communities weren't looking to learn new languages for the sake of new languages. Many still just use MATLAB.

MIT hadn't switched to Python when a lot of this happened. I think it's more that Ruby wasn't widely known to exist until 2005 and was "brand new" to the English-speaking world then. Python had been plugging away at numerical libraries for a decade by then and NumPy (which had learned from previous numeric/scientific libraries) came out basically when Rails came out.

Once all these numeric libraries exist for Python, are you getting grad students excited to work on an open-source numeric system for Ruby? Are you getting FFRDCs interested in creating libraries for a language that's quite similar to Python without any significant advantage? How do you justify that work? How do you get people excited about it when the reaction of most users is going to be "we're already happy with what we've got"?

Rails burst onto the scene at a time when people were often unhappy with their tools. Rails was a breath of fresh air with clean separation of concerns and a lot of helpful stuff. This is back when Java meant XML sit-ups, C# was closed-source and this is before most of what the community knows today existed, Scala had just appeared, Python was still in the Plone/Zope era (remember when an object DB in Python seemed good?), PHP was pretty dominant but often ended up a mess and didn't have the same framework that Rails was offering. Rails offered something compelling and new which meant attention. Many other communities followed Rails - Django, .NET MVC, JAX-RS, etc. Still, Rails was there first and got a lot of mind-share.

Similarly, Python was there first in scientific/numeric computing and people haven't provided enough to compel people to move off it.

I love reading historical context around language use like this. Thanks for sharing.

Quite interesting, thank you!

I remember Python being fairly popular for quick work in research 10+ years ago. It was simple and easy to start with but not that different from the c/c++ which they needed for performant bits.

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

Numerical computation is generally done on scripting platforms - Matlab for instance.

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.

One reason I can think of is, certainly early in the Ruby/rails days it was quite difficult to support/install ruby on Windows. Python was much easier to install and get going with so it maybe got a foothold just because more people had access to it.

Another reason is that in the timeframe where people might conceivably written these, ruby was going through the 1.X->2 transition with all the pain that entailed.

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.

These are pretty normal growing pains and one should ascertain for themselves if they are willing to shoulder the risk of using an emerging technology. That being said, some of the "break stuff and monkey patch later" mentality is still in the community's DNA.

I am not trash-talking that phenomena but I also found it off-putting and eventually moved away from Ruby/Rails after 6 years with them.

I remember looking at both Python and Ruby when I was getting into dynamic languages - this was the time when Rails just showed up, and Ruby was suddenly getting a lot of attention.

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.

"...too much magic and implied behaviour..."

This is why I opted out of Ruby. Feels too much like macros and C++ templates. I just don't want to be that smart.

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

Mid 90s, Java was logical step from C-ish towards Scheme-ish and Simula-ish (SmallTalk, Self). I could focus more on design and less on wrestling the compiler. Much progress since then, in Java and elsewhere.

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

> This is why I opted out of Ruby.

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.

"What language would you recommend in this area?"

I wish I knew.

For ages, I've imagined a Java do-over I code named Encore. What would "Java" look like today, given the same original goals of improving programmer productivity and reducing errors.

But now I've switched tacts almost completely.

TLDR: Code generation 2.0. Code you'd write yourself, if only you had more time.

So with SQL, for example, instead of a wrapper or model which generates SQL at runtime, start with the SQL and generate code (in your target language) at compile time.

I've done this, with varying degrees, for SQL, HTML, HTTP, HL7, DICOM. Just trying to flesh out the idea, strategy.

One consequence is the target language becomes much less important. So now I feel (hunch, as in "believe but cannot yet prove") that the smaller the language, the better. Like BASIC, Pascal, Lua (which I don't particularly like) small. Barely more than a scripting language with some objectness and modules.

And even more impactful, the contemporary libraries and frameworks become much less important, or even moot.

Thanks for replying. I'll post something if my efforts mature enough for sharing.

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

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.

> He regrets not focusing on immutability primitives earlier.

Hah, I think every business-first (as opposed to academic-first) language had this problem.

Immutables are easy to implement in every OOP language but the if standard library isn't aware of them out-of-the-box you're SOL.

Never tried to make a programming language myself but what you say is interesting. I wonder if this mentality (mutable-first) can be changed at least in universities?

The global variables is generally mitigated by RoR but that leads right into one of his primary regrets that it's not used for something other than Web.

I'm sad to hear that he's sad about that because to me I love Ruby/Rails for the web. It's just too strong for getting off the ground for me to ignore. The community has solved so many problems that allow me to focus on business/user issues.

Not having static typing is that double edge sword. I personally wish it had it now as well having been with Ruby for 5+ years seriously. I've played with Sorbet, but in the Rails world, it's just too weak to be useful. Too many exceptions/untyped definitions to allow everything to play nice. It's the standard problem of trying to make an un-typed project => typed.

With all his gripes, the frameworks he laid down -> human readable + everyone be nice to each other has been incredible. The 1st one is controllable, but the 2nd relies solely on other people carrying it forward. Issues, forums, meet ups, conferences. It's not perfect by any stretch, still lots of issues, but it's incredible to see that the community does try and is relatively successful at it.

Even though I moved on from Rails ~3 years ago I am not spiteful of it -- I just came to realise it's just not for me. I am really glad the community is still going strong.

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.

> But I never found good use of it outside of small projects. Any serious business work becomes very painful to maintain and stay on top of for bigger projects.

That statement reminds me a lot of the conclusion I came to on a reddit post[1] a while ago, where I compared Rubys fibers¹ to Luas coroutines, more specifically, how many of them could viably be used concurrently:

> Conclusion: Ruby is awesome; just don't use it for anything serious.

¹ Note that after Ruby 2.7 was recently released with a supposedly improved coroutine implementation, I repeated the benchmark and did see a slight improvement in execution time (no change in the maximum number of coroutines), but it was still orders of magnitude slower than even the PUC Rio implementation of Lua.

[1] https://www.reddit.com/r/lua/comments/cgqfch/lua_coroutines_...

> Conclusion: Ruby is awesome; just don't use it for anything serious.

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.

> - He seems a bit disappointed that Ruby is mostly used for web development only and would be happy if it was used in research and AI.

Flowstone ( http://www.dsprobotics.com/flowstone.html ) uses Ruby for scripting, so there is a bit more to Ruby than webdev.

Most of what you mentioned seems to be fixed by Crystal. That said I am not sure when Crystal becomes production ready or 1.0.

Not saying Crystal will be the silver bullet, as it will take at least one or two years writing a large codebase with it before we can make any decent judgement.

> That said I am not sure when Crystal becomes production ready or 1.0.

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.

> is now working on an optional typing system where you choose to describe types in a separate file. (Reminds me of C/C++ and OCaml header files.)

My experience using C/C++ is limited, but this always feel felt rather cumbersome to me.

In C/C++ it definitely is. But it sounds Matz wants to do it similarly (but not exactly) like in OCaml, where the "interface" file only describes all public modules and functions and their typing signatures, which serves the purpose of (a) limiting access to the users of your modules/functions to only those you want to expose and (b) help the compiler's typing system.

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.

> too much magic and implied behaviour

I think you may be confusing RoR with just Ruby.

Rails is its own beast.

I didn't confuse anything. I specifically mentioned Rails before listing those drawbacks you quoted.

I didn’t really work in Ruby during those times, but I do today. I like it, I find it a very “plain” language to work in. I mean plain in the beneficial sense, Ruby makes it easy to write boring code. It has too many bells and whistles, such as all the OOP doodads, but I try to avoid those and just write functions.

I don’t really find it magical, though if I spent much time working in Rails I probably would. But, there is Ruby without Rails. I recommend it, in fact.

As you yourself found out, writing in Rails is very different. You can go crazy with all the things happening without your knowledge. I liked the productivity that Rails gave me back then but it very often felt like that the expertise you get is the result of a series of traumas (a lot of "Why the hell did this thing change 0.5 secs later?! I didn't tell it to do that!").

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.

How do Elixir or Rust help you with front-end/UI? It seems you would need at least Javascript and maybe more if you're going to produce mobile apps.

Elixir has LiveView, which can eliminate 90% of your JS by simply offloading frontend computations to the backend and utilising WebSockets streams to do it. It's pretty neat.

Rust, AFAIK, doesn't.

But you are right of course, if you want to cover the full-stack then JS is mandatory.

Hi draw_down, I believe you are shadowbanned on HN. Just thought you'd like to know.