Working with this with a small team with one simple stack is a breath of fresh air in today's world.
I’ve always heard awesome things about elixir/beam but I only have so much love in my heart for languages without good static types. Right now that love goes to clojure!
I’ve been hearing some buzz about static types landing in elixir, and it’s definitely piquing my interest. This comment of yours has fully sold me though!
having used both, elixir feels a lot like clojure semantics with a ruby like syntax. the big advantage of elixir is the erlang vm. if you want a vm that heavily prioritizes parallelism and network programming, give elixir a try. otherise, clojure is perfectly adequate.
Elixir/Phoenix is far and away my favorite framework to build with, but it does leave some things up to the user in a way that Rails doesn't, eg: there is no automatic `class name -> db table` mapping, or automatically inferring what partial or form names to use by a variables name.
In my mind, this is not a downside and there are still idiomatic ways to write Phoenix code, but just to outline some philosophical differences I guess. In the end I much prefer it because everything's a bit more explicit and flexible when I want it.
I think Phoenix also expects read documentation around OTP if you want to really achieve high leverage. This is worth it, and you can sort of drip feed yourself by starting with Phoenix, recognising that Phoenix primitives [sic] are actually Elixir primitives are actually just OTP primitives and you end up with some pretty good examples of how OTP works in a system you're already familiar with.
I highly recommend checking out Elixir & Phoenix.
Was it the LiveView stuff that felt foreign? I'd agree there's a learning curve there as someone coming from Django.
https://github.com/elixir-nx/axon -> AI/neural networks
https://elixir-broadway.org/ -> consume streams from kafka or rabbitmq
https://oban.pro/ -> job processing
https://membrane.stream/ -> webrtc (make a video confrencing app)
For a skilled developer who knows any of the major MVC web frameworks, they’re all really productive, just in slightly different ways.
And now with InertiaJS, there are no more API endpoints necessary for any UI stuff. The data just gets prepared in the controller in PHP and gets directly loaded as JSON into the React/Vue/Svelte frontend pages, thats it!
In 4 out of six large, dynamic code bases I have worked in, everything becomes spaghetti. This joins with that which n+1s with yadda yadda. You end up with dependencies that prevent billing options because you can't separate the billing structure from the user model from the product table. Queries start joining and joining and you get monstrosities of queries. The beefy postgres db gets bogged down at less than 2k rps. Everything gets slower. Then the org spends millions and millions on domain separation and breaking teams away from another. Builds get slower. Competing styles of decomposition litter the codebase. Changes take days to release. It takes Herculean effort and heroics to fix a dynamic code bases that grows, eating at growth when it should be compounding.
"But it let us get here, where we can afford to do those changes." Maybe. It is the road less taken's point - you can sell yourself that the dynamic code bases allowed for the success. But that doesn't say the alternative wouldn't work.
</insomnia thoughts>
This is hardly the property of languages or frameworks - just orgs being orgs and incentives being incentives. I don't see why a codebase in a compiled lang would not have queries that "start joining and joining and you get monstrosities of queries" if the business logic demands that queriage to be queriaged?.. Maybe you could make a case to the business that the speed of rework has to be reduced "because static lang and we do things properly here" - but the same can be done with dynamic langs, just with a bit of rigor.
Speed of iteration rules above all.
My speed of iteration in dynamically typed languages is great at first, but after running in production for 8 years, coded by a team that never wrote the original, dynamic typing hurts iteration speed.
If you judge iteration speed by how fast you get to feature #3, I've got a ton of bash programs that will beat any serious language product you have on that metric.
That can be a mix of how you see it, how the business works and how the code does anything.
It is important to understand I’m not referring to dynamically vs statically typed languages or not. It’s a distraction. Code runs fast on pretty much anything these days, and dynamically typed languages have pre-compilers.
These are sometimes matters of personal experience, interpretation, preference and opinion masquerading as facts.
Most languages have to abstract from to the web using a framework and that additional interpretation is where a lot is lost.
Featuritis is the disease, solving problems solely based on customer input (who are strangers) is important. Problems are rarely a single feature, but a sequence or group of them.
The irony of bash scripts is they can be some of the most durable and well lasting parts of a project while everything around it might change and evolve quicker. So if there’s some bash scripts being called by a language in the beginning.. so what.
My original point about Laravel is I have not seen as tightly integrated of any ecosystem to ship solutions and product where so much time is not lost in the product side of it (accounts, billing, migrations, etc). While I’m relatively new to it, at the very least it’s a worth comparison to show the holes in others.
There are always attempts in every language to replicate the convention over configuration and batteries included approach of Rails, but they all lose steam pretty quickly.
I just don’t think there is an alternative to Rails. It’s a giant project that is actively developed for over 2 decades now.
Any other ones are gonna be a little niche but from what I can tell these four (with rails) have the most large and active communities atm.
When I struck out on my own I realised that I no longer had team consideration as a constraint and went a little bit off the beaten path.
Every client I have used it for has had nothing but praise for how maintainable the software is.
All jokes aside, having worked in both languages and frameworks, I’ve enjoyed the Dev experience in either option.
Grateful for both dev communities as well.
As someone who likes Rust, has one project (web based) in production in Rust, and considering starting another one, I'd be glad to learn from the experience of other people.
So far I don't know any better way of doing it and I have tried all the classic ways like PHP, Django etc. This is way superior. The only downside is that I am the only one who can touch the backend, but I guess if some of the projects grows enough, there will be enough incentives to find another Rust programmer besides me.
Both Rails and Django are horribly slow though, so once you get to some critical scale you gotta start doing some real weird stuff like Instagram did with turning off Python's GC [1], etc.
[1] https://instagram-engineering.com/copy-on-write-friendly-pyt...
"Home page should load under 2 seconds at P95", "reports should load under 10 seconds at P99", "this background task should take under 30 seconds at P99".
Having these targets (and, frankly, remembering in the B2B space is that the status quo is _so slow_) can let you set performance objectives without chasing milliseconds that you don't need to.
Django has a lot of intrinsic slowness to it, "easy" DB access patterns often lead to heavy messes, but if at the end of the day most customers are getting served under some benchmark you can reap the advantages of the tooling without sweating perf too much.
And when you set these SLOs, you can then push for even tighter ones as you figure out your problem space!
In the B2B space companies get away with _so much_ sluggish behavior, if you're better than the median that's already improving things.
Things we did: careful about N+1 queries, caching where obvious, API calls/emails/etc running in background queues.
Things we didn’t do: use a fast templating language (we used Django’s built in one and it was often our bottleneck), removing all database queries (we just had Postgres <2ms latency away), renormalising data (we were highly relational for most things).
Django is perfectly performant enough for almost all use cases, and insanely fast to develop with.
I think B2B SaaS, for "normal" teams (read: people not that adept at building scalable systems), when not careful, tend to make omnipages where about 20 different things are happening. Even just navigating to a page ends up triggering random side effects (driven by various needs).
There you can easily find yourself in a performance pit that you have to dig yourself out of (often redesigning features in the process to remove some stuff).
I just find that setting fairly easy performance goals can help to make perf seem more tractable.
.Net has tons of configuration and boilerplate so I can't say that it's exactly the same in that sense, but the more meta theme is that just as there is a Rails way to do things, there is a Microsoft way to do things. Unlike Java where you're relying on lots of third party packages that while well maintained, aren't owned by the same company that does the language, framework, ORM, database, cloud provider, IDE and so on. Having a solid well documented default option that will work for 99% of use cases takes a lot of the load of decision making off your shoulders and also means you'll have plenty of solid documentation and examples you can follow. I've been in JVM land for the past couple years and it just can't compare.
I know Java people will come fight with me after this but I just don't think they know any better.
But I guess Spring tried to do that, but probably didn't have the resources that Microsoft does.
But I just want to say that I have the same feel when I develop using Spring Boot. I am extremely productive and seldom have to pull dependencies outside Spring for 80% of what I make.
I can't really say how the web UI side holds up to alternatives, tho.
https://news.ycombinator.com/item?id=10135825
https://github.com/dotnet/core/blob/main/release-notes%2F1.0...
People aren't just going to jump onto something recently open-sourced by a company that popularized the phrase "embrace, extend, extinguish". For the last decade, they've had to earn people's goodwill, while with a project like Rails, there is no "we used to be closed source but now we're not, use our thing!" to overcome. So in the 20 years since Rails has been released, it has only ever needed to demonstrate its usefulness.
Now that a decade has past, that negative association is starting to wash away a little.
Take a look at this: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...
I’m pretty sure even back then Entity Framework was very capable, it has only improved since then.
https://learn.microsoft.com/en-us/ef/core/querying/complex-q...
It’s probably better to compare with other statically typed, compiled languages since both Ruby and Python are an in a different class (and an order of magnitude slower, more painful dependency management, etc.).
With admin, you basically just write models, and the entire rest of your app is free. Not quite, but, not far off.