Jet's literally got us off the ground and to the point where we could handle spikes where we scale up 1000x to handle hundreds of thousands of messages per second and then immediately scale back down 1000x because of the spikey nature of our workload.
Almost all of the traditional issues one encounters when running a Rails app in production vanish when you build on top of Jets, as scaling just becomes something that happens automatically without you worrying too much about it other than at the database level.
One thing that was particularly impressive about Jets is its whole ApplicationJob system that provides an easy-to-use API for writing lambda fan-out routines, which we used as the crux of our message scheduling and processing system https://docs.rubyonjets.com/docs/jobs/
Anyway, I mostly work in Rust now but still am and will always be a huge fan of the project and Tung Nguyen, its creator :)
How much more do you estimate, very roughly, it costs to use the serverless stuff in "normal times" outside of spikes compared to a more traditional system?
normal times was well within the free tier, and this was even with a pre-warm job turned on for our endpoints. Even the spikes were not very expensive. Back then 80% of our bill was RDS and I think we were paying under $50/mo for beyond-free-tier usage of lambda. It was a tiny fraction of what the cost was when we had EC2 clusters.
If you're ok with cold-starts on less-used routes you could probably make any medium to low traffic app run totally free on jets (other than db)
I guess this is a serverless thing rather than Jets-specific? Has anyone had this experience in NextJS using serverless erm... servers? Maybe Vercel themselves (or Lambda etc.)
What's really special about Jets in particular is it lets you have your cake and eat it too, in that locally you have what feels like a pretty normal monolithic Rails app, but when you deploy every endpoint magically becomes its own lambda...
To be fair that’s exactly what NextJS does too. In dev everything runs locally, when you deploy to Vercel or a similarly capable host each non-static route becomes a lambda.
He says quite clearly in the GP. It solved all their scaling problems and massively reduced their costs. With a note that their traffic was particularly bursty.
Does the “lambda per api endpoint” part help with the application boot part or something? Otherwise I don’t quite see what advantage you would with that get over just one lambda for the entire monolith.
OC also mentions that they run a job to keep the lambdas warm. One disadvantage with the lambda per endpoint is that he has to keep dozens of lambdas warm instead of just one.
Dead code/dependency removal. "Tree shaking". If you only serve one route per lambda, you can be (somewhat) sure about what you need and compile the minimal optimized code path for that.
Less "stuff" in each route, less boot/warmup time for each lambda.
I tend to agree that in a lot of cases just sticking the whole monolith in a single lambda is fine, and that's probably how I would do it if I had to do things manually. But as things grow, it becomes much better to tree-shake unused routes, though dead code detection in Ruby might as well be a pseudo-science with all that Ruby can do lol
I tried Jets a couple years back. I wanted the ease of Rails, but with (ostensibly) a cheaper AWS bill.
Actually writing your app and testing it is just as easy as it is with Rails. That's good. The hellish cryptic errors when it borks a CloudFormation config? Not so good. Ultimately I gave up and went back to Rails.
With Jets, you still have to keep in mind that the infrastructure is way more complex than Rails. Jets tries to hide away that complexity, and it does a good job... until it doesn't. If you're an AWS expert (I'm not) then this is a great tool and you should try it. If you aren't, just stick with Rails.
I've had great success running Rails apps with Google Run. If you can live with the initial request sometimes taking 1-2s it's great. All my usage is within the free tier and once it's set up with Google Build, it's fire and forget
You can have your cake and eat it, too. Have a minimum of 1 instance "on", with the CPU in low-power mode until a request comes. This way, you get low cost in idle times without cold starts.
Love seeing non-rails ruby stuff. This project looks cool...In general I think most people should avoid lambdas except for very specific types of workloads, but I hope projects like this allow ruby/rails devs to feel a bit more comfortable building lambda functions when they do need one.
Likewise, non-rails ruby stuff doesn't get nearly enough love. I still use and love Sinatra for small apps quick PoCs/demos/tools. So wonderfully stable and mature, and does what it needs to do.
Check out hanami next time you're starting something new. It's a little more complex than sinatra, but really gels with how I like to architect things. It's basically "what if dry-rb had a web framework"?
Oh yeah! I still have two sites powered by Jekyll, and that thing has been a rock. So refreshing compared to the other worlds of constant churn and breakage
What's wrong with lambda? If you write a monolithic app that serves your rest API via lambda that pattern can be very powerful. What alternative for such a use case would your recommend instead?
There's nothing inherently wrong with lambda/serverless platforms, but I feel like most people are better suited by a regular app server running somewhere "normally".
I'm not going to pretend I'm a domain expert here, but from my own experience I see several common themes: Serverless has the potential to increase complexity and potential problem points. Scaling isn't as simple. Debugging backend issues can be more complicated. Extra latency when bolting together lots of different serverless things to make one cohesive application. Increased vendor lock-in.
I think they're best for certain types of workloads (simple POCs or small side projects with little load can be run virtually free on any serverless platform these days, very bursty/erratic workloads, or workloads run seldomly/ones where a cold start isn't a problem), but not for most use "regular" use-cases.
Ya I miss the time when Rails was used 2 out 3 times in startups. It has it flows but dang the DX and the features it has. And the speed you ship things. Even Java with its massive ecosystem and devs doesn’t have an all packed solution like Rails but it gets closer with Spring Boot but not equal or better. Maybe Phoenix? We are getting there with TS but you have to use 30 different packages and glue and config the whole thing before even beginning to code anything.
Is Flame actually ready for production use yet? I just saw it the first time a couple days ago but no idea how long it's been simmering.
Flame seems very different to me than Jets though. Flame just plugs into a Phoenix app and lets you trivially async some application code on a different node through the existing erlang functionality without having to manually sync memory/state/etc. Definitely cool, but seems fundamentally different than Jets which uses traditional "serverless"
Flame was announced two days ago - the above linked blog post is the announcement post. So I'm not sure anyone is using it in production yet except fly.io, its creator.
Tung Nguyen who runs this project has done a stellar job managing it. He is super responsive and it is amazing how much time and effort he's put into it. I've been pretty active with Jets for the last 4 years.
Ruby is absolutely worth learning. It's a nice combination of OO and functional programming, and I find it nice to both read and write. It's very expressive; I find it easier to model my ideas in Ruby than many other languages.
The job market seems healthy and stable, but I'm not a reliable source on that.
Outside of web development, Ruby is an excellent scripting language, that's perhaps where it excels best.
Agreed, Ruby the language is fantastic for ease of use starting, then more complex concepts ready to go (functional programming, WASM, C interopt, etc) when you're ready to dive into them.
IMO the jury is still out on its recent changes to make things faster and statically typed. With so many other options in the script-language space (Python and Javascript being biggest by market share) it's difficult to grab a bigger piece of the pie, even if the newer features would be 100% perfect with no downsides.
As far as jobs, most will be tied to Ruby on Rails - the Rails framework of course being built on top of Ruby the language. And I'll mention Rails is also worth at least trying out, to see for yourself what it does and how it works.
Ruby is a super nice scripting language. I much prefer it to python when I need something with a little more "ooomph" than bash. It's just...nice...to write in. Ruby performance has come a long way in the last decade as well. There's libraries for pretty much everything.
My modern programming toolkit is basically golang + ruby + bash and I am never left wanting.
I do find Crystal (https://crystal-lang.org/) really interesting and am hoping it has its own "ruby on rails" moment that helps the language reach a tipping point in popularity. All the beauty of ruby with all of the speed of Go (and then some, it often compares favorably to languages like rust in benchmarks).
> I actually compile my Ruby scripts with Crystal when I want a portable binary!
Na, you probably don't do it, but you think you could do it. Until you really have to do it and then you see that Crystal isn't a drop-in replacement for ruby. Anyway.. if every single "Dude use Crystal" person commenting on HN would be actually using Crystal, what huge community we would have ;)
> Na, you probably don't do it, but you think you could do it.
That's a weird response.
I actually do it, there is no reason for me to lie.
Keep in mind that I don't use any gems. That is why it works.
Crystal is not an drop-in replacement because some features Ruby has does not work in Crystal, but you can just write it in another way that Crystal supports.
If you're being serious, then you're sticking very intentionally to the very small subset of Ruby that compiles to Crystal and missing out, unnecessarily, on the very amazing features that both languages offer to no great advantage.
I tried this very thing, and very quickly started looking for other options, landing on mruby. Compiled mruby is almost as fast as just writing bare C. I just compile an mruby interpreter and use that to run .rb files when I want speed. It's fast enough for me.
Much, much better than trying to shoehorn Crystal into this role.
You're right, Crystal might not be the best choice but it does the job so far.
Shipping compiled binaries is so sweet, having to force every user to install the Ruby runtime isn't fun.
Thanks for the tip, looks like mruby is even a better way to provide portable ruby scripts. I'll check it out.
> Compiled mruby is almost as fast as just writing bare C.
That's interesting!
Just tried mruby and it seems to work very well, the packages seems enough for me aswell.
https://mruby.org/libraries
You're using the wrong option, the one you want is at the bottom, where you use the -B option to dump the bytecode into a C array, which you then wrap with a bit of boilerplate so as to compile into a standard executable. Once you understand it it should be easy enough to script.
The job market for Ruby is doing just fine (though, I presume you mean Rails - not many of us work mostly on non-Rails Ruby stuff, though for me that's what I prefer), but generally getting too stuck into a specific language is not great for job advancement for most people. I'm not currently in a Ruby focused job, but my last one was, and I had several offers for Ruby jobs before I landed where I am now - in the end it came down to details of the offers. If you want to maximise your pay, Ruby is not where the highest paid jobs are right now - salaries are fine, but not the very top (the offers I turned down were within 10%-20% of the one I ended up taking; other factors weighed more).
I use Ruby mostly for non-web things. Some things non-web I've used Ruby for:
* Orchestrator for a hybrid cloud (1000+ vm's so not huge but also not trivial; spread across on-prem, colo, several managed providers and a few VMs)
* Queuing system (think Sidekiq, but sadly not opensourced)
* Financial modelling and analysis at a VC fund. Processing round data and doing simulations of different allocation strategies.
* Lots of devops scripting
* Distributed map tile rendering, and PDF generation of maps.
* Personal projects:
* My personal X11 tiling window manager (that I'm able to post means it's now somewhat stable ;) - Chrome does *not* like window manager quirks ) - this one was started a couple of weeks ago and is now my only window manager (though my requirements of a window manager are basic and specific; I replaced bspwm and used only a small portion of bspwm's features)
* My personal text editor
* My personal terminal (this uses pure-Ruby X11 bindings, and a pure-Ruby font-renderer)
* File manager (very basic; replaced Caja for me, but only because I hardly do any file management via GUI - it's mostly a launcher)
(only some of the lower level parts of these projects are open-source so far, mostly due to me being to lazy to tidy them up for release, but will get there eventually. Other than Chrome and a PDF viewer pretty much everything else "visible" I use day to day on my own machine is Ruby)
Did you try out using I3's scripting capabilities before setting out to reinvent that wheel? That's the route I'm current on right now, but we seem to be kindred spirits. Discovering IPC has mostly quelled my urge to reinvent wheels. Emacs can easily be communicated with and controlled from Ruby, and I'm still figuring out the right approach to interop with Firefox. I think eventually I'll just use a terminal from inside of Emacs.
Both i3wm and bspwm. I must admit part of it was probably the fun of it, but the main consideration was a number of small nuisances.
E.g. I prefer the minimalism of bspwm to i3wm, but bspwm insists on placing a window that has _NET_WM_WINDOW_TYPE_DESKTOP on all desktops. That follows the EWMH spec, and makes sense for a floating wm, but not for a tiling one - if you use a file manager you end up with a file manager that expects to be able to open floating windows all over the place behind all your tiling windows on your tiling desktops too. There are other wm's that deviate on this - e.g. Katriawm does it the way I prefer for this specific case.
(Basically I want one or more floating desktops, and the rest tiling; on the floating desktops I want a file manager that is always at the bottom of the stacking)
I'm sure it's reasonably easy to fix, but there were more nuisances like that, and when I started digging into the bspwm codebase to consider fixing that and a few other issues (e.g there's no trivial way of making all windows on a specific desktop floating without running a script that waits for events, which means you often get "flashes" when windows opens first in tiling mode before being modified), I realised it was a toss-up whether being stuck fixing issues in a code base that size would be more enjoyable than just writing one from the scratch.
My wm is currently ~680 lines of Ruby, with no dependencies at all on native extensions (the X11 gem I extended from an abandoned starting point speaks directly to the X server with no Xlib involved). Bspwm's IPC support alone is 2KLOC, it's layout tree support is 2.3KLOC. There are many more files.
This is not to criticise it - it's very clean for C, and has far more capabilities than my wm will ever get because have no interest in adding much. i3wm similarly is very clean code, but it's also "big" and complex.
When I started building my own, I rewrote tinywm from C with this hacky little thing[1] and then just iterated. That's how little it takes for the bare minimum floating wm - ironically making a decent tiling wm takes far more code than floating - both bspwm and i3wm spend a considerable amount of code on their tree management.
I have nowhere near parity with bspwm, but I'm ~90% there in terms of the functionality I use, and so don't have to deal with several of the little annoyances I wanted to fix in bspwm.
I expect mine to grow a bit, but not much, because I have no intention of catering to "the general public" (of tiling window manager users, so all 12 of us) - I'll split out anything that is generic enough in gems, so that it may be of help to anyone else who wants to go down the same path, but I see these projects of mine as being my configuration. As such they'll be extremely opinionated, and rude about it. Generic stuff will be torn out, step by step, until all that is left is the bits specific to me.
With respect to the IPC, I'm fully with you that having IPC helps and I wish more tools embraced minimalism based on cooperating scripts. My entire environment is focused on composability via IPC or spawning separate scripts controlled via pipes. My file selector, theme selector, and buffer selection in my editor all call out to scripts that default to using rofi for example. It's also the only reason I didn't replace my WM many years ago.
Ironically both i3wm and bspwm reinvented the wheel on that one, when most of their needs can be met with even just XSendEvent, and the rest can be met with selections. My wm doesn't need a special client because any client like xdo etc. that can trigger XSendEvent works.
The complexity of the existing options and my config is the same thing that led me to write my own editor - Emacs is far more capable, but I only ever used 1% of that, but to try to shape Emacs into what I wanted I ended up with a bunch of elisp packages and a couple of thousand lines of my own config. My own editor, on the other hand, is ~4k lines that I know inside and out and so it's far easier for me when I want to tweak my workflow (incidentally it's also heavily IPC based - all buffers are held in a separate process and frontends operate on that, so each frontend only know how to show a single file because you can just attach another frontend with a single key-combo so why bother supporting multiple windows or spltis)
Similar thing with Polybar, which I mostly replaced in anger last night because it was less effort to write my own (<100 lines) workspace switcher than to get Polybar to build with the new EWMH based switcher module on my system. Too many tools are too big and complex.
Of course, had I not enjoyed coding for the sake of it, I would have made do. I do feel my resulting environment is nicer and more productive, but not enough to justify embarking on this rewrite spree if it wasn't fun too.
Thanks for this writeup, I really appreciate it! I love coding too, but not enough to do it in my off time, my body screams at me too much, but I was recently released from my corporate job where I had to use MacOS so now I can spend more time on it now. Never taking another job where I can't control my computing environment.
Someone was watching me work in a bar and saying he'd pay for software that could help him do all that. I could only laugh.
I do end up using a lot of Emacs' functionality, and will more likely just use it's shell functionality when I feel the need to learn how it works. If I do end up rewriting something it would be a browser, I think. Webkit is annoying but maybe not as annoying as Firefox. Can't be too hard to wrap Ruby around it and make something basic.
I'd love to see clean Ruby bindings for a modern browser engine - I don't really care which... Being able to customise it more easily would be fantastic..
Totes should learn Ruby :) One of the most important things to learn in Ruby is a sense of "this should be easy" - if you're doing something, and it's hard, often times that's because there's a different approach that's not only easy, but once you're doing it that way you realize it was the Right Way All Along.
Job market - At Rubyconf, the part of the literal job board looking for seniors was full, but the junior/mid were crickets. I think that's the case pretty much everywhere tho, so.
People have been saying its dying for years, yet here we are. Your reasoning doesn't quite make sense, not everyone wants or needs to do ML - choose the right tool for the job.
In absolute numbers it may be doing fine. Steadily growing even (I don't think it is).
But in relative numbers, that means a significant decline. In many niches and usecase, that practically means obsolence. Keep in mind that the amount of new people in software development have been almost doubling each year, for decades.
I'm in Ruby and Rails fulltime for over 12 years now. Almost all the work I come across is either legacy, maintenance, upgrading or untangling spaghetti.
One reason for that may be that Rails is optimized for "one man shops", which by nature aren't jobs people have vacancies or hires for.
But the more logical reason is that people just don't start new projects in Rails anymore. Not on a practically significant scale, anyway. For every new rails project, there's probably hundreds of python, typescript, rust, Java and PHP projects. In web alone.
Something can be dying for years and not be dead. Other languages (python, golang, rust, ts) left ruby behind. Even big tech companies founded on rails have diversified their tech (Airbnb, Github, Stripe, etc.).
Most companies will have an DS/ML team. "ruby" doesn't scale (in that you can't write efficient ruby code that can process data at the same level as python/c++ can without writing c-extensions to the underyling cpp libraries).
> "ruby" doesn't scale (in that you can't write efficient ruby code that can process data at the same level as python/c++ can without writing c-extensions to the underyling cpp libraries).
Wait, excuse me, I thought people did not use "python" for high performance code either.
They use a module of compiled fortran/C/C++ or a FFI interface, that happens to be in python. Calling this mass of external modules "python" is extremely naive to me.
Using this naive definition that "X solution is in Y language if it is started in Y language" almost all high performance code in existence is in bash and systemd units.
Great! I understand that ruby has similar access to this "mass of external modules", but where are they? If I need to support face recognition, nudity detection, or recommendation engine, how do I `gem install` them into a sidekiq worker?
Most LLM client code uses LangChain (or that MS one, I forget the name). Where is the ruby equivalent?
From what I saw on several LLM projects, they usually don't use LangChain at all - if they really care about performance, they go straight to huggingface/transformers or even directly to pytorch.
If you want use PyTorch and you're dead-set into using Ruby then you can just FFI LibTorch and you should be fine; torch-rb mostly does that.
Does it work "OK"? Well, I would say for some cases potentially better that Python, but mostly because in python-land version and package management is somewhat of a unmitigated dumpster fire.
LangChain is an API layer wrapping huggingface and/or pytorch. Huggingfacetransformers and pytorch solve a different set of problems than what LangChain solves.
I understand that, but most programmers want the simple `pip install` `gem install` flow to work, without needing to create their own bindings code.
torch-rb offers the barebones. You'd still need to re-implement the model from whitepapers or translate the python version.
You come off as an extremely bitter person. Why so much anger directed at a programming language (of all things)?
Companies you mention HAD to scale up, then their stacks diversified... hell, Facebook was built on PHP, and when he time came for a chat functionality to be implemented they used Erlang, not because PHP is shit, but because concurrency and resiliency was better handled by a different programming language...
Realistically, most applications will never need to scale up. So what's wrong with a nice framework that allows people to just get stuff done?
Umm...pointing to facts based on real data isn't bitter. Did you see even look at the graph that was shared? It's pretty clear ruby is trending downward and I say this as a past long-time ruby advocate and fan.
I think that you're conflating correlation with causation. I think it's more plausible to assume it was the early numbers that are skewed and non-representative.
The fact that GitHub itself was is a killer app of the Ruby on Rails, and that the Rails project itself changed to being hosted on GitHub somewhat very early on it's history [1] had a disproportionate effect on the early community that gathered there.
Now GitHub attracts a much more diverse portfolio of projects, so the numbers you see there are less statistically biased towards early Ruby on Rails adopters.
> Realistically, most applications will never need to scale up. So what's wrong with a nice framework that allows people to just get stuff done?
I've coded with Rails since Rails 3.
There are a few issues with rails:
1/ DHH never gets JS right. CoffeeScript, Asset pipeline, and now the new Turbo. Migrating your FE every 3-5 years to a new language stack is the opposite of "get stuff done"
2/ Rails is built for b2b apps (Basecamp). If your business looks like basecamp, then the conventions will work for you, but if it doesn't (think b2c apps), it won't. Examples: ActiveStorage was a mess with no CDN support (it is better now though), Action Cable only supports a handful of connections compared to nodejs.
3/ No ML support.
If you want a framework that "allows people to just get stuff done" then use Django. It is similar to rails and has all the bells and whistles of the ML community.
That graph is a bit deceptive, it shows Ruby dropping from 19% of commits to 5% of commits. However, since inception GitHub grew by far more than a factor of 4 with GitHub leaving the initial Rails bubble and the rest of the world getting on board.
So in absolute terms the number of Ruby commits grew over that time span, it's not declining, and certainly not dying.
It might be not dying but, for example, our company banned new apps to be build with Ruby and Javascript, instead new apps needs to be build with Go or Rust, existing apps will continue to be written in Ruby and no plans to migrate to other languages, but at some point I think it would be migrated and/or deprecated.
The benefits to go or rust isn't hands-on-the-keyboard developer velocity. Servers in Golang or rust will run faster (lower cloud costs). It also has lower risk of bugs and side effects.
Coding in go is slower than ruby, but debugging go code is 100x easier than debugging ruby or python code.
Once companies hit a certain size, the zoom-meeting time or system design time is an order of magnitude greater than coding time.
This is pretty cool. For folks on GCP, does it make more sense to use vanilla rails with cloud run? I wish lambda had the ability to share processes like cloud run with a max concurrency setting.
Lambda doesn't allow websockets in the way you might expect. However, you can use the WS feature of API Gateway[1] to implement WS serverlessly in AWS.
Jet's literally got us off the ground and to the point where we could handle spikes where we scale up 1000x to handle hundreds of thousands of messages per second and then immediately scale back down 1000x because of the spikey nature of our workload.
Almost all of the traditional issues one encounters when running a Rails app in production vanish when you build on top of Jets, as scaling just becomes something that happens automatically without you worrying too much about it other than at the database level.
One thing that was particularly impressive about Jets is its whole ApplicationJob system that provides an easy-to-use API for writing lambda fan-out routines, which we used as the crux of our message scheduling and processing system https://docs.rubyonjets.com/docs/jobs/
Anyway, I mostly work in Rust now but still am and will always be a huge fan of the project and Tung Nguyen, its creator :)