Former CTO at Arist (YC S'20) here.
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 :)
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
Cloud Run? Did you do any work to get cold boots faster?
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.
https://cloud.google.com/blog/products/serverless/cloud-run-...
They say in the blog post those instances are charged a very reduced value when idle. IIRC something in the order of 20-30% of the original one.
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.
Same, I almost always default to Sinatra. Love me some Rails for all the powerful stuff though.
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"?
I've done enough with dry-rb to know I don't want to try Hanami.
I think at that point it's just better to switch to something truly functional like Elixir.
> I think at that point it's just better to switch to something truly functional like Elixir.
Well, yes, and I did ;) but since we were talking about ruby...
Not to mention Jekyll
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.
Anything that gets more Ruby out in the world is positive in my book. Great looking project!
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.
> Maybe Phoenix?
Yes
If people aren't familiar, there's a similar project for Python that's fantastic: https://github.com/zappa/Zappa
There is one for Elixir too, Flame: https://fly.io/blog/rethinking-serverless-with-flame/
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.
That looks similar to Chalice (also for Python)
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.
Thanks!
Jets 5 was just released also https://blog.boltops.com/2023/12/05/jets-5-improvements-galo...
I've learned and previously also professionally worked with: JavaScript, TypeScript, PHP, Clojure, ClojureScript.
I really like the ergonomics of Ruby. Should I learn it? How's the job market (decreasing|stable|increasing)? Is Ruby also good for non-web things?
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.
[edit: added reference to JavaScript]
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!
The Crystal comment that we were missing
> 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 ;)
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.
The rails community is working on building out a job listing site, worth checking out: https://jobs.rubyonrails.org/
I was totally unaware of this. Thanks for sharing the link, time to go find a new job!
I've been seeing a lot of job postings mentioning rails recently
Based on your FP background, you might want look into Elixir. Ergonomics of Ruby, FP ideas from lisp and scalability/concurrency of Erlang.
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.
[1] https://gist.github.com/vidarh/1cdbfcdf3cfd8d25a247243963e55...
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.
I've coded in rails for 7+ years. imho, its a dying language.
Better to learn Python, b/c if you want to do anything with ML, you have to use Python.
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).
checkout how ruby has fallen off a cliff on github: https://madnight.github.io/githut/#/pull_requests/2023/3
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?
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.
> 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.
can't recall the last time i was on a project's page and everything just clicked. no fluff. kudos to the team!
Related:
Ruby on Jets: Like Rails but serverless - https://news.ycombinator.com/item?id=34474049 - Jan 2023 (84 comments)
Jets: Ruby Serverless Framework - https://news.ycombinator.com/item?id=19893796 - May 2019 (39 comments)
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.
Nice, looks like the Ruby equivalent of sst.dev for folks that prefer Typescript.
Missed opportunity to call it Ruby on Rockets XD
Is there an example of this to run a web socket?
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.
[1] https://docs.aws.amazon.com/apigateway/latest/developerguide...
Oh thank you for this!
I was a Rails dev for 4 years. After the switch to TypeScript I could never go back.
if you view typescript as equivalent to what rails can provide in development... best of luck to you!
r-r-r-ruby and the jets
How active is this project?
https://github.com/rubyonjets/jets/commits/master/
Pretty active?
It's been pretty consistently active over the last four years from what I've seen
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.
How is making each endpoint a lambda helpful?
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.
https://open-next.js.org/
Thanks Sam!
isn't that just cloud?