Episode 48 for anyone else who's interested: https://www.therepl.net/episodes/48/

Joy was a key reason I chose Clojure.

I started my app using Rails and Hotwire/Stimulus and honestly finding myself way more productive than I did with more JS heavy options. Everything just works so nicely together in the Rails world.

Jake Zimmerman wrote this excellent blog post[1] on the current state of Sorbet.

I was impressed at recent changes in the Sorbet syntax but also with the proposal that we make code comments available to the ruby VM.

That would allow Sorbet to adopt the rbs-inline comment syntax for both runtime checks and static analysis.

So there does appear to be a way forward on this which is pretty exciting.

1. https://blog.jez.io/history-of-sorbet-syntax/

I see what you mean but I have never found it to be an issue even in large codebases. Sorbet and RBS have been problematic. Lots of development slows down with these solutions. I wished it had something baked into the language as well but I'm happy without... just following conventions alone has worked really well for me.

The way I describe language types to non-coders inquiring about language selection for a given project is simply “scale matters”… dynamic types provide flexibility at small scale, but can very easily result in chaos at a large scale. Conversely, the structure of static types can feel onerous and restrictive at small scale, but provide robustness and structure at large scale.

One big up for Laravel and also Symfony, the other big PHP framework!

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!

This was my first impression too but I wasn't sure it covered the OPs convention over configuration stipulation.

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.

Elixir + Phoenix is amazing. It's one self-contained stack. Just Elixir processes (and Postgres) which takes care of everything other ecosystems farm out to extra services. Background jobs, real-time channels, and even hot-code deployments run natively within the same BEAM runtime.

Working with this with a small team with one simple stack is a breath of fresh air in today's world.

I've been slowly / occasionally dipping my feet into Elixir / Phoenix dev over the past year or two, building an app idea that's been floating around in my head for a while. It's a bit of a steep learning curve for me, coming mainly from Python land (Django / Flask / FastAPI); I understand that it's designed to be a gentler learning curve for those coming from Ruby / Rails land. Phoenix is also a lot less mature / less feature-complete / less thoroughly-documented (than I had hoped, and) than Django / Rails (many of my Phoenix questions I've only found answers for in the forums, rather than in the official docs). Nevertheless, I agree, BEAM / Elixir / Phoenix is awesome, I'm hoping to get into it more in future.

I have a proprietary one that's much faster in terms of dev velocity.

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.

I'm 15,000 lines into a Rust project at the moment. I like it a lot but I'd never consider it for a web centric app.

Coming from Ruby, Flask is much more of a Sinatra than a Rails. It’s very batteries-not-included. You basically just get routing out of the box. DB ORM, forms, auth, mail, background task, etc. are all DIY. That said, there are high quality packages to do all of those things within the ecosystem and I really like that I don’t feel like I have so much unused bloat in the framework when I’m making a small service.

I still don't get why .NET barely ever gets mentioned in these threads. Even new or niche frameworks like Phoenix, loco.rs and others get mentioned, but almost never .NET. It's as "convention over configuration" as it gets.

I learned to code professionally in Ruby but wrote C# .Net for almost 10 years. I've probably forgotten more about .Net than I ever learned about Ruby at this point so take what I say with a grain of salt.

.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.

Asp.net core is actually pretty simple to stand up and bang something out. Stick to the Microsoft docs and most patterns are handled.

I can't really say how the web UI side holds up to alternatives, tho.

The only thing I don't like about ASP.NET is all the dependency injection, last time I looked it seemed unavoidable.

Django's admin is great. I think iommi is better for a lot of projects.

With admin, you basically just write models, and the entire rest of your app is free. Not quite, but, not far off.

Speed of iteration varies within a single projects entire lifetime.

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.

Most slow queries / endpoints / things can be cached! But, of course, every time you stick a cache in front of something, now you have two problems...

Regarding the slowness, I think it's super important when working with slow stuff like Django to have good SLOs in your head.

"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.

"horribly slow" yet some massive websites run on both.