IMHO the answer is that Rust, C++ and Haskell are out there and anybody can use them to build a web site. Maybe the real question is why there are developers the prefer coding in Ruby. In my case, I barely used C++ in the mid 90s and only read some examples of Rust and Haskell. I can't really tell anything about Haskell. Rust and C++ look too hard to use, I don't want to care anymore about all that micromanagement stuff. I'm really with Matz on this. I'm not with him on making types more prominent in Ruby. They are also micromanagement and I don't plan to use those new features. There are plenty of languages with that kind of typing, there is no need to have another one.
Actually I'm doing most of my money with Elixir and Python now. Elixir is nice except for deployment, like all the compiled languages I know. Python is much like Ruby but with weird design choices. Oh well, I guess that people coming from Python could say that the weird one is Ruby.
> I'm not with him on making types more prominent in Ruby. They are also micromanagement and I don't plan to use those new features
I agree with the general argument, except this - keep in mind that typing in Ruby is optional (and will always be).
So devs who choose not to use it, they won't suffer any downside. There are also middle grounds - typing can be added gradually or locally.
Keep in mind though, that as projects grow large, handling dynamic languages becomes more and more challenging, and adding types is a good strategy to handle that.
This will change over time. There are already several companies using Crystal in projects. As they say, typically, it doesn't take many changes to migrate Ruby code to Crystal.
"It doesn't take many changes" unless you're using Ruby for the things Ruby is good at: dynamic generation and metaprogramming. If you're not, you can port to anything and it'll be roughly equivalent and having a static language in Ruby's clothes doesn't scratch much of an itch.
TBH, having evaluated it, I don't see a great argument for using Crystal in 2020 unless the criterion is "I want to use Crystal." Which is defensible, if that's how you want to roll, but it doesn't make for a good porting argument.
> If you're not, you can port to anything and it'll be roughly equivalent and having a static language in Ruby's clothes doesn't scratch much of an itch.
> I don't see a great argument for using Crystal in 2020
There is still the Ruby-like syntax appreciated by many developers and Crystal has also some other interesting aspects not present in Ruby or imperative OO languages in general, e.g. union types, powerful macros (see e.g. https://github.com/sam0x17/mongo_orm/blob/master/src/mongo_o...).
Ironically I find the lack of static typing in Elixir (and thus Erlang) its greatest weakness.
Dynamic typing only gets you so far. Once you get beyond a certain scale of your project (number of lines, files, modules etc.) then static typing a sanity saver.
I still love Elixir to death but the lack of static typing isn't making it favours.
Have you seen Gleam Lang? It's like Haskell but on BEAM. I was looking into it but I decided that since there's next to no ecosystem for it, I might as well go with something like Rust.
Yep, I did. Wanted to make Phoenix projects with it but it turned out to be way too laborious, so gave up. Elixir has some problems but it's still much superior to Gleam.
Yeah true. For me I couldn't stand Elixir's dynamic typing and switched to Rust. I just feel personally like I can't use dynamically typed languages anymore.
I don't see them at odds. They are mutually complementary. You can go very far with a fantastic dynamic language like Elixir. The loosely shaped data that bombard your app from the net is a perfect fit for a dynamic language. And the OTP concurrency / parallelism approach as well: you can have an actor per connection (while languages like Python and Ruby and PHP have struggled with thread pools and dynamic limits for ages).
I am starting to love Rust but again, I don't see it as a competition to Elixir.
I like the BEAM and I like the spirit of Elixir, but I find it really hard to write correctly and quickly. For me it's the weak inference and autocomplete. Ecto is pretty cool, but Ecto doesn't help me do the right thing in the way that even something like TypeORM (not my favorite database layer) does without much effort on my part.
I agree with you in the past Elixir deployment was a bit complicated, you needed to install packages and such, but today IMO it's well supported by the language and simple to do, `mix release` and voilà.
So you haven't used the languages I listed but you want to judge them? No shame in that but if you want to ask why people use Ruby, I'd say you answered your own question, it's due to inertia, and if you actually want to compare these other languages, you have to actually use them to some non-trivial extent.
And I'd also say a big one is Rails, I'm not sure of many people who use Ruby outside of Rails. But that is because they're using Rails despite it being in Ruby, not necessarily because of it, because again, they're more interested in the features that Rails provides rather than being enamored with any language feature per se.
No way, I learned Ruby after 20 years of programming. Languages that earned me money before Ruby: C, Perl, Delphi (or something on DOS similar to it), Visual Basic, a little Visual C++, PHP, Java, JavaScript, even some Cobol plus a number of other languages for fun (hello to Postscript, Tcl, Forth, Pascal, BCPL, several assemblys and too many others to remember). Ruby was so much better. Garbage collection as in all interpreted languages, no types to write and a number of niceties that made me happy.
As you wrote, I started with Ruby because of Rails and I slowly migrated all my scripts from Perl to Ruby. Ruby is the language I use for my projects, plus some Node when I have to. Everything else is too hard, life is too short to waste it wrestling with those other languages. If I had to write something very parallel I'd go with Elixir. We'll see what Ruby's Ractors will bring to us.
The fact of the matter is, Ruby and Python are badly implemented, speed wise. The other commentor states more about this. JS is super fast with a JIT but Ruby and Python are still stuck with slow implementations.
Seems about right. Luckily, if performance becomes an issue, you can probably scale out horizontally, or perhaps if you don't care much about sticking to the reference implementations, you can consider using alternative ones.
Of course, performance in real world scenarios and when using larger frameworks (such as Ruby on Rails or Django) may differ from synthetic benchmarks, but it's nice that at least there's work done in creating these alternative implementations. A bit like how we have Hotspot and OpenJ9 for Java as well or even how there's glibc and musl - that way you can choose which implementation is the most suited for your needs, be it for performance reasons or others...
You're caring too much. Why is it so important to you that two particular implementations of two programming languages are badly implemented and thus (which doesn't actually automatically follow, but nevermind that) slow? Are you being forced to use them against your will? Have you developed a trauma?
My advice would be to change a job and stop caring. It would be healthier in the long run...
As for the subject matter: yes, Python and Ruby are somewhat slow, which is absolutely fine for a lot of projects and in a lot of contexts. Where the slowness is problematic, they simply shouldn't be used, and if they are, it's an engineering or organizational failure. Don't blame poor decision making on the language implementation!
> Python and Ruby are somewhat slow, which is absolutely fine for a lot of projects and in a lot of contexts
You can say that, but it presumes they are better than alternatives in other regards when there are options with really no disadvantages but better performance. The primary reason for using these languages appears to be that they are easy to learn when getting started (either as a new developer or a new project). But when you think that you're optimising to save a couple of months coming up to speed on tech over a lifetime of maintenance and performance benefits ... it seems lazy to me.
I mean, I am forced to use them if I use apps, sites and services running on Ruby and Python right? And why shouldn't I care that things are slow? I don't really appreciate you sarcastically armchair diagnosing me with trauma which can be a serious thing for many people.
Except there is jitted Ruby. Rubinius and jruby to start. Even (C)Ruby 3.0 literally touts JIT as one of the pillars that make it 3x faster than 2.0, granted it is only optimized for a certain kind of code (not Rails) in 3.0.
Almost any web-public-facing project is very parallel so Elixir should be a no-brainer, provided no artificial limitations on which technology to use (which is a very generous assumptions, granted).
I think you're pretty much wrong on that last point. The people I know who love Rails tend to rave about Ruby the language. It's not personally my favorite (spent about 2 years with it as my daily language, no rails involved) but it has many many fans.
How can you tell that that is due to them liking the language because they work with a nice framework on top of it? If I worked all day in a a language, I'd like at least some parts of it.
These people had experience with many other languages prior to Ruby. And they choose it for non-rails projects.
A lot of the love for Ruby seems to center around the widespread use of generators and the clean syntax for invoking them. And some people truly love duck typing.
People are raving about all sorts of stuff and that doesn't mean they know what they are talking about. I've been a party pooper on a Rails meetup before, people were extremely clueless where Ruby ends and Rails starts. Nothing wrong about it, but it can be a bit worrying sometimes how much misinformation is being spread.
For the record, I like Ruby -- but no longer work with it. I feel there are languages that picked up its slack for years now. Might come back to it now with the 3.0 release (provided Rails works with it). Actually excited to see if it's better now.
So I am not mindlessly hating. But "raving" about something is not a data point.
Actually I'm doing most of my money with Elixir and Python now. Elixir is nice except for deployment, like all the compiled languages I know. Python is much like Ruby but with weird design choices. Oh well, I guess that people coming from Python could say that the weird one is Ruby.