Matz 2003
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.
Want Ruby with Java like performance? Pick Groovy.
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.
There are a couple of reports about successful ports, e.g. https://forum.crystal-lang.org/t/experience-porting-a-ruby-w....
> 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...).
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.
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.
For example, there are benchmarks of some of the Ruby implementations here: https://pragtob.wordpress.com/2020/08/24/the-great-rubykon-b...
And here's a paper from 2016 comparing some of the Python implementations: http://kth.diva-portal.org/smash/get/diva2:912464/FULLTEXT01
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...
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!
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.
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.
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.
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.
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.
I am starting to love Rust but again, I don't see it as a competition to Elixir.
What was the problem? You can code in elixir in a style where you basically get ~80% static typing using structs everywhere.
I haven't gotten a runtime type error in years.
Problem is the unwillingness of the market to move. But it's happening, I am witnessing it while I am contracting.
Maybe I am getting old but I started to be skeptical about language features and power if at the end I can't make it max all CPU cores and use async I/O everywhere.
I think we all could use a bit more pragmatism. I for one don't like Rust but I am relentlessly investing in mastering it because I do need low-level statically typed and compiled language and I still have PTSD from C/C++.
F.ex. I loved Racket. It is an amazing language and extremely well-crafted and thought out. But, call me when they have Erlang/Elixir's processes (actors) and preemptive scheduling.
I'm getting there though. Rust is an acquired taste, plus I am very much sold on its premise and love the results. The journey, not so much. But I want to have that extremely powerful tool in my toolbelt so I am muscling though the learning process.
If we're talking naked OS threads, that's not efficient or impressive though.
(I am still going to review it sometime.)
Don't forget Crystal, which is a compiled Ruby-like language with static typing and type inference.
Violation of irrational dogma? Certainly is.
> simply because people don't optimize at every step of the process
Sure they do.
Processor efficiency isn't always the target of optimization, often for very good reasons.
> In game engines they do, to some extent, because they have to,
Yes, because optimizing market value to production cost in that market requires optimizing use of hardware.
In lots of other markets it doesn't, and optimizing use of hardware would be an taking on a cost that isn't warranted by delivered value.
Is Microsoft Teams supposed to be the fast, efficient alternative because I don’t think so...
Sure, there is bloat in a great many web frame works and I too question why some blogs need JS enabled just to render static text. But if we are being honest, by far the worst offenders for web bloat is the trackers and ad partners.
They certainly seem to come in waves though. It seems like the equivalent of bulking and cutting.
Swapping out ruby for golang won’t fix any of those.
I’ve worked on multiple Rails apps over the past decade, responsible for hundreds of thousands of customers and hundreds of millions in revenue, that easily rendered every page in 150-300ms. This isn’t time-to-first-byte—this is fully rendered, images and all.
If coders write their backend in rust for "the ultimate performance", and it's shipping 20MB of javascript to query a poorly designed, poorly indexed database with no caching, they're going to get far worse performance than a ruby app querying a properly designed, cached database with indexing that doesn't have to spend 5 seconds domming the user's DOM first. Performance is a holistic problem, and anecdotally, web sites felt a lot faster during the rails era than they do right now during the JS era.
It's certainly possible that the answer is that the language you're using is fundamentally too slow - I personally have almost never experienced that - almost always I can get more out of a time investment by focusing on improving DB performance, or some problem with delivery, caching or optimizing bundles.
You should look at your personal situation and use real data to decide where to focus, but you always have to focus. "Make everything 100% efficient at all times" is completely unrealistic.
I usually run Rails on two servers for redundancy. Any features that are CPU expensive I will spin off into a separate service (I’m partial to golang.) This is all on the order of $10s of dollars a month on AWS. 90% of most products’ landscapes are CRUD, and bottlenecked on IO to the database, not expensive CPU calculations.
Stripe primarily interfaces with 3rd party payment systems. Anytime a request has dependencies outside of the database, you’re “off the Rails” and should investigate additional options.
Shopify is a great example. Last I checked, Shopify is doing great still using Rails for 90% of CRUD and are optimizing just the 10% that they see ROI from.
Apps need to fulfill our needs. Nothing more and nothing less. Just like you buy a Nissan Leaf to fulfill your need all while knowing that Bugatti Veyron is one of the fastest cars in the world pushing above 400 km/h. Just like I use ArchiveBox written in Python and SQLite while knowing that there is Rust and RocksDB out there that can outperform Python/SQLite.
Side note: I do agree that in some cases product owners take over both user needs and developers' good judgement and turn a good product into a horrid mess but I would argue you can do that in any programming language.
Go make yourself some drip coffee on this Christmas day and take it slow! Happy holidays everyone!
I fully agree! But not everywhere and not at all times.
> feels good > matter of beauty
Well, that's not "matters" as in "must have", rather "nice to have" or "should have". See https://www.librarything.com/ for another example where a slow(er) app with high information density is preferred to a "nice" app (eg Apple Books "shelves" that are next to useless compared to this but sure enough, they are nice and fast).
> playing Doom Eternal the other day and it was just amazing the fluidity I got.
Well, this is where speed truly matters. The whole purpose of a game is to give you experience. Nice UX and fast graphics are a must because it's key to what the game shop is selling you.
I think you and I differ here because I really don't agree with this. Speed always matters. In fact, it is superlative, the fundamental feature on which other features must rest. I certainly won't use an app that's slow, even if it does more, because I get annoyed at the slowness.
This is the excuse typical electron developer make. But I think I disagree here. Speed matters everywhere. Just see sublime and vscode.
But then again, Electron is the best example where neither users want it nor developers particularly need it: users are fine if the UI differs across platforms and developers are OK to develop multiple native apps but PMs are not fine paying 3x or more for the product development.
They are? I'm not. I was not placed on this earth for tedium.
I can see the difference between VSCode and Sublime Text. I also don't...care. I use VSCode because everything it offers is way more useful to me than a handful of milliseconds. Wider language support, better language server support, better autocomplete and intelligent suggestions, out-of-the-box formatters and linters for the languages I care about, a really genuinely great remoting solution.
And as you obliquely sniff at: it's TypeScript, and this is powerful. "Oh hey, I don't like how this works, I'm just gonna crack its brain open and write an extension for it" is powerful, and while I used Sublime Text for quite a long time its accessibility in this regard is much weaker.
On top of it, projects are often lead by managers that are mostly interested in grabbing the low hanging fruits, pack the product with poorly tested features, set unrealistic deadlines and monetize as fast as possible, and they often don't provide developers time to breathe, take a step back and do any refactoring or optimization - those are too often labelled as purely technical tasks with no business impact and pushed down the priority line.
Some of the code written two or three decades ago was much more efficient (especially given the hardware available at the time) than today's projects both because developers were aware of building software for machines with a limited amount of resources, and because the software delivery timelines were much more realistic - aggressive marketing, sales and product departments hadn't yet completely taken over the engineering departments, and while agile methodologies were supposed to mitigate these issues they've actually only shrunk even more the delivery windows and made software development more hectic and shortsighted.
30 years ago a program that would choke on a 386 would be refactored until each single but was optimized for the available resources. Today's approach is simply "just throw more RAM/CPU power" - and that's what I frankly find unacceptable.
We often (justifiably) argue that deep learning, as it's done today, is something unsustainable for the environment. I wonder if anyone has ever measured the impact of running tons of non-functional scripts on the web pages rendered every second by billions of devices around the world.
We can run full fledged games at 240 FPS and yet,
websites and apps lag
Slow websites?
It's the overall system design of the web. Running a bunch of untrusted sandboxed code, retrieved asynchronously from potentially dozens of sources?
Yeah, that's gonna be slow.
Replace all the Rails sites with assembly code running on bare metal if you like, it's not going to change anything.
Ruby on Rails is plenty fast. You can serve up static pages in a few milliseconds. If they take longer than that, it's because you're doing a bunch of work at the database layer or some other work outside of Ruby.
the other side of that is in the web, the tech stack was not at all designed for what we are trying to make it do...
add those two things together, add a dash of network latency for all the loaded resources, and you easily get what we have today...
IMO a chunk of the programming world is entering a mature stage where much more work is put in the runtime of a language on not on the language itself. End of the day, you are going to have a call from an executive asking why the hosting bills are ballooning. I've saved some of my customers literal [tens of] thousands of $$$ a month by migrating a critical chunk of their services from Ruby on Rails to Elixir's Phoenix and, on one occasion, Rust's Rocket.
Programmer ergonomy and happiness are important, don't get me wrong. But IMO we are fixating way too much on them in some languages / frameworks. Some pragmatism should be put back into the picture.
"No matter how fast or slow your language might be, there will always be some applications for which your language is fast enough and some for which it's not."
-- Mark Twain
> Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
And I like Ruby. And I hate Ruby.
We expect civil engineers to account for people, but they think about materials, planning, math, etc. Stay close to your craft or you might see it and/or your position in it evaporate.
This release looks interesting. Let's see how type annotations work out in real life and if people use them.
It wouldn't be needed if unit tests were enough as it used to be sold.
You are not furthering your argument, you are just reasserting the status quo.
They really aren't, though. No statically typed languages which started off as such, to my knowledge, have added an Any type (casting magic notwithstanding). You must be thinking of TypeScript and other "gradually typed" languages, where it's a necessity for interop with existing code.
The rest of your comment, unfortunately, does not really put forth any coherent argument, so I would tend to weakly agree with the parent comment.
There was a real need/use case for it.
Its successor, Visual Basic, had a VARIANT type. Then VBScript was derived from that, and it was fully dynamically typed.
No, it hasn't.
The fact that there is utility to static type checking that is sometimes a net win so it is better, ceteris paribus, for a language to have it available does not “settle the discussion” about the claim that dynamic typing was pure lazy design that was never in the interest of human developers.