To be precise, the previous problem with Rust was because somebody copped out and used a temporary escape hatch function that absolutely has no place in production code.
It was mostly an amateur mistake. Not Rust's fault. Rust could never gain adoption if it didn't have a few escape hatches.
"Damned if they do, damned if they don't" kind of situation.
There are even lints for the usage of the `unwrap` and `expect` functions.
As the other sibling comment points out, the previous Cloudflare problem was an acute and extensive organizational failure.
You can make an argument that .unwrap() should have no place in production code, but .expect("invariant violated: etc. etc.") very much has its place. When the system is in an unpredicted and not-designed-for state it is supposed to shut down promptly, because this makes it easier to troubleshoot the root cause failure whereas not doing so may have even worse consequences.
And I don't understand your comment. The author is obviously a techie. Netlify + Cloudflare cost peanuts (might end up less than $5 a month) and you would have a blog that can sustain all but a coordinated huge DDoS attack.
If you're talking about non-tech people then sure but that would be a hypothetical. The author obviously has the skills. He just fell into the trap "my blog is not popular enough so WP is fine". Which is a common bug in our brain's algorithms: we never act until too late after an incident. Oh well. That's Homo Sapiens for you.
Then the reality is that the blog should be migrated to fully static contents. You have generators, many of them (f.ex. Zola), where you write Markdown files, run a command and run `rsync` to your host.
As a person who actively uses Elixir, Rust and Go (in that priority order) to me there is a maddening gap between Rust and Go.
While Go has the goroutines and they have made concurrent and parallel programming accessible to many, they are a rather raw material that's easy to abuse and use wrongly (leaks, deadlocks, and don't even get me started on writing to a closed channel -- instant panic and program abort).
Rust async is also too raw but in another way: gets wordy / verbose and too implementation-oriented way too quickly -- I never wanted to care about Pin<Box<???>> or what must this or that Future implement in order to be eligible for usage in `select` and whatnot. Those things should have been hidden behind a DSL much like `select` and `async` itself are a DSL / macros / state-machines of sorts. Rust's async just seems... I don't know... unfinished. Zero disrespect is intended (and I do recognize you by your username), I love Rust and I never pass an opportunity to whip up an internal CLI tool with it and my most consulting engagements have resulted in teams highly appreciating such tools, but I can't shake the feeling that Rust's async could be more... polished.
Both Rust's and Go's async mechanics leave me with the impression that somebody thought that they gave the devs enough LEGO building blocks and called it a day. I don't judge. I understand. But as a user of the languages I also have the right to find their async facilities less than ideal.
Erlang / Elixir / Gleam / LFE on the other hand stand on a runtime that has exhaustively analyzed a ton of async scenarios and cover them very well (minus stuff like filesystem operations being centralized through a singleton runtime agent, something you can opt out of, thankfully).
So I'd say both Rust and Go are ripe for either disruption or courageous backwards-incompatible modifications. Their async implementations simply did not go far enough.
And don't get me wrong, I love both and do my best to use them regularly. But it's a sad reality that their "unfinishedness" led to a plethora of footguns that became a badge of honor if you get to know most or all of them, as in: know how to avoid them. Which I don't know why many see as a desired state of affairs. Job security, I suppose.
I would kill for something as terse and explicit as Go but as super strict as Rust but that also has 100% finished async semantics, and has a faster compiler than Rust but optimizing as aggressively as it as well. Yeah, I know: what color do I like my dragon?
All that being said, Rust is the closest we have to a perfect language currently. And that's kind of sad because it has a few things that it really needs to fix if it wants to keep gaining mind-share. I personally find myself reluctant trying to build a career with it. But I'll not digress further.
• Senior Elixir Architect & Systems Engineer (9.5+ years in Elixir / 20+ years total)
I am a veteran engineer transitioning from independent consulting to a long-term Product/Owner role. I specialize in unsticking complex architectural bottlenecks, stabilizing legacy systems, and shipping high-reliability features in regulated environments.
• What I offer:
The "Majestic Monolith" Mindset: I know Kubernetes and microservices (because I've fixed them), but I fight for simplicity and maintainability.
Polyglot Systems Knowledge: I write Elixir for the business logic, but I use Rust/Go for the heavy lifting when the BEAM needs help (Author of xqlite, a Rust-backed SQLite wrapper for Elixir).
Looking for a small, high-autonomy team where I can solve hard problems and then stick around to own the outcome.
just what i was taught when i took a management 101 class in my university years.. it was one of my elective papers outside of my core curriculum quite enlightening and helped me manage my managers...
Bad code is not written on a bet. It's written because either competent engineers crunch, or because they are incompetent.
Good code could be costly, yes, but often is not. In fact it's very often economically sound to periodically address tech debt i.e. not allow it to accumulate because it seems to increase exponentially until one day a critical customer-acquisition-stakes feature cannot be shipped on time due to it. Only then do the executives wake up and even then 80% of the time they just blame the engineers and move on. They are never at fault, the angels.
Finally, many companies are already on the market and are relatively OK economically. Let's be honest: most deadlines are entirely artificial and are just power moves by management; they are not mandated by critical business needs.
Well maybe you get hit with the gray arrows because you first make a sweeping generalization and then say "I have no sympathy for you". Food for thought?
I have communicated the business value in addressing tech debt, as in I have pointed out how many critical customer features got delayed by it and we churn customers we really can't afford to.
Still got overruled. The tech lead stepped in and threw his weight around with zero explanation to the CTO or the CEO. Who needs to hear what the engineers on the ground have to say, right? They cannot communicate!
Man, tearing down strawmen is easy. You should do better and see nuance. A lot of engineers communicate very well and are still ignored.
I think we are both operating on our priors. At least here in the Bay Area, those kinds of workplaces don't survive over the long term due to their incompetence and toxicity dragging down execution. I can't speak for where you might be.
What is there to get? Bull-headed egomaniacs on a power trip are the norm in most of the world -- on the executive positions, middle managers included.
Reasoning with unreasonable people is not impossible but drains too much time and energy... and you don't know if they will not come back to you next week and hit you with "You know what, I actually think that your idea is not as good. Let's get back to mine and...".
I have danced this dance. As much as it pains my younger idealistic self to say this, you'll know how well you'll work with somebody after the end of the first week. All the signs are there, we just choose to ignore them because you can't bail during your first month after all.
It was mostly an amateur mistake. Not Rust's fault. Rust could never gain adoption if it didn't have a few escape hatches.
"Damned if they do, damned if they don't" kind of situation.
There are even lints for the usage of the `unwrap` and `expect` functions.
As the other sibling comment points out, the previous Cloudflare problem was an acute and extensive organizational failure.
reply