You install their Github app and give them access to your Github repo (private repos are ok too) and they run a Github workflow when each PR is submitted scanning for secrets that should not be in the code. Really happy with how their product works.
If you weren't aware of it... There is a world of static application security tools (SAST) which can help you. Add them to your text editor/ci/cd to use them.
I have always questioned, are the guys making pizza's, working minimum wage jobs wasting their talent or do they simply have no talent? Then I came across this short video : https://www.youtube.com/shorts/4HnGbQ-vi8s
The line that stuck with me was how you do something is how you do everything.
I follow an indian mystic named Sadhguru who had the same advice. He said if you do not know yet what to get involved in, then do everything with absolute involvement.
This I think was also the core message of the movie Soul from Pixar.
We all might earn different amounts of money in our lives but all of us have the same ability to create a meaningful life for ourselves.
Is there any other framework which can claim that it compares well to Ruby on Rails speed of development? I.e. conventions over configurations? Asking as I don’t want to learn ruby
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.
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 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.
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 had the opposite experience coming from Django/Flask to Elixir/Phoenix. I found it very comfortable and that there were many similar patterns at the framework level. Now, LiveView is a bit of a different story but basic Phoenix routing and views seem quite similar to Django routing and views. Ecto's model schemas have a decent amount of overlap with Django's model objects.
Was it the LiveView stuff that felt foreign? I'd agree there's a learning curve there as someone coming from Django.
Built my startup on phoenix and I can vouch that it was 100% the right decision. code is easy to modify/reason about. Performance smokes rails by a wide margin and its websocket support is simply amazing. There's a few really great libraries for it that just let you scale very efficiently without much effort.
Laravel. Massive batteries included ecosystem and the mental model for PHP programming fits the web so freaking good. Rails 8 tried to catch up by beginning to shape the first party queue story, while Laravel has been there for a decade and the tools have been vetted at scale.
For a skilled developer who knows any of the major MVC web frameworks, they’re all really productive, just in slightly different ways.
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!
In each of the dynamic frameworks I have worked in, besides lacking types, the biggest problem is domain separation.
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.
Ugh, the billing thing hits hard. Just know that having types doesn't prevent this issue. The current codebase I'm working on has a tightly coupled billing model with the incoming requests. Someone thought it was a great idea to mix http status codes with billable events in the same table.
This rings true, but I also saw a lot of situations where just as spaghetti was being tangled, the few folks who resisted it were overruled, again and again.
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.
I have heard Laravel is shockingly complete and most others will pale in comparison to in terms of out of the box speed to first feature and the full CI/CD setup for most any kind of product.
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.
Speed of iteration is for speed of feedback and insight from the business/market into the product.
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.
I’ve been asking this question for a while since I love Rails but I don’t like Ruby that much.
I think only Django comes close, although I haven’t tried it, but I dislike Python much more than Ruby.
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.
I used to code ruby. Now in python land and am using flask. Theres conventions but no scaffolding. Ai code tools make the scaffolding feel redundant anyway.
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.
In Rust we have loco[1], that aims to be a Rails for Rust. I personally have never built anything serious with it, but all the toys projects were pretty enjoyable.
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.
I have several apps in production.
I employ sqlx, axum, async_graphql, React frontend.
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.
Yes, this mirrors my experience as well. It's just every time I see someone who "quits" Rust in order to go back to Ruby/PHP/Python, I'm interested to know what part they were struggling with.
It's niche, but check out https://www.boxlang.io/ and https://www.lucee.org/ on the JVM. They're rock solid runtimes. I single handedly manage multiple production applications going on 10+ years. They essentially never break, never need major maintenance. Backwards compatibility is great. The runtimes are very batteries included in terms of backend web development.
Django is the closest I can think of. Many unicorns built on Django.
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.
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.
My previous company had a sizeable Django monolith and did e-commerce stuff which is fairly latency sensitive. Used well, Django was perfectly capable of hitting 150ms per page which was fine for us. Some optimised pages were under 100ms.
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.
Yeah you can make Django go really fast, especially when you have pages that well scope what data they are pulling from (though you seem to know it better than me).
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.
If you value types more than completeness, Krop is a framework for Scala: https://www.creativescala.org/krop/ It's only suitable for very brave developers at this point in time, as it is nowhere near to feature complete.
I’m curious if .NET can compare here, though I have limited experience with rails or ASP.NET both seem to give you a lot to work with. Though the overlap of rails devs with .NET devs seems minimal.
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.
I don't want to fight you, because I don't know .Net well enough to have an opinion.
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 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.
Platform support and open-sourcedness. The Phoenix 1.0 release predates the first open-source and Linux-supported .NET release by a year, for example. .NET is just now starting to shake off its association as a closed-source, Windows-only thing.
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.
Thanks for that link. If I'm not wrong, it doesn't change the fact that compared to Rails or Django there's a lot of boilerplate that needs to be written to get a database-driven web app running.
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.).
Django is more or less Python's equivalent of Rails. Its admin panel is nice, especially for a solo developer trying to manage something they built in a weekend.
Filament, and it’s fucking awesome. I think it’s way better than Django’s admin panel, and I’ve used it to build out both my Laravel admin panel and basically all of the UI for users.
Meteor.js offers pretty good iteration speeds and a fairly complete toolbox for the JS world. Fully featured accounts system, RPCs, client/server reactivity, etc.
I understand the criticisms, but in my experience, MongoDB has come a long way. Many of the earlier issues people mention have been addressed. Features like sharding, built-in replication, and flexible schemas have made scaling large datasets much smoother for me. It’s not perfect, but it’s a solid choice.
SQLite is a lean and clean tool, it's very much a candidate for being inserted into all manner of contexts.
What beggars belief is the overly complicated, inefficient, rats nests of trendy software that developers actually string together to get things done, totally unaware of how they are implemented or meant to work.
By comparison using SQLite outside of its "blessed (by who?) use cases" is very practical.
Easy. Sometimes it's more than you need, and there's no reason to use sqlite when you can just write things to a flat text file that you can `grep` against.
That's a huge topic. The short answer is that you can't control the output of the LLM. The idea of RAG is that, by inspecting the output of the LLM, you can use it to trigger tools ("tool calling") that pull supposedly-correct data from the real world (like a database). That code which is not based on a model but is traditional programming code in a normal language, must be the arbiter of what is allowed in and out. The LLM is always statistical in output and never fully reliable or controllable.
A banking application is a good example. You might have a chatbox that allowed the customer to write "Transfer $1M by Zelle to Linda Smith." The LLM would probably return the correct tool, but your actual app would not transfer funds you don't have, thus providing the "safety."
I am in a similar boat. Many of us in similar boats would be very thankful if you can expand on what are the names of these consulting companies and how can we breakthrough?
Honestly, there is no easy way. It was partially strategic and partially luck. I started down this path in 2016. The only actionable advice I can give is start taking on projects with greater scope, impact and that is closer to dealing with the “business”. Work on your soft skills and presentation skills.
My favorite book is “The Geek Leaders Handbook”
2016 - I chose a job that would give me a chance to lead my first green field major implementation from scratch over one that paid more. But I would have just been pulling tickets off the board. I was first exposed to AWS here. But “consultants” did all of the AWS setup. After I started learning AWS, I realized that they were just a bunch of old school operations people. I thought I could be a better consultant since I knew software development and could learn cloud.
This is hugely helpful and one of the most helpful things I read. Thanks for your kindness. This is a very good blueprint on how to think about career advancement at our age. Thanks again
