I owe my career and livelihood to Ruby, Rails and the community. When I started learning programming I was overwhelmed because of c, c++ and JavaScript. Tried a bit of Python too.
I thought I would never get a hold of any programming language ever. One day I tried this mysterious language from Japan(That's how I knew Ruby at the time) on tryruby.org. Ruby was breath of a fresh air. Code read like English. I was making small CLIs which required so much work in every other language. That was enough to get me hooked. Then I learned about Rails and never looked back.
Happy to see this language making new strides with this release. This is a thank you note to Matz and the community.
Ruby played a big role in helping me rediscover my love of programming, and it also acted as a bit of a gateway drug to think much more about language design and to explore a lot of other languages. I don't use Ruby much anymore, but it will always have a big place in my heart.
couldn’t agree more. learning ruby and rails (in 2007 when things were much simpler) was a truly beautiful experience for me. i consider rails and ruby to be one of humanity’s great works of art.
I remember Ruby on Rails first being announced, and Why's Poignant Guide, and the first PragProg book about Rails (as well as Try Ruby).
Back then I was a teenager and doing most of my stuff in PHP, because in 2006/2007 most of the resources about PHP and MySQL I could find were all about that, and I was still at the level of just injecting some PHP into my HTML to make it dynamic (back then Javascript/DHTML was something you copied and pasted and there was only rarely a reason to seriously use it). This was the era of PHP, Cold Fusion, classic ASP, CGI and so on. Not to mention that shared hosting providers (the cheapest option for web hosting) only really gave you PHP under Apache to work with (or the LAMP stack as it were).
So this Ruby on Rails looked cool but I couldn't get my head around it at first, I was still super green. Skip forward from 2007 to 2009, right before my first professional gig, and the seed had gestated. Suddenly I was running a minimal Rack/Sinatra server around a Redis app purely because I needed a leaderboard and I learned about things like ZRANK and ZADD before I understood what sorted sets were. I did try to advocate for Ruby at my first job but they were of the mindset that literally anything and everything could be built through Drupal. I will leave that thought to your imagination, although I owe my team mate a lot for properly mentoring me when it came to javascript, closures (back in the day where articles about closures in JS were the same as more recent articles about monads.) He didn't just show me jquery, he gave me the low-down on JS itself.
I'm made redundant and after that, I go deeper into Ruby. I get a job in London of all places and thus began my career as a full stack engineer specialising mainly in Rails, and Ruby. My interested in the language grew ever stronger and it remains strong to this day, a good 10 years later. I dabble in a lot of other things these days too, because that's what I enjoy, but I'll always find myself back with Ruby when I need to be pragmatic. It's a beautiful language with a strong community that values developer experience, and my only real wish is that I learn enough to be able to contribute back to the language in a meaningful way,
I'd say less than 10 years ago, because many not-so-edge cases have been fixed, and the new sections of the framework (activestorage, active job) simplified the development of some features that were harder to integrate some time ago
A new Rails 6 project will by default install web packer, to mention just one thing that is likely to trip up beginners. On the rails of yesteryear you would just drop a JS file in a folder and it would "just work".
Some things are more complicated, and some things are less. RESTful resources which seem so core to Rails were not part of Rails until 2.1 I believe. Also Bundler and the Asset Pipleline while having some growing pains really did solve significant problems of early Rails apps in production. Personally I still prefer the old school ujs patterns over the new JavaScript but I’ll still a request/response proponent so I may in the minority there.
Same here: There are programming languages that are faster or can be ranked higher on technical aspects based on the type of project but none are Fun, Ruby is Fun.
In 2008, I ran across DHH in an Apple store in Chicago, and got to thank him in person for Rails. Similar story for Matz and Ruby in 2013. My current work is mostly Java, which is tolerable since Java 7/8, but I always enjoy revisiting Ruby and Rails when I get the opportunity. Great to see this continued progress and investment in the language.
I remember when Rails first was released. I kept the source code for Ruby and for Rails handy, and it was sort-of possible to wrap my head around both. One of the most fun non-AI conferences that I ever went to was Merb Camp in San Diego where the Merb team announced merging with Rails.
I have such good memories of the four or five years when Ruby was my main driver. Great job by Matz and core team with the 3.0 release.
I have gone back to my 1980s roots and now once gain use Common Lisp as my main driver, except for deep learning where I need to use Python (tried Julia and Swift).
I think Matz has it exactly right. As programmers it is important to be happy using a language. Life should be fun most of the time, and there is nothing wrong with trying to optimize life for maximum joy we bring to ourselves and other people.
I still feel we the Merb “merger” was less than a merger and more of funding being cut for Merb development. Not sure if Engine Yard didn’t see a future in Merb or what, but it felt weird after so much rhetoric about the modularity of Merb over Rails to just see Rails gobble up Merb in just a couple of months. Either way, I wish I never threw out my sandals and I still miss Ezra :(
I miss Ezra as well, he was a great example of someone who moved things forward just because he cared. Ezra also put way more effort and passion than anyone could reasonably expect into growing the Ruby and Rails ecosystem and community. I enjoyed listening to many of his talks.
Ezra sat next to me the second day (he was giving presentations the first day) and we had some good talks. You say you miss him, is he not OK? If so, I am very sorry to hear that.
EDIT: I just did a web search. Very sad. Long before I met him at the Merb conference, I appreciated some nginx plugin he did for uploading files with a progress meter - that was a long time ago.
I remember hearing about Merb, and how some people really liked it, sighed a deep sigh, NOT looking forward to years of acrimony and battling-by-benchmark.
So I was so glad when I heard the announcement, particularly as they treated it as "We sat down and considered each other's technology, from a tech perspective, and we're going to bring the best parts of each to make Rails 3." Not everyone loved the results (sorry, sarcasm), but we avoided an irritating fan-war.
I got to thank Yehuda when I met him at EmberConf, and he seemed pleased that it was appreciated.
I’ve been working as a developer for9 years. For most of that time I gravitated toward the DevOps/SRE/Platform niche because I care about quality, but the process of developing resilient, maintainable and clean code in all the languages I had used seriously (PHP, Python, JavaScript, C, Go) just didn’t work with my mind. I couldn’t wrap my head around it and make myself apply the discipline.
A year ago I was dropped in as the lead on a large Ruby project. Suddenly everything clicked. Now all the reading I’ve done on domain driven design and TDD actually has meaning and I’ve written more solid code in a year than the rest of my career combined.
And on top of that, while every corner of tech has its toxic personalities, the Ruby community is overwhelmingly friendly, welcoming and mature.
+1 for the community. Ruby was my first language, and I think the Ruby people were a big reason I kept going with programming. There are welcoming... but also very goofy/ whimsical at times!
I'm curious, which toxic personalities are you talking about? I'm not very aware of the personalities in the software engineering world, but I would like to know what other people consider "toxic" in the software industry.
To be up front here, I am generalising based entirely on my personal subjective experience and the reports of some peers and friends.
Many of the language communities I’ve been involved with have been dominated by behaviours such as:
- gatekeeping
- elitism
- subtle sexism
- credentialism
- (most frustratingly) a general sense that “our” community is somehow superior to others (people often hurl this nonsense toward PHP and JavaScript developers in particular).
I remember going to a Go talk where one of the founders of the language was speaking to a small group. An audience member who was an avid Go user asked a simple, innocent question about some shortcoming of the language. He copped a sarcastic and dismissive response from Pike, which of course then acted as the signal for everyone else to treat him the same way during the casual drinks and pizza after the session. I’ve seen this sort of thing time and time again both professionally and in the meetup / conference space.
On the contrary, the Ruby development community across three different Australian cities is dominated by people who have a solid baseline of emotional intelligence and worldly perspective. This filters through the community and creates an environment that I personally find to be far more welcoming and intellectually stimulating.
I've been considering learning Ruby to replace Python for high level coding and scripting, Python is what I use for most of what I do. Should I? The main reasons I have not are inertia, massive selection of data manipulation libraries in Python, difficulty of async and multithreading in both languages means not much benefit from a usability perspective, and I'm not a fan of the Contributor Covenant CoC.
But I have looked at the syntax of Ruby and find it to be more elegant. Does anyone knowledgeable about it have any useful information?
Everything is an object, methods take blocks where that makes sense. stuff just feels well thought out and generally when I learn something new about ruby I think 'wow that makes sense' and not 'why would you do it like that'.
There also seems to be much much less churn from a tooling perspective. Learn how gems/bundler works and you're set.
Also, ruby can be a (in my experience) superior replacement for awk.
Brief example, -n is loop over current line as $_, -l is clean up line endings
I was trying to find some longer pipelines from my command history. encode is stripping out a bunch of invalid utf-8, otherwise it would have just been $x<<$_
Do learn Ruby. You seem to answer your own question! You’re curious about it, worst case you’ll have opened your mind to something else which is only a good thing.
But do not be fooled by Rails, Ruby is quite something else, of which Rails is a very small, opinionated part.
Tips: look at MiniTest source code, Sinatra and Rack source code are quite interesting too.
Shameless plug, a couple of idiomatic Ruby repos of mine:
Only if you are going to use Rails. It seems that in all other domains Ruby have lost to Python, Kotlin, Go and others. Personally I love Ruby and Rails, I prefer clean Ruby syntax over Python syntax, however except Rails all other activity is going in other languages. Kotlin code with type inference is as concise as Ruby code but executes 50x faster. Ruby simply won't have ML libraries like Python has.
For a web programming I would switch to Kotlin. However Ktor is still lacking compared to Rails in most important areas for me. In Rails common operations like upload a picture, serve is later in a different resolution, migrate a db, quickly create CRUD forms, etc. are just a few lines of code. In Kolin web frameworks you would have to invest much more time to glue together different libraries to do the same job. Many won't agree with that opinion but for me Rails ActiveRecord is the best part of Rails. There is no a such complete thing for a Java ecosystem. It is a beautiful compromise between ideological (only pure plain Java objects are allowed) ORMs like Hibernate and plain SQL approach like jOOQ.
I've been using Phoenix rather than Rails as my go to for web development, but I still use Ruby shell scripting. It's dramatically faster to write than Python, Go or Rust, largely because it's got more convenient Unix interop than anything since Perl.
One example is, I've written a script that I can pass a domain name and an email address to. It will then set up basic nginx blocks, install certbo and add a cron job if needed, run certbot, get an https certificate and reconfigure the nginx blocks to reverse proxy incoming requests and force https.
I have no idea what language would have let me write this faster than Ruby did. Maybe Perl if I knew it well. Definitely not Go or Rust.
Ruby started as a shell scripting language so I agree that it is good for that purpose. However the question is how much time one spends writing shell scripting code for personal use. If someone already knows Python and only occasionally writes shell scripting code then in my opinion learning a new language only for that purpose isn't a good investment. I would say Python is good enough for that tasks.
In other words if someone has a good enough tool in their tool-belt for a certain area, then learning another slightly better tool in that area is not a must.
In my opinion it is better to be proficient in a one language than mediocre in two similar languages. If someone is bored and has time to learn both Python and Ruby then why not.
I'd say Ruby's edge for shell scripting is considerable, but I agree with that strategy and recorded a whole video on the idea: https://youtu.be/bIpgUmn5yK8
tldw; Pick tools that complement each other rather than compete with each other.
Also it's interesting that some languages like C or JavaScript make a good complement to almost anything.
As much as I want to learn new languages, it looks like my brain is not cooperating. Either the syntax is hard to read (eg ruby or elixir) or articulating the same solution (eg python) in Javascript much easier.
Any suggestions on which practical language to complement Javascript for web dev? Also, use cases for functional programming language, is it even useful?
Ruby is a fine application development language, but an incredible scripting language. Can't recommend it enough for that niche. Nothing else is even close.
From the opposite side, I learned Python after learning Ruby (and Javascript) and had a hard time with Python namely with scoping and lambdas.
I think if you care a lot about the philosophy behind Python (have one obvious way to do things, explicit over implicit) and the syntax, then you might have some difficulties picking up Ruby right away.
With that said, I think it's a very enjoyable language; Rails is still a very enjoyable ecosystem; and it works well for scripting especially if you're trying to write organized shell scripts.
Particularly I am a fan of the "explicit over implicit" paradigm, and what little tinkering I've done with Ruby, you're right, that does mess with me a little.
That’s mostly a Rails trait though. I code and choose a mostly explicit approach to Ruby, which lends itself very well to that, especially as it’s how the stdlib is designed .
Both languages have their strengths and weaknesses. I have a Ruby background and have been learning Python more recently. After years of "artisinal" Ruby with heaps of unnecessary metaprogramming magic Python seems nicer to me, but I'm senior enough to be aware of my perceptions not necessarily being reality.
The bottom line is that (A) the more languages you are proficient in the better and (B) as long as whatever problem you need to be solved is solved then the language doesn't really matter.
Depends on how much of a drag you feel Python to be. People sometimes want a change for change's sake. If you think you're happier using Ruby well that's a good enough reason to seriously consider it. Outside of machine learning I can't really see any objective advantage one has over the other. Both are super mature, expressive, dynamic languages. The rest is a matter of taste. Jobs wise I'm sure Python has an avdantage, but Ruby has some strong niches (web development, devops) that are always in high demand as well.
IMO Python has more libraries, more developers (people who might want to work on your project with you), and a more simple and intuitive syntax (easier to onboard people). Ruby is a fairly quirky language, eg functions aren't first-class values.
I would say that Python is quirky for having functions at all and as a Rubyist it is confusing why some things are functions in Python when they could be methods. This leads to a much simpler mental model in Ruby.
The syntax in Python also leaves much desired (e.g. use of underscores) and most of Ruby's quirks are Perlisms such as $1.
Yes. Why the f is len() a function in Python? From a design perspective, it makes absolutely no sense. You have to implement the __len__() method in order for the len() function to work. Why isn't it just a method?! And that is the one "right" way to do it. Drives me crazy. And there are countless other examples like that.
That's the crux of it here. People really differ about this and OP should check it out for himself.
Yes Python has more usage, I hardly think it really affects one's work in any meaningful way. Javascript has tons of developers using it, many times this is a con actually. An explosion of libraries and conflicting views and philosophies.
That's another consideration I forgot to mention. A lot of what I do is small FOSS tools and it seems most of the people interested in using and contributing to stuff like that are proficient in Python, whereas the Ruby community seems to circle around Rails and is very small.
Learning anything new is always a good idea. My (maybe unpopular?) opinion is that Python and Ruby are practically the same language. With different syntax, sure, but the same in the sense that there is a large overlap in terms of what they are good at and bad at. If Python is a good fit, then Ruby probably also is. If Python is not a good fit, then neither is Ruby. Unless you really depend on libraries that are only available in one language (say data manipulation libraries).
So I would personally recommend learning something new that is quite different. For high level coding you could give Elixir a go. I've seen it used at a very high level to orchestrate machine learning jobs running in either Python or Java. Ruby/Python are probably still better for little scripts though. For data manipulation maybe give Julia a go? For lower level programming maybe try Go or Rust?
Whenever I need to reach for async in Python I ponder rewriting the program with Go or Elixir. Python feels like a very high and expressive language with tedious, low level async primitives bolted in...
Can recommend, it's pretty elegant, fun, and efficient. Also: https://github.com/JuliaPy/PyCall.jl "This package provides the ability to directly call and fully interoperate with Python from the Julia language."
See the Ruby Advent Calendar 2020, December 1st - December 25th - 25 Days of Ruby Gems [1] that highlights ruby scripts in action for a sampling what you can do with ruby. [1] https://planetruby.github.io/gems/
So with the promised 3x speed improvement (hooray!), where does Ruby stand with regard to performance, compared to say Python? According to [this benchmark][1], it seems (the 3.0.0-preview1 version was) on average about 2x slower than Python. Are there other benchmarks to compare with?
Looking into it, this other benchmark [2] of 3.0.0-preview1 vs Ruby 2.7 actually concludes there's no real performance improvement there. So I guess an additional question is, is there actually a 3x speed increase in realistic benchmarks?
> where does Ruby stand with regard to performance, compared to say Python?
In my experience Ruby has been faster than Python for a long time - ever since its performance improved significantly going from 1.8 to 1.9, and Python’s got worse going from 2.x to 3.x.
Interesting results, thanks for sharing, that matches my expectations.
OptCarrot is probably one of the rare cases where Ruby 3.0+JIT is 3x Ruby 2.0.
On most benchmarks, the gains are much smaller.
I'll try to run these benchmarks on TruffleRuby (and maybe JRuby) too, would be an interesting comparison.
BTW, is there any reason you used 2.1.0 and not 2.0.0? Maybe some issue with 2.0.0?
> OptCarrot is probably one of the rare cases where Ruby 3.0+JIT is 3x Ruby 2.0
The Are-we-fast-yet suite is optimized for inter-language comparisons and sets the focus on ideomatic language use and representative algorithms. There is a peer-reviewed scientific publication; here is a preprint: https://stefan-marr.de/papers/dls-marr-et-al-cross-language-...
> is there any reason you used 2.1.0 and not 2.0.0?
> The Are-we-fast-yet suite is optimized for inter-language comparisons and sets the focus on ideomatic language use and representative algorithms. There is a peer-reviewed scientific publication; here is a preprint: https://stefan-marr.de/papers/dls-marr-et-al-cross-language-...
Benoit (eregon) is the second author of that paper.
Well, apparently he does not want to be recognized; without your hint I would not have figured it out (there is also no indication in the profile). At least I don't have to convince him of the benchmark's quality.
the Ruby 2.7 benchmarks [0] seem to shows that Ruby is slightly faster than Python 3, or at least fairly competitive.
Though things like Python 3 going from 18.45 seconds to 2.67 seconds on the regex-redux test [1][2] tends to make me question the validity/usefulness of these benchmarks. (inasmuch - how much of it is testing language performance vs bypassing it?)
I've also found that the Computer Language Benchmarks Game benchmarks tend to be less and less representative of real workloads, due to what the benchmarks do and to the philosophy of "write it to make it fast, not idiomatic, and parallelize things that would typically not be parallelized".
Just taking a look at the benchmark code makes it clear it's very far from idiomatic Ruby code.
'You will probably come across people saying that the programs are not idiomatic ("enough"). So read the description and write your own idiomatic program, without programming tricks.'
Several multi-core Ruby programs failed when run with 3.0.0-preview1 --jit
Which is why you see Python3 programs using 4 cores for spectral-norm and binary-trees and fannkuch-redux — when the corresponding Ruby program is only using one core.
These releases have become one of my favorite Christmas traditions. I've been using Ruby since 1.8.7. It's really come a long way since those days. It was my primary or only language for over half of a decade and even though it is no longer my daily driver I still find myself having a lot of fun programming in it when the opportunity arises.
Having actors and some async capabilities might make me return to Ruby. I always liked the syntax and the ecosystem but felt like they were dragging their feet sitting at ancient computing paradigms for way too long. (Transparent parallelization like in Erlang/Elixir, anyone?)
I feel the same way towards OCaml and its multicore saga as well. I figured I'll just wait for 5.0 which is due at the end of 2021 (at least) and then will start afresh there without having to do 100+ legacy code and compatibility dances, and have multicore from the get go. (Sort of like starting with Python 3 and never touching 2, I suppose.)
Back to Ruby, I always felt it was too slow as well, at least when paired with Rails anyway -- JS and Erlang/Elixir are much faster and are still dynamic.
But with 3.0 I might make a return to it. Shame that IO#select isn't supported but with async and actors that's likely not a big problem.
Before Ruby, I just hacked stuff together as a hobbyist trying to figure out how to earn a living. Ruby is what forged me into a Programmer with a capital P, and it continues to rock my world to this very day. Congrats to the Ruby team and everyone involved in the release of v3. I hope the groundswell of excitement and enthusiasm I see is proof once and for all that Ruby is alive and well.
I feel left out since I never learned Ruby. I love a range of programming languages, but I never had a reason to learn Ruby. It looks so powerful and seems to have a lot of quality of life features (backticks for a subprocess seems awesome for scripting). When I've considered to sit down and learn it, the big question always pops in my head: "is Ruby dead?". I think that's because of the lack of its prevalence in my life, because it seems like HN loves it and this most recent version seems fantastic, especially with some more advanced static analysis.
I wish I didn't have that idea of Ruby being dead for as long as I had, because it really seems beautiful. Maybe I'll have to make Ruby my next language project.
Ruby is far from dead, it’s just past the hype. Fortunately in the last year or so I’d say it’s also past the blowback that comes to yesterday’s hype tech when the next hype tech arrives. (Have fun with Deno, Node.)
Ruby really shines into areas: general purpose scripting (it was originally designed to be a bash replacement), and web development (because the ecosystem is very large).
As the primary language for GitHub, Stripe, Shopify, AirBNB and many others, Ruby will likely always have a vibrant niche in web world, even if it never expands far beyond that circle. And for general purpose scripting, I mean, any language you enjoy using is a good choice for writing your scripts in.
I kind of doubt Deno will see much serious production usage. There’s not much practical point to it from a business perspective. The only way it would become popular for most use cases would be if it had Node compatibility, which doesn’t seem to be happening regardless.
To me, 3.0 is not super interesting per se, but it's a great ground to make future releases compelling, congrats to everyone involved, and thank you for your work.
The thing is the language is complete (imo).
I don't want them to reinvent the wheel or break backwards compatibility like python 3 did. And please don't introduce explicit types into Ruby for god's sake.
So what's left to work on? I guess the things they're doing now: better performance, better tooling etc.
Double down on actors and async I/O, make scheduling preemptive like the Erlang's VM does, and make message passing the preferred way to do multicore-CPU-enabled work.
Nobody is requesting new language features for ages now. They are very rarely needed. The runtime is what needs a lot of work.
Yes they do but that won't help you if one bad actor (literally and figuratively) takes a long time to execute a single function call. Erlang's VM has machinery to multiplex actors on separate CPU cores and keeps around several different kinds of thread pools -- native (as in Erlang bytecode) actors, dirty I/O threads (where potentially long-lived I/O will live) and dirty CPU threads (where CPU intensive tasks go) -- and can move actors between them (although let's be honest, nobody can make that work reliably and Erlang makes mistakes there as well).
Basically, as they call it, several different schedulers, each with its own pre-warmed thread pool.
An event loop is a step in the right direction. I am just worried that Ruby 3.0 might turn out how OCaml Multicore is turning out -- an endless saga.
Completely agree about the tooling bit, after working during some time with Golang (just a bit during these past years) one of the things that I most like about that language is the set of official tools that it has, from formatting your code to check for security issues or unreachable code.
It helps the developer to be more confident about its code.
The Ractor support is very welcome and needed. I've tried several times over the years to do concurrent HTTP requests using various gems, and was never able to get it working properly. Great to see a true message-based concurrency model.
Ruby has definitely helped me get through some rough and tight spots. So many things are easily able to bum me out, while Ruby goes out of its way to make me happy.
> Welcome home. Things are going to be fine. Don't worry about nonsense. Just `:chill`
A beloved safety blanket that makes it easy and fun to do boring everyday tasks.
What are your thoughts about it being the 7th most dreaded language on Stack Overflow's 2020 developer survey? I've never programmed in Ruby, but it seems attractive to me.
I honestly cannot believe that this is a solid metric. I believe the question, or their answers are poorly parsed.
I presume a lot of the dread is really about Rails. And the rest partly hearsay of the slow performance of Ruby.
Rails is, to me, a blessing, but also a terrible framework. It helps to rapidly ship products. Just cobble some gems together in a controller or two, mix a gem or three into your models and you have a demo. A rapid Proof of Concept. But also a product that is practically unmaintainable. I've been doing Rails from its very beginning, solving this (trying to) has been my primary job for over seven years now.
And performance? Yes Ruby is slow. But the speed of the language is unmeasurable in, I daresay, the vast majority of the projects of people who tell you it is too slow.
That legacy mysql setup, this poorly evolved domain model, or that badly integrated external API is almost always the thing making it slow. The ms of Ruby handling that JSON to CSV conversion then is practically unmeasurable.
Rust is not going to speed up those 3000ms spend in that ugly SQL query. Go's multithreading is not going to solve the slow API which you call thrice per minute. And Java is not magically making the tangle of classes, jobs, callbacks, listeners and whatnot dissapear.
Rails is alright. It's just a great scapegoat for bad teams working under impossible deadlines: "Our code is unmaintainable because Rails! We need 1 year to rewrite it in Go/Elixir/Java". I mean, because Rails has a flat structure you couldn't ever take the time to reactor that piece of crap code you wrote for 2 years? really? You didn't notice a model stopped making sense or growing in complexity?
I see the same criticism with PHP. It's perfectly fine, stop blaming the tool.
Rails doesn't help you form a proper domain model. Or force you to put side-effects in the proper place; it doesn't help with evolving a proper data model, or avoid tight coupling in unwanted places, it has hardly any tooling in place to employ design patterns.
On contrary: often it encourages bad practices through "defacto" standard gems, or by making "the wrong choice" easier than "the proper design pattern". A "concern" is a simple way to turn a 800-lines controller into four 300 lines modules that amount to the same ball-of-mud, for example. (Concerns have great use-cases, but most often it is not the solution to your problem). Rails offers things like `try(:foo)` to quickly solve that equivalent of the "null-pointer"- exception, without forcing the developers to dive and in and solve the reason why it is nil, or solve it with some design pattern (adapters, null-pattern etc) either: just keep sprinkling `try()` keeps it rattling along too. Somewhat.
So, yes: lack of proper design and architecture is the real problem behind those "ball-of-mud" rails projects.
But Rails' lack of training-wheels and the ease at which to make the wrong choices, really doesn't help teams aim at proper design and archicture either.
> Rails doesn't help you form a proper domain model. Or force you to put side-effects in the proper place; it doesn't help with evolving a proper data model, or avoid tight coupling in unwanted places, it has hardly any tooling in place to employ design patterns.
I think this is only half true. Rails certainly forces very little on you - but has lots of documentation and helping hands pushing you towards tdd - and it has fairly powerful and simple tools to help with data modeling - as long as your data can fit reasonably in the ActiveRecord pattern.
More complex subsystems can be split out into rails engines or services.
All that said,it is indeed easy, without some discipline, to roll out complected controllers and views.
But I don't think it's fair to say that rails the framework via structure or its official guides, encourages that.
Quite the opposite.
As for "try" (now for a long time largely subsumed by ruby's built in &-operator) - that can be helpful where appropriate, like with handling input,and occasionally with explicitly optional relationships and nullable values. But of course NULLs should normally be avoided, and the database should be leveraged to ensure data integrity. And rails allow you to do that.
Rails has a flat structure, it has no knowledge how big your project will become. For many, many code bases this is good enough. Look at Gitlab, which is quite big.
If you need more structure there are many design patterns you can follow and introduce into your codebase.
I like their UI just fine. Speed, smoothness, never had much of a problem. And the amounts of features they were able to come up with the last few years is pretty impressive.
In terms of features I quite like GitLab as well. I just think it's time they rewrote it in something much faster than Rails.
I have literally never used a fast GitLab instance. Anecdotal evidence, I am aware. I'd still venture out to claim this says something about the average speed of your average GitLab installation though.
Hmm don't see any rewrite in their cards though...they're pretty much gonna ride this thing with Ruby. If Shopify did it with their monster scale I bet they can as well.
On the nulls bit, in a context where nil is a legitimate value, my team's policy is to use the ampersand operator. To be honest this is preferable because it clutters up code the least. I don't think we use a single try() anywhere, even before I used ampersands it was always `blah_blah unless x.nil?` etc etc
There are legitimate cases for `nil`, but far less than most people allow.
What does "user.last_login_at == nil" mean? `NoMethodError `to_human_date` for `nil` in email.erb. "Quick! lets fix that with a `try(:last_login_at, "Never")`: if nil, it means the user never logged in.
You now, without proper thought, you introduced a business meaning to a missing value. Adding tight coupling, slowly painting yourself in a corner. How does this translate to "Could you give me a CSV with all users that never logged in"?
Maybe you did mean to assign such domain-meaning to "last_login_at == nil", but then it is far better to explicitely do this. E.g. a `NeverLoggedInUser` subclass, a method on the model `never_logged_in?` an explicit flag in the database, or maybe even a special table "inactive_users" that holds these. All depending on domain-meanings, discussions, use-cases and thought. This is always a lot more work than just throwing another `try` at the bug. Rails "rewards" the bad choice, and somewhat opposes the proper solution.
Rails makes it easy to prototype and rapidly move forward: those are good features. But often you should, instead, be forced to halt for a second. To push you towards the whiteboard. Being able to throw in a quick `try` here, or a `sort(last_logged_in: :desc)` with another `where.not(last_logged_in: nil)` there, and so on, are a blessing when quickly moving forward. But they will haunt you in the future.
Balancing that is hard, regardless of framework, but Rails' features balance towards the "moving fast" a bit too often in my liking. Esp. because it rewards that team-member who "Gets stuff done" by abusing those "quickfixes", while leaving the project with ever more technical debt etc.
Having worked and working with rails projects spanning ruby 1.9 through 2.4 and rails 3.2, 4.1, 4.2 and 5.2 - the major issue I've seen with legacy rails is how difficult it is to keep views refactored and seperateted into widgets. Some teams seem to blame erb for this and run towards various different template dsls like haml (equivalent to writing a template language for php, which already is a template language, because the team can't keep views/templates simple).
Fat/smart models help - but the old/standard tools in rails (helpers and partials) INMHO is poor tooling for the "view" layer - and this just gets worse with Javascript in the mix.
Another option is of course to just use rails as an api server, and do the front end in react/vue etc. Although, at that point, you might be better off just using postgraphile or hasura.
The other real problem I see in some of our projects, is developers simply not trying to learn minimal best practices (just reading a few paragraphs on rails guides...). And that leads to many awkward choices, a lot of re-inventing subsystems that already exist in rails (because developers didn't have a look before coding up a quick fix) - and few tests and poor testability. But those strike me as much more cases of people "holding it wrong" than rails being the problem.
Finally, I think there's still some issues in rails 6 with asset handling - but overall rails 6 seems like a comprehensive, solid and easy to use framework.
> But those strike me as much more cases of people "holding it wrong" than rails being the problem.
My idea exactly.
To stretch that analogy: Rails has guides, books and neat API documentation explaining how you should "hold it properly" (and when not to etc.). But it also lacks "notches", "crossbeams" or "ridges" that help people "hold it properly" on a daily basis.
Well, what you said would be true if management was sympathetic to the argument of "the language and framework we are using no longer serves the project well, so let's rewrite". Since they are not, projects are, 99% of the time, stuck with their first choice of language / framework for life.
What I meant was you can take a messy Rails monolith and do a million things to improve it (including breaking it into smaller independent services if that's your thing). Rewriting in another language is the last thing I would do if the project is big.
Ruby isn't new or novel anymore, and is a relatively small niche. Learning it properly takes time and effort - hence the "dread". I'm pretty sure 10 years ago no one dreaded Ruby yet the language was almost identical to what it is now. So I think it speaks less about languages per se and more about hype cycles and job markets.
There's a saying that Ruby gives "Every toddler a chainsaw" (https://codefol.io/posts/ruby-python-and-freedom/). You can use it and it's metaprogramming to write some really elegant APIs. You can also write entirely the wrong abstractions, and it will not stop you. You can even extract private variables from lambdas if you're willing.
Now, imagine that in the hands of someone with poor taste, or, even, just rather different taste than yours.
Not a big fan of Ruby (okay, with 3.0 I might become a fan again!) but to be fair, these SO surveys are asking really weird questions that appeal much more to emotion than to reason.
With MJIT showing such a big improvement (for particular cases anyway) starting with this version, I hope more people start writing code/gems that take advantage of this.
You shouldn't sacrifice the ergonomics of your API just for the same for performance IMHO, but there should probably be nice gains here and there.
Best of all would be if ruby code becomes good enough that you no longer need to FFI into C code, who knows, maybe ruby 3 will be the start of the `ruby only nokogiri` age :).
Congrats! To celebrate Ruby and the Ruby community, the Ruby Advent Calendar 2020, December 1st - December 25th -
25 Days of Ruby Gems highlights ruby scripts in action - packaged up in gems for your convenience and for easy (re)use, see https://planetruby.github.io/gems/
I don't know about beauty, because what's beautiful to one programmer might look terrible to another. For example, functional programming, especially as you get closer to point free style - some people love it and find it truly beautiful and others find it obtuse and distasteful.
That said, I do think that Ruby is one of the most expressive general purpose languages, for reasons like being able to chain function calls without needing to add parentheses or some other call notation. There are surely DSLs or more obscure languages that are more expressive, but I would argue that few general/widely used languages are as expressive as Ruby, and so to answer your question if allowed to equate beauty with expressiveness, I think Ruby ranks very highly.
I would say point free is a case of form over function, beauty over readability. Other examples would be slim laptops with loud fans and those low height keyboards that get blocked by small particles.
My 2020 macbook pro had probably my favorite keyboard. The low travel means I could type far faster on it than any other keyboards I've used. My 2019 is almost as good, except it has the issue of keys getting stuck/jammed by small particles, the 2020 version apparently had that issue resolved.
I wrote a coule of small CLI tools in Ruby. I really liked how a single line could do a lot of work and those fancy syntax sugars. But I found it difficult to work with due to bad code completion suggestions in IDEs and overall poor documentation.
I never knew what objects a function could return without reading the code or trying to call it first and inspecting the response.
Then I switched to Go and Python and found those best-suited for all my needs.
it don't feel it rush imho.
if you follow the github repo and there talks, there are preparing this for a while.
they already have the branch 3.1 start it :)
Not sure about actors but I just use joblib for parallelization. It is way lighter than Dask and friends but still depends on (cloud)pickle serialization.
"Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves."
I have to agree with the dead comment here. Focusing just on people is how we got to the stage of having extremely fast CPUs that can compute billions if not trillions of operations and yet websites and apps lag. We can run full fledged games at 240 FPS and yet, websites and apps lag. It truly is heresy to not fully utilize the hardware we create, such a waste, simply because people don't optimize at every step of the process, useless abstraction on top of useless abstraction. In game engines they do, to some extent, because they have to, and so should they in general purpose applications as well.
Web apps are usually slow because of (1) poor data modeling/unoptimized SQL/unindexed tables, (2) ad tracker bloat, and (3) single page applications that reinvent the DOM for $reasons.
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.
However, fixing all of those, which costs less in server time (and potentially even dev time, debatable)? I've seen hundreds of Rust based sites on a single 5 dollar droplet while the same would take an order of magnitude more servers. At scale, this gets expensive. See Stripe, Shopify etc that have found this out.
I run a busy production ruby app on a $40/month droplet. My performance issues are almost never related to ruby. It's nearly 100% of the time some complex database query that needs to get indexed/cached.
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.
One abosolutely should be prioritized over the other. There's never going to be a situation where you can address every potential source of slowdowns, and make everything 100% efficient all of the time. Given that, in any somewhat realistic environment, you're going to need to prioritize where to spend your focus on making things more efficient.
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.
To try to clarify: none of my 3 points above are fixed by rust, golang, or any other language, because they are not caused by Rails. Uncharitably, in my experience, these 3 bottlenecks are usually accidental consequences of decisions made by software developers who do not fully understand the whole lifecycle of a web application request/response.
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.
That's fine, I never said everything is solved by switching languages. But oftentimes focus in performance in one area, ie language choice, is correlated with performances concerns over other parts of the app.
Apps and sites are pushed out fast, crammed with the everything including the kitchen sink and monetised to the hilt. This is more the reason why they suck these days, rather than because programmers are modelling abstractions from the human end rather than the machine end.
Hm, it's also because we use dynamic languages with shitty implementations. JavaScript has been optimized to hell, it has a proper JIT compiler, and it's extremely fast, about half the speed of C in many cases. Python and Ruby are inexcusably slow in comparison. We have the technology to make them fast, but the language implementations were born in the 1990s, at a time where everybody thought single-core performance would always double every 18 months. It's this kind of "performance doesn't matter" mentality that lead to poor implementations and a huge waste of CPU cycles. IMO, those languages will inevitably be displaced for performance reasons. It will take time, but it's inevitable.
I do like LISP, don't get me wrong, but the lack of speed and modern multicore support (actors and transparent parallelization like in Erlang/Elixir) has always put me off.
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.
Common Lisp with SBCL compiles to very efficient code, it can be comparable to C, for example. For multicore support, I'm sure there are good libraries available - lparallel maybe? (https://lparallel.org/overview/)
What don't you like about Rust? I haven't done any of it in anger but I did Advent of Code in it this year and have been having a great time. I miss some stuff like Python's generators and some of the crates I've found (like ndarray and euclid for example) have felt a bit incomplete but overall the language and standard library feel very well thought out and enjoyable to use.
There is a lot of obscure error messages surrounding lifetimes and borrowing. Most of the time I would have immediately fixed my problem by being told "you are returning a reference to the insides of a temporary structure, either clone it or make the structure's lifetime `static`" but no, I have to get an error about not implementing a certain trait with anonymous type parameter... :(
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.
Thanks for this reminder, will do as well! Overwhelmingly I've actually been really impressed with the quality of the compiler diagnostics— 9 times out of 10 the prompt is telling me exactly what I need to do. I will try to do a better job of keeping track of the occasional bad/baffling ones.
And yet Ruby has a global interpreter lock and is an interpreted language. Ruby, I assume as a language, has had all the time in the world to develop well. Why don't we fully utilize our hardware while still allowing for high usability such as with Rust with algebraic data types or (if you don't want to deal with a borrow checker) recent C++ with auto pointers, or Haskell which is garbage collected but is still quite fast and of course highly expressive?
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.
Fully agree, using Tcl as Apache/IIS plugin in our own AOLServer inspired application server, while a pleasant experience, has taught me to never again use scripting languages for anything other than OS scripting tasks.
Sure, but the pendulum has swung so far in the "I optimize for dev time not server time" that people are forgetting how to write fast, efficient programs, and we the end users have to put up with that garbage like Electron.
There is this meme that Electron is so bad but as an end user I have much better experiences with Electron apps like Slack and Discord then I do with Microsoft Teams or other competitor apps that don’t use Electron.
Is Microsoft Teams supposed to be the fast, efficient alternative because I don’t think so...
The problem with Teams is that Teams doesn't have to sell based on user experience. Its sales pitch is "you already paid for an Exchange server or Office 365, so this is ready to go".
Haha guess it wasn’t such a good example then, I had no idea. But I do think Slack or Discord works as well as native Mac apps from the user perspective. I can’t really tell the difference between Atom and say the old Sublime Text or Textmate. If you told me they were all Electron I’d believe you other than Textmate being so old that it couldn’t have been when I used it
Electron afaik wasn't created because "people forgot" but because it's by far the easiest way to create a platform independent UI that's heavily customisable.
Web site bloat is largely due to web applications being optimised for product managers. Tracking, ad partners, etc...aren’t there for the developers benefit any more than they’re there for the end user.
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.
Why? Why do we have to make apps run fast? I run a self-hosted install of ArchiveBox and it takes > 10s to archive a webpage. If I am saving the page to retrieve it in a few years, I can surely wait 10-20s. One can say that an optimised setup may load and render a page in under 2s but why?
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!
Speed matters. As a matter of UX, it feels good. People can tell when things instantly open up and load versus being sluggish. And it's also a matter of beauty. I like and appreciate things that fully utilize their forms. In software, it's apps that fully utilize the hardware. I was playing Doom Eternal the other day and it was just amazing the fluidity I got.
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 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.
True, but again this is the case where the primary function of an editor is to edit, so people naturally get upset when editing is slow. But if only Slack worked as nearly as good as VSCode does, I think we wouldn't be trashing Electron so much.
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.
Right, but then you are not just a developer but also a product designer/manager (in some capacity). 3 (30) developers would happily develop 3 native apps if a company was to pay them.
But speed doesn't come for free. You need to spend time either using a lower level language or improving algorythms, time that could be used to add functionality to the product. Speed can be a feature, but one of many.
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.
You would have a hard time naming a AAA game which doesn't have a huge chunk of its actual gameplay logic in a scripting language (or something like Unreal blueprints). There's a huge amount of value in using different tools for the performance-critical parts vs the rest.
The programming language is often only a (relatively small) part of this problem. The choice of the framework (or, I'd say, the pollution of frameworks, as well as 40 MB libraries only imported to do dependency injection), wrong abstractions, wrong data models (if I'd had a penny for every time I've seen some code do a full list scan when it could have indexed the objects into a map I'd be millionaire by now), over-engineering, frameworks that reinvent the wheel (often in a much less optimal way, all in order to provide the developer with a bit of syntactical sugar), they all play a much bigger role in performance degradation than the language itself.
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.
Oh, one more reason I forgot in the case of webapps: 3rd-party scripts and trackers. I've been using NoScript for years now, and that forces me to explicitly whitelist any domain used for scripts on a website. Once you start looking at what major websites do, you start to understand the problem. Most of the newspapers on the web, for example, often employ 20 additional script domains on top of their own - for anything from analytics, to tracking, cookie banners, ads, adblock detectors, Hotjar, Taboola, and so on.
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
This problem is real, but addressing it in the context of Ruby is misguided.
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.
i think this has less to do with "concentrating on humans" vs machines and more to do with "business requirements" that are ever-changing which causes insufficient time to work on optimization and siplification... all we get are piles of code upon piles of code...
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...
I agree with the general sentiment but it has been brought to an extreme to the point that things in many dynamic languages are way too slow. Maybe some of the CS courses are to blame; people think "hey, let me make my own language and an interpreter!" -- and the rest is history.
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.
> things in many dynamic languages are way too slow
"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."
I agree. When I think Ruby it brings to mind the Chef code base. Massive amounts of indirection via one line, but only one time used?, methods. Mixin abuse requiring manually searching an ungodly number of files to figure out where behavior is coming from. Errors pointing to non-existent lines of code because somebody thought it was a good idea to generate classes in loop to avoid boiler plate. Sandi Metz' "come to Jesus" book.
As a computer engineer you need to focus on computers, not people. I know this is popular right now, but it sucks and it is wrong and leads to bad results. Yes, the current state of affairs is a "bad result", young ones.
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.
At the design level where stresses strains and loads are the considerations, it’s nothing about the people. I think that’s the level the parent was thinking of.
The fact that all static languages are adding an Any type means the discussion is settled.
Lol. How has this settled anything? You think Ruby devs from now on are all gonna use Sorbet or RBS? I highly doubt it. Some very unique companies like Shopify or Github, which don't really represent the average Ruby shop, may make a limited use of these tools. The vast majority won't.
>The fact that all static languages are adding an Any type means the discussion is settled.
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.
Which was added to support COM variant types as main goal, and as side effect of trying to make the CLR a good target for Python and Ruby, an effort that has mostly died and is kept around just for backwards compatibility.
They add an "Any" type because they have no choice, what are you on about? You can't change a dynamic language to a statically typed language overnight. Or over a year. Or five.
You are not furthering your argument, you are just reasserting the status quo.
Okay you convinced me to stick with my assessment of ruby. I regret every single time I have chosen to write something in ruby. I guess this release won't change that if nobody uses these features.
No, it won't. If you don't like it you don't like it, it's alright. I'm not trying to convince anyone to do anything most of the time, stick to what makes you happy and productive.
> The fact that all dynamic languages have adopted some kind of static verification tool has settled the discussion.
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.
It was, back when all mainstream statically typed languages had atrocious UX and there really was no good example of a language with ergonomic typing. Even now, there are very few languages around which has that. The most ergonomic I know of is Crystal, which is not surprising considering its heritage.
Both Python and Ruby have grafted on new features to support type checking and concurrency. I would much rather just use Go, which was designed with these features baked in right from the start. Simpler, cleaner, and faster.
Ruby is nice but I lament that it's a dynamic interpreted language. As I said in another comment, it's a shame we don't fully utilize our hardware and instead throw away our gains by piling on more useless abstractions in the name of "human experience". Spoiler alert, other languages can have good UX and still be fast, like Rust with algebraic data types, modern C++ with auto pointers, Haskell despite its garbage collected nature, Nim which is like a compiled Python, or hell, even Crystal which is like a compiled Ruby.
On a tangent, Python has a static type system. It's been a part of the language for years now. It works much better than TypeScript– I would say it's as flexible as Haskell's type system while being extremely easy to use and catching many bugs.
def sum(a: int, b: int) -> int: ...
Unlike Ruby and JavaScript, Python is strongly typed. You can't add a string to a number, for example. Because it's strongly typed, it's much easier to add a type system. When I first started using the type system, it felt like it was always a part of the language, they just added a syntax and a checker. It doesn't restrain me from what I would otherwise normally do in the language like TypeScript or Flow does. It's a perfect fit.
