Moving on from Rails and What’s Next
blog.seantheprogrammer.comI’ve seen a number of people move from Rails to Rust... is that really a common move? Seems like they’re very different and designed for very different things. Are people commonly building web applications in Rust? I know it’s possible but C++ has web frameworks too and that seems like a more apt comparison.
I guess I’m just baffled by the number of people on here that I see pointing to Rust as the next project they tackle after Rails when I don’t see them overlapping at all.
I can't comment from experience, but I have seen a lot of people here say that Rust feels a lot like something between C++ and Python/Ruby. I think the idea is that besides the static typing (which a lot of people that use Dynamic languages, like me, would love to enforce at times), if you use it in a functional manner it's fairly expressive and not that different looking/feeling that the equivalent dynamic language of large chunks of the code you write. As someone who's gone through the Rust book but not really written anything useful in it, that's how it appears to me sometimes too (and other times it appears to be an arcane incantation).
Edit: The solution here[1] is a good example of what I'm talking about I think. A lot of what's there is pretty obvious to someone familiar with JS/Ruby/Python/Perl, and they might even use a very similar looking solution. The Rust specific stuff is really the only foreign stuff, so if you assume you would learn that when learning the language, it's a pretty straightforward solution that looks similar enough to be inviting.
1: https://stackoverflow.com/questions/31986628/collect-items-f...
Whether it can be used like an more FP-style Python/Ruby is one thing but whether it can replace Rails is a whole other question. This website is dedicated to answering that:
(although looking at it again most of the content links are a bit old, but the library stuff seems current)
I think that a Web framework such as Flask (without the ecosystem of its plugins) or even Falcon can be replaced by a Rust app, as of today. But, I totally agree with the rest of the website. Before replacing a Django or a Rails project, there is some work!
Rust has that feel because it is new. I have no doubt that it will look like c++ in a few years. Full of "must have functions and extensions"
Correct, they are for completely different purposes. I have the feeling that a lot of people (particularly the bloggers/more vocal types) jump into newer languages for no other reason than to position themselves as experts in said language/stack, right when it's getting more popular. I've seen this happen with Ruby/Rails, JavaScript/Node, and now Rust. In this case, it would have made a lot more sense to move to something like Elixir/Phoenix.
I cut my teeth on Ruby and Rails, I've screwed around with Phoenix, and I'm currently infatuated with Rust. Earlier on I thought that, yeah, Rust is a great replacement for C and not something want to write a web app in. So, sure, I've got a bunch of little doodads written in Rust (mostly CLI tools). Now? The fluff I've written in Elixir is getting ported to Rust.
The Rust tooling and community are just that good. I'd rather have to work on some extra verbosity and maybe even maintain my own helper library in Rust than deal with with Elixir/Phoenix at this point. The number one reason is that Elixir deployments are nothing short of a nightmare. I've found the community not particularly helpful or knowledgeable about how things work (and given how many moving pieces are in an Elixir deployment, and how brittle Elixir deployments are, this is a terrible thing). And you're definitely not going to write CLI tools in Elixir (it straight doesn't work with escript in the first place).
Compiling down into a single "static" binary like Rust (and Go) do by default is a huge win for things like this. The quick startup time of a Rust or Go app compared to Ruby or anything JVM based is great for rapid iteration and testing. The tooling around Rust is, in general, fantastic. Being that much of a pleasure to use really makes up for how inappropriate it is to use Rust for most high level web app things.
Phoenix had a lot of promise, but these days I'd much rather go back to Rails or Django (with an eye towards how to migrate to a compiled language) if I needed to churn something out quickly.
This is quite a coincidence as deployment was exactly what I covered in my last YT video. I hear the complaint about deployment a lot, but it really doesn't make sense to me.
If you run mix in production, then it's just like running Rails or Node. You don't get certain features like hot upgrades in production while keeping what's in memory on the server, but you don't get that from Rails/Node/PHP/Python either.
If you want those BEAM releases, then you have to use the Elixir (or Erlang) tools for them. I also encountered a great deal of frustration when working from a different OS, but no more than I did when building Rails apps several years ago.
Now I generally, build with Gitlab CI/CD and deploy from that Gitlab container to my server with Distillery and Edeliver. It lets me use the standard CI/CD tools and have stateful upgrades. I am running Ubuntu on the server, though:
Sorry, I don't get your point for deployment. There are complaints you can make fot everything, but deploying an elixir application boils down to compile, upload, start.
Sure, 2 days of work the first time, which is a negligible amount of time for any real world project (otherwise you are on the wrong language). This if you want a good pipeline. Otherwise it's a couple of hours, but even with rails i always invested a couple of days to have a good pipeline.
Doesn't mean rust does not do it better, but it's really not the point for choosing a language over another. In a big project you have a dedicated person. In a medium project, the investment is very small. In a small project, you are better served by prototyping tools (rails)
I'm currently looking into learning Elixir, but your comment sprinkled some doubts on that.
If deployment was easier in the Elixir world, would you have stuck with it?
Honestly Elixir has been one of the most enjoyable learning experiences I've had in years. Deployment is fine, but there are a few different things to consider (because you can do some really cool stuff using BEAM). But you can just chuck it on Heroku if you want something easy.
I also like Rust a lot, but I find Elixir pretty much frictionless to work in. Rust is basically you vs the compiler for quite a while. I've been using Rust for IoT work but I vastly prefer Elixir for web. And since I've been enjoying it so much I'm gonna start looking at Nerves (https://github.com/nerves-project/nerves) for IoT work as well.
If deployment was easier in the Elixir world, would you have stuck with it?
Perhaps, but Elixir was a very niche product for me. I'd use it for web apps and that's about it. Even then the ecosystem was fairly immature, and I'd only really want to use it in a setting that played to the strengths of Erlang. One of the big problems with the deployments being a gigantic beast is that there are maybe one or two people who understand the tooling around it. Great when it works, really lousy when it doesn't.
With the other languages being discussed (e.g. Rust, Go, Python, Ruby, Clojure, Kotlin) I've found far broader uses. I'm not going to write TUI/GUI apps nor would I write shared libraries with Elixir. Unless escript support was implemented you simply can't write things that depend on a shebang.
There's no harm in learning it, but the key is in being able to go beyond the hype and evaluate when it's worth using the knowledge you've just acquired.
Not sure when you were using Elixir, but releases are a good option for deployment now. This is supported with the distillery library (https://hexdocs.pm/distillery/home.html).
The master version of Elixir also has support for releases https://hexdocs.pm/mix/master/Mix.Tasks.Release.html
Last I checked distillery was Linux only (e.g. does not work on BSD), which is a deal breaker for me. But I wouldn't consider using distillery (and thus Elixir/Phoenix) on any platform given the haphazard nature of the support for distillery. There's exactly one person who knows anything about it and he supports it when he doesn't have anything better to do. Sure, in a smaller shop you could dig into distillery and try to fix things up. But when shit hits the fan, do you want to discover the hidden dependencies (e.g. bash vs POSIX sh)? I wouldn't want to bet on a single point of failure like that.
And the big problem for Elixir is that you don't see that level of mess or siloed knowledge with other languages. Say what you will about something like Capistrano, but it's an order of magnitude easier to dig into and support because it's not mashing together a variety of languages (erlang, bash, elixir). Some languages like anything JVM based (that compile down to JARs), Rust, and Go compile down into single artifacts quite easily. Others like Ruby and Python can be moved around with standard system tools easily enough.
If those are your concerns, then the fact we are adding releases to Elixir core in the upcoming version should solve most of them.
The single point of failure is gone. The code is now maintained by the Elixir Core Team and it should garner more general attention from the community. The amount and complexity of scripts have been reduced drastically and they are statically verified to run on `sh` (no bash). As with everything else in Elixir, we do our best to keep the Erlang <-> Elixir interface pretty clean. You should expect the same level of quality and polish as the remaining of the Elixir tooling.
I am not sure about this point though:
> Others like Ruby and Python can be moved around with standard system tools easily enough.
If you are not using releases, and simply Mix, is Elixir any harder to move around then Ruby and Python? From my understanding, using Mix to run Elixir in prod is a similar experience that both Ruby and Python would provide.
If those are your concerns, then the fact we are adding releases to Elixir core in the upcoming version should solve most of them.
I've articulated my experience in my previous reply to you, but I'll pose this response: that it's taken so long for Elixir to come up with a manageable deployment story makes it seem like deployments are an afterthought with Elixir. If things are better now that's great, but as an ops guy by trade I think that deployments are one of the most important user stories out there.
I suspect one of the reasons people are gravitating towards Rust for things it's not particularly well suited for (like web apps with a ton of business logic) is that the Rust team focuses on important user stories like:
- tooling (human readable error messages, dependency management, portability)
- deployments
- IDE user experience
These are things that Elixir and Phoenix aren't focused on. For example I still get the occasional email from github about the poor souls trying to use distillery on FreeBSD so I don't buy that things have improved that much.
The Elixir tooling is fantastic, not sure where you pulled that one out from. IDE's are unnecessary cruft to the point that I'd call it a language-design smell if you really felt compelled to use one; VSCode is great. Deployments are trivial if you use Gigalixir (which has a free tier) and will be easier in the general case going forward.
I am sorry to hear that you had bad experiences while deploying Elixir. To avoid having others running into the same bad experiences, I would like to point out to some resources and recent improvements in the area for those interested in deploying Elixir.
There are mostly two ways to deploy Elixir. One is the provisioned approach: you install Erlang/Elixir (or you assume it is installed in the machine), then you fetch your project source code, fetch deps, compile them and run your project (in the same way you would run it locally).
The other approach is via releases. A release is a way to package the Erlang VM, Elixir and all of your application code into something you can dropped into production. The downside is that you need to match the target OS and architecture but there are many documented approaches to do so. Today the main tool for performing releases is Distillery and it has great documentation covering AWS, Docker, etc: https://hexdocs.pm/distillery/home.html
In Elixir v1.9, coming out this July, we are incorporating releases as part of the language. You can read more about it in our documentation for master: https://hexdocs.pm/mix/master/Mix.Tasks.Release.html
If you are using a PaaS such as Heroku, it is likely there is already tooling that will take care of it for you, such as the Heroku Elixir buildpack: https://github.com/HashNuke/heroku-buildpack-elixir. There is also Gigalixir, a PaaS specific to Erlang/Elixir: https://gigalixir.com/
Finally, if you want a more structured resource, there is also the Adopting Elixir book (disclaimer! I am one of the authors): https://pragprog.com/book/tvmelixir/adopting-elixir - One third of the book is about production concerns, covering deployment, performance, metrics, monitoring, etc.
If none of this works, you can always reach out to the community in elixirforum.com. I assure you there are more than 2 developers that know about deployment :) and if you still feel like none of the replies about deployment there have been satisfactory, feel free to add me to the conversation there.
> And you're definitely not going to write CLI tools in Elixir (it straight doesn't work with escript in the first place).
I do not understand this comment as Elixir works with escripts just fine. You can build an escript for your project by simply calling `mix escript.build`. This has been available since v1.0 (https://github.com/elixir-lang/elixir/blob/v1.0.0/lib/mix/li...). You can even install escripts directly from Hex (our package manager) since Elixir v1.4 (2.5 years old).
FWIW the last time I tried to use Elixir with escript was with 1.3. The parts that make Elixir interesting for web apps aren't necessarily things you'd be leveraging in scripts and so, unfortunately, instead of waiting around for Elixir to do the things I was interested in I've moved on. There just aren't any killer features in Elixir that would revisit it. If I need lightweight concurrency primitives there's go. If I want immutability by default there's rust. If I want to hack up some scripts that leverage my web app there's Ruby and Python.
I'm deploying to BSD, which distillery does not support. Perhaps there are other people who can grok deployments on Elixir, but none of them have seen fit to (or know how to) resolve these issues. I've seen scattered reports of success in the issues, bitwalker's attitude and general willful lack of engagement was enough to get me to move on from Elixir and not look back. By the time I gave up on Elixir, deployments on BSD had been known broken for months.
I'm used to hitting speed bumps by not deploying to Linux, but Elixir was by far the bumpiest road for the least benefit. For comparison the rust community has been extremely responsive to BSD users of all stripes (incl. dfbsd).
> FWIW the last time I tried to use Elixir with escript was with 1.3.
Interesting, escripts should have worked by then. I assume this was quite some time ago, so you don't have it around anymore, but if you do recall what went wrong I would love to take a look at it. But just to put things in perspective, v1.3 is almost three years old and things have generally evolved since.
> There just aren't any killer features in Elixir that would revisit it.
Well, sometimes the killer feature is having all of that in the same package: immutability, concurrent primitives, scripts, etc.
There are also killer features (although I guess "killer" will depend on the person) that we get from running on the Erlang VM: focus on fault-tolerance and supervisors, concurrency and distribution out-of-the-box, and generally other features coming from processes and the actor model. For example, Phoenix makes an excellent use of all those features to build performant web applications with a focus on real time (Phoenix LiveView being a recent great example). Nerves uses the fault tolerance bits for building embedded software. Etc.
But just to put things in perspective, v1.3 is almost three years old and things have generally evolved since.
But who wants to sit idly and wait for three years for a language to evolve (and regress)? At what point does saying "deployments have been broken with no fix or root cause in sight, let's just sit tight and hope for the best" sound ridiculous?
Were the alternatives to Elixir mediocre I'd consider revisiting it. Were I to see an interesting opening at an Elixir shop, I'd consider it. Would I ever stake my reputation on suggesting Elixir for a new project in a professional environment? Absolutely, 100% no.
Well, sometimes the killer feature is having all of that in the same package: immutability, concurrent primitives, scripts, etc.
I get all of that with rust and I'm not tied to Linux or a petulant maintainer. vOv
I'd be careful about touting performance versus a compiled language like Rust though. Going from Phoenix to Rocket I saw a pretty dramatic speedup in the time it took to serve requests even on my simplest web app (an image gallery). Phoenix wasn't slow, but Rocket was consistently faster.
Edit: OK async on rust is still a shit show, but hey nothing's perfect, right?
> But who wants to sit idly and wait for three years for a language to evolve?
That's not what I meant at all.
Look, I am not trying to invalidate your experience. Nor I am implying you should wait 3 years for things to get fixed. Nor I am saying that Elixir is better than Rust.
I just want to point out that, for someone starting with or using Elixir today, their experience may be different because 3 years is a lot for a language and ecosystem where v1.0 was only 5.5 years ago. Deployment involves many concerns and even if some particular scenarios have not evolved accordingly, you can be sure others have. The same applies to Rust and other languages, they are improving all the time.
I just want to point out that, for someone starting with or using Elixir today, their experience may be different because 3 years is a lot for a language and ecosystem where v1.0 was only 5.5 years ago.
Distillery was (is?) broken less than a year ago. Ending up in a situation where such a key component (deployments) is developed and understood by only one person for such a long period of time speaks very poorly to the oversight and development process of Elixir. Beyond that it creates a distrust that Elixir will continue to work or prioritized appropriately — deployments worked on BSD for some period of time.
The last message I got from Github from BSD user commenting about distillery not working was in February 2019. After that it devolved into "here's how you get distillery working in Docker." That's the kind of low quality engagement I walked away from, and that's the reason I continue to recommend against Elixir or Phoenix for new projects.
> In this case, it would have made a lot more sense to move to something like Elixir/Phoenix.
In this case it's about someone involved in both languages already moving from being primarily (or identifying as) a Rails committer to a Rust ecosystem committer (for which he's already written a few very popular modules over the past couple years). This isn't the usual "I tried some new language and I like it" blog post, so I'm not sure your assessment holds true, for this case at least.
I think this is one of the reasons the Rust community is so much more focused on web related technologies than other software. Web servers are where most of the community is coming from and how they make a living so it makes sense. TUIs are also popular but I would love to see more emphasis on getting cross platform GUIs working (as well as kernels, codecs, drivers, graphics, data science, etc).
Mmstick had a good post about this two months ago: https://www.reddit.com/r/rust/comments/af43dy/rust_windows_g...
I tend to agree with those that suggest OO languages are far better suited for GUIs than Rust. I love traits, but all the GUI libraries for Rust I've seen are hot messes. The TUI stuff isn't much better (e.g. Cursive is borked on Windows).
I'd LOVE to see something along the lines of Qt for Rust, but I'm not going to hold my breath.
I don't see rust as a natural move from Ruby at all. I think it's just people moving to next cool language. A few years ago when Go was at the peak of the hype cycle, you saw a lot of people moving there from Rails.
Rails to Phoenix/Elixr makes some sense. As for me, I'm moving backwards in the hype cycle. I started out with Ruby as my first programming language 15 years ago, but I'm spending more and more time in C# these day.s
Which I think is a testament to the expressiveness and readability of Ruby and Elixir and how powerful some of the libraries are. Once you get past the superficial, they're nothing alike.
That said, I agree that anything you build in Ruby can be done in Elixir and you should be able to leverage a lot of benefit. The reverse isn't true.
C# and TypeScript make for a powerful combination when developing web-based solutions, with the added benefit of making you flexible to switch over into desktop or server applications. Or, if you're feeling froggy, an entire OS (Cosmos).
Doesn't it feel so much nicer to just focus on the domain problems of new tasks without relearning how to talk to the computer?
Which is why I prefer platform languages, slowly adopting the best parts of trendy languages, no need to keep switching to the next shinning thing.
Pick platforms, not languages. But always learn what the others bring into the table as well.
I think it's less about the working style and more about the promise of working in the future(tm).
When Rails 0.9 dropped in 2004, I instantly rewrote my old PHP app in it and never looked back. It just felt so expressive and naturally declarative.
Rust has a similar amount of promise, though not quite as good of a demo. The idea that you can write high-performance code without typical high-performance code bugs is amazing! There's a whole new type of type system that ensures it!
Sometimes you want your language to also be a religion ;)
I just can't see how Rust is a good choice for web dev. There's a lot of mental overhead to writing Rust. Something like C#/Kotlin/Go will avoid all the same bugs and give you 95% of the performance while being much easier to code.> The idea that you can write high-performance code without > typical high-performance code bugs is amazing! There's a whole > new type of type system that ensures it!I just can't see how Rust is a good choice for web dev. There's a lot of mental overhead to writing Rust. Something like C#/Kotlin/Go will avoid all the same bugs and give you 95% of the performance while being much easier to code.
Rust is dramatically lower level than something like Ruby or Python. But sometimes the promise of really usable dependency and project management with something like Cargo wins out over the minimalist approach that Go takes. Rust (and something like Rocket.rs) wouldn't be my first choice for anything other than smaller personal projects, but it's not nearly as awkward as PHP was before it matured... and it's nowhere near as bad as rolling everything from scratch in C++.
It also depends on your target audience. My experience has been that Rust is significantly more portable than C#, Node, Elixir, and (to some extent) Go. Java (and by extension things like Kotlin and Clojure) have a big leg up here too.
I doubt that given the amount of hardware platforms with support for Java and C#.
Rust catches some more bugs than at least C# by having a more expressive type system (sum types), read-only being default, class/strict members always needing to be initialized.
Covered by F#, while still having access to a large set of .NET libraries.
.NET is a multi-language platform, with support out of the box for C#, F#, VB.NET, C++ and many others with MSIL backends.
Rust also promises concurrency without data races.
I did not read TFA, but I think the reason people go from Ruby on Rails to Rust is that various people they trust went that route.
For instance, Yehuda Katz and Steve Klabnik were both extremely helpful and widely admired figures in the Ruby/Rails community. Then they both joined the Rust core team.
That alone is enough to attract the interest of a lot of rails people I think, by giving Rust relatively huge exposure among Ruby people.
Then you have the fact that (probably due to the above) Rust became a common choice for outsourcing performance-critical parts of Rails apps.
Once you start doing that, it’s kind of natural to start thinking hmmm what if I wasn’t even doing Rails..
Ruby has a very readable syntax and easy learning curve for new devs. What it lacks is the performance and type safety of a compiled language which I think is why many people eventually switch to Rust and Go.
Interestingly, Crystal might be an easier jump as it's syntax is very similar to Ruby, but with the performance gains that come with compiling to a single executable.
Crystal is still pre-1.0 though so it doesn't quite have the production-ready stability or robust community of Go or Rust.
Perhaps critically, it lacks an official Windows distribution and support.
Is anyone deploying anything other than .NET on windows for webdev though?
I work on windows boxes all the time for go development it works great for that. Docker / Docker machine cause issues, and I can't use HyperV because I also have to be able to run android emulator.
However every time I've looked at crystal I've stopped because there's no windows version. I have to have a gaming PC and I only use editors and languages that work on windows mac and linux so I don't hamstring myself or anyone I'm working with.
>However every time I've looked at crystal I've stopped because there's no windows version. I have to have a gaming PC and I only use editors and languages that work on windows mac and linux so I don't hamstring myself or anyone I'm working with.
I have a gaming PC too and I run my editor and browser etc... in windows, but I have a Linux server where the software I'm developing actually lives and runs (if it's something web based and not designed to run on windows).
I can't for the life of me figure out why you would actually run your development environment on a drastically different OS than what you're deploying to unless you absolutely have to. You're just asking to introduce an entirely avoidable class of bugs.
I have done it btw, Go software developed for Raspberry PI on windows, but I definitely wouldn't do it again.
Some of us do deploy Web applications on Windows.
In which case developing on Windows makes perfect sense.
Just run a Linux dev VM in VMware. Best of all worlds. You have your Windows gaming PC and you can develop on it in Linux.
done that for years too. file syncing from windows to linux isn't the fastest... the vms are decently fast but not good enough. I also use quad monitors on my windows pc and 7 at work (tho one runs twitch or MLB all day), I hate to say it but the vm feels almost as bad as me using a 13" laptop (or a laptop in general for development without monitor) feels. I just switched my laptop to linux (it's new and it's god awful fast, it was always choking on windows, and it may be because linux isn't speed stepping the cpu constantly). My desktop is generally quite fast but it's a beefy box.
I find that if I use VMWare the VM is nice and fast and no problems. If I use VirtualBox the performance isn't fantastic but still workable.
How on earth do you use 7 monitors for work?
A lot of folks have to use Windows machines at their day jobs.
If they're not deploying on windows though, there isn't much reason to develop on it.
That's what I'm saying. It's not uncommon for companies to have AWS linux infrastructure for deployment but give everyone windows laptops for development. Don't ask me, ask the IT department.
Are they running Linux VMs? Everywhere I've worked, I'm one of the few who's not on a Mac, so I'm not familiar with companies like this.
Very typical on enterprises doing Java development.
It doesn't matter where the JVM is running.
node.js.
I have a production line of business app running on node.js in a full windows environment (cloud server and desktop) for a SME I do work for.
As a game developer who sometimes uses Ruby, Crystal is appealing but a non starter.
Java and C++ (IIS modules)
Is this really an issue for most devs moving from Ruby? I don't think I have ever run Ruby on Windows or talked to anyone who did.
In 2008 when I did rails I was always annoyed that the dev tools heavily favored mac but you deployed to linux. No end of issues with native gems and deploys. I don't think I was using windows back then.
I hate this. Some tools work best on Linux (i.e. LAMP/LEMP, composer, etc. - performance is noticeably better than Mac). I don't even mention Windows here because it's probably worse. I'd love to have one ultimate OS to do web development, but find myself hopping to Linux and back to Mac... and occasionally to Windows (games :D). Mac/Windows with Linux VM solves this issue, but it's a hassle. Windows Subsystem for Linux is again very slow (try composer) because of slow I/O -- so that great attempt from Microsoft doesn't work for all.
Rails is still very much develop on Mac/deploy to Linux. Although I think developing on Windows and Linux is easier these days.
It seems fairly common for a small number of prominent members of some community to move on to a new technology and have a number of people follow them for various (good and probably not good) reasons.
I'm not that familiar with Rails or Rust, but Steve Klabnik (http://www.rustforrubyists.com/) and Yehuda Katz come to mind in this case (https://blog.rust-lang.org/2014/12/12/Core-Team.html).
In case it wasn't clear from the article, I'm moving from contributing to Rails to Rust, not as a user. Most of my contributions to Rails were around Active Record (the ORM), and I got into Rust by creating its most used ORM. My main role in the project right now is co-leading the team responsible for crates.io, the Rust package registry, which is a web application written in Rust.
So all of those things overlap quite a bit (also am I not allowed to expand the scope of things I work on beyond web frameworks? I'm not really sure why they have to overlap at all)
The one reason that might make sense is if the objective is to write webapps using webassembly. Rust can compile to webassembly. But that seems more like it would displace something like React or other frontend frameworks rather than Rails. Elixir/Phoenix seems like a much more logical progression from Rails.
Me too curious about this. For me it's more understandable moving from Ruby to Elixir. But Rust is so different from Ruby...
Both the Ruby and Rust communities are drawn to a "Everything In Its Right Place" mentality.
Next optimal choice is calculated on the number of letters that needs to change on the resume.
> The problem is that working on MIT/Apache licensed software doesn’t exactly help pay the bills. That’s why I’m asking for your help. I’ve spent the last 5 years having a single company sponsor my open source work. This time I’m going to try something different. Right now my goal is to get a handful of medium sized grants from larger companies to support my work on crates.io. If you work for a company that might be interested in helping sponsor me, please reach out.
This is the crux of the problem which seems left unadressed in the comments.
If it feels nice to enjoy those consulting rates, give something back.
Honestly, my initial thought when reading the article was whether anyone is using Patreon for helping them focus on open source projects, or if there's a popular competitor for that. Patreon seems to have all the controls to handle this well though. I would happily give a buck or two to someone monthly, and an additional few dollars per release capped at once a month or quarter (and Patreon supports both those, but I'm not sure it supports them at the same time). Although something that worked at the project and/or individual+project level might be better in this case.
I believe Sean's decision of moving to Rust has very little to do with Ruby/Rails. I think all of us have a point where we just simply want to move on to new things in life.
I really appreciate all the contributions done by Sean in Ruby On Rails and wish him all the best.
Sounds like some philosophical differences too.
I hope he can make a living doing open source.
I would have thought rails to golang so I too am surprised.
I wish I had millions and could be a patron saint of sorts for people like the author. Open source funding is so broken as the companies that build upon the vast open source and often free software don’t do much in the way of donating or otherwise supporting the companies or individuals behind the projects.
Ruby has developer happiness as one of its main goals. Go on the other hand seems to have a lot of narratives around keeping the language small even if it's inconvenient. Add to that that Rust with Cargo has a package manager that will fell just like home to Ruby devs, whereas Go brought package managing back to the dark ages. => All this makes it hard to get excited about Go. Rust on the other hand comes with a bunch of new and exciting language features.
I don't think the "lot of narratives" you're talking about actually exist. I've never heard anyone from the Go camp say that they want to make the language "small even if it's inconvenient". From a language design point of view I think they're trying to make it small to maximise convenience. Yes, it's a different philosophy to "kitchen sink" languages but that doesn't make it wrong. In fact it's considered a gold standard of language design. Wikipedia says:
> Orthogonality in a programming language means that a relatively small set of primitive constructs can be combined in a relatively small number of ways to build the control and data structures of the language[2]. It is associated with simplicity; the more orthogonal the design, the fewer exceptions. This makes it easier to learn, read and write programs in a programming language. The meaning of an orthogonal feature is independent of context; the key parameters are symmetry and consistency (for example, a pointer is an orthogonal concept).
Go modules are a fairly new feature which addresses past criticisms of Go dependency management so I don't think that's a valid criticism any more.
I don't disagree that making the language small is a great goal and makes the language better. I just think that such a language will not appeal to everyone who enjoyed a large language full of syntactic sugar like Ruby. In fact I very much agree with Go's design goals and see lots of problems with Rust's design choices, at least when considering it for "mondain" work like web dev. However, I cannot get myself excited about Go at all, while I am very excited about Rust. I think it's that Rust, especially coming from Ruby, has interesting new concepts that lead to many rewarding learnings where you change how you reason about some things. When I read about Go, there are no surprises, everything immediately makes sense. All of this is good. It's also boring (in a good way). If I somehow got forced to use one of these languages for a new startup, I'd go with Go. If I had to pick one for playing around with on the weekend, I'd definitely go with Rust.
Mundane... Not mondain
To be fair Golang modules fixed this somewhat. To that end, go modules are not cargo or ruby gems.
The article seems to disagree with your point about open source funding:
> Right now my goal is to get a handful of medium sized grants from larger companies to support my work on crates.io. If you work for a company that might be interested in helping sponsor me, please reach out.
If that's a financially viable proposition, that speaks well of large companies supporting individuals on open source projects, no?
I think that particular type of patronage is fairly uncommon, but popular projects might have a couple people like that each. That's still a very low number if I'm correct. I know sometimes there are foundations for languages that aggregate donations and fund grants to do specific work (e.g. part of the The Perl Foundation's function, I believe).
I think the majority of companies that give back do so through developer time and effort. If there's a non-profit to push money through to fund work, they at least get to write it off easily, so whether a language has one like the one I referenced above might greatly affect whether there are dedicated people working on the language specifically or not.
Does anyone know if the "Rust organization" he references is meant to refer to Rust as a whole, or is a specific non-profit with a goal of funding Rust advancement? I'm not finding anything specific. Mozilla probably isn't equivalent, as I imagine only a fraction of anything donated to them could be expected to go directly towards Rust.
Yeah, it's a problematic model if we were to look at it as a solution to open source funding. It requires you to already be contributing heavily to a significant enough project that you'd be able to get these grants in the first place. Being able to get there without being paid along the way is a position of extreme privilege that not many have.
I spent a lot of time wrestling with the decision to even try this at all ("is it fair for me to do this when so many others can't?" and "will folks just think I'm abusing my position" are both things I had to come to terms with).
That said, if we do a better job of breaking down barriers to getting into that position in the first place, it's not a terrible model to start with. Getting a enough large grants to fully cover a salary from various companies a year is much more feasible than getting enough tens of thousands of individuals to contribute.
Working with these shorter sponsorships vs a full time employer also just feels more like the kind of open source work that got me wanting to do it full time. It lets me be much more flexible on when/what I work on (within reason, there are expectations on what "full time on crates.io/Rust" means). It's also helps to avoid situations where the employer is upset because you're spending time on a feature/bug/whatever that is important to the ecosystem but not directly useful to the company (e.g. working on a PG specific feature in Rails while employed by a company that uses MySQL)
There is no legal entity, he just means the contributors group. The GitHub organization.
We may eventually start a foundation, but that’s a huge “may”.
Yeah, calling it "The Rust organization" was probably a mistake, as it can be confused for something more official than the nebulous non-official entity that I'm referring to
I've never contributed to go in the past, why would I be transitioning to working on go full time?
I am curious to what drives the next thing? Just wanting to use a new fresh language?
I saw the rise of Ruby on Rails; the driver was the ability to deliver wellstructured web applications fast. The language was a secondary thing.
Is it even possible? Or do you basically have to relearn what you missed in Computer Science over the last 6 years.
It reminds me of what Dijkstra said about people raised on BASIC in the 70s:
> It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
My progression was BASIC > Pascal > (insert a bunch of procedural/OO langs and scripting langs)> .NET > Ruby > coding Ruby in a FP style > Elixir.
So basically procedural > OO > functional.
I will say the hardest transitions (where "hard" is still less hard than, say, understanding everything about how a SQL join works) were from .NET to Ruby (and even THAT transition was mostly hard because I was going from "Microsoft ecosystem" to "open-source ecosystem" without having Java on my resume), and from Ruby to Elixir (syntactically similar, semantically night-and-day). But clearly it's possible... and I'm a Dijkstra fan!
OTOH, one of the best ways to learn something is try to use it on a language that doesn't support it. Back when I was a kid, I tried translating a Pascal quicksort from a textbook into BASIC. Those old BASIC's didn't support re-entrant functions, so I ended up having to implement my own stack. I didn't understand re-entrancy and recursion before that exercise; but certainly did afterwards! A similar later experience with a game engine in assembly language taught me a lot about object orientated designs.