We've done the same thing in my job. I think what they're saying is that rather than passing/returning `SomeStruct` and having it maybe be optional, they either pass `SomeStruct`, with a rule that it's never nil, _or_ they pass `Option[*SomeStruct]`. Then anything that deals with optional types is forced to explicitly check.
This is exactly how Rust works, except there it's built into the compiler, and there's no such as nil in most code.
Imagine that you are a consultant. You get a call that starts with, "Hi, this is Joe Schmoe and Schmoe Law Firm. I need a new billing system. Can you build me one?"
And you respond by saying that you can, but you need to do a _lot_ of work with him to spec this billing system out. You can't just build "a new billing system" without any more details. You tell him that this will take many hours of work between the two of you where you ask him questions, write a spec, get his feedback, and repeat that a number of times.
At this point, he says "wow, that sounds like a ton of of work for me just get started", and he gives up.
AI does not fix any of this, and this is the thing that I think most people will not want to do, and that's why I think this blog post is making a very good point. The amount of work it takes to build a new software system, even with a super competent programmer as a partner, is still quite significant. And it requires thinking about hundreds of tiny little details in a way that drives a lot of people nuts. They will only do it if they _really_ have to do it.
Yeah, it's quite difficult to walk for any length of time without encountering one, usually a 7-11. They're everywhere. And they actually have some decent food. It's a bizarre thing to experience for an American like myself.
I'd love to see this for Taiwan. I'm here now (on my Nth trip where N >= 11), and my impression is that 7-11 is the clear winner in all the cities I've been to, followed by Family Mart and then some stragglers like Hilife and OK Mart (it's ok).
My personal favorite is probably Family Mart, because they have multiple very delicious vegan rice balls to choose from.
I was wondering about this myself. My guess is no, since AFAIK the only way to do this sort manual memory management is to use unsafe code. But there's also things like the (bumpalo)[https://docs.rs/bumpalo/latest/bumpalo] crate in Rust, so maybe you wouldn't need to do this sort of thing by hand, in which case you're as leak-free as the bumpalo crate.
> What's an example of a language that's as bad as Perl, that's used as widely as Perl was, that's still in use today?
PHP? I don't know how widely it's still used, but I'd guess it's more widely used than Perl. Also, PHP is not "as bad" as Perl. It's much, much, much worse. It's Perl without the charm.
My main complaints about Go are not that it needs more obscure syntax. The biggest problem with Go is basically that the core of the language's syntax is special, and only accessible to the compiler. This goes hand in hand with the language not offering generics out of the gate. This means that things like slices, maps, channels, etc. are all special. You cannot implement anything similar that uses the same syntax (even now that generics exist).
This lack of flexibility means that it's impossible to experiment with replacements for built-ins, and the lack of generics out of the gate meant so many things were simply impossible (like useful iterators).
Compare this to Rust, where almost everything like this is just a trait. If you want to offer a map replacement, you just implement the Index and IndexMut traits.
Overall, I don't think Perl is the best language design. It has some interesting ideas. Go is _also_ not the best language design. Is Rust the _best_? No, but it's better than both Perl and Go, IMO.
I was just saying that they were confused about what was going on with Perl because if the Perl 6 effort. I don't think that they were confused or wrong in their decision making.
True. For whatever reason, these never displaced XS. For wrapping C libraries in particular, it's not clear to me how much Inline::C helps with this. You're still stuck using a lot of Perl C API calls, AFAICT, which I think is the biggest challenge of using XS (I still have nightmares from trying to figure out where and when to add `sv2mortal` in my XS code).
> The point where I disagree is I think Perl 6/Raku played a significant role in Perl's decline. It really gave me the perception that they were rudderless and that Perl probably had no future.
I assume you disagree with the blog post, not with my comment, since this is exactly what my comment says too!
I was writing a comment asking if it was really easier. Then I took a look at Cython. Yes, this looks easier than Perl's XS, which I have some experience with! There are ways to do something similar in Perl these days, notably https://metacpan.org/pod/FFI::Platypus. But these are relatively new (starting in the 2010s) compared to the history of Perl, and Cython goes back to the early 2000s.
As a very long-time Perl developer and FOSS contributor, I think this blog post is incorrect about whether Perl 6/Raku was a factor in Perl's decline. I think Perl 6/Raku did a few things that hurt Perl 5:
1. It pulled away folks who would otherwise have spent time improving Perl 5 (either the core or via modules).
2. It discouraged significant changes to the Perl 5 language, since many people figured that it wasn't worth it with Perl 6 just around the corner.
3. It confused CTO/VP Eng types, some of whom thought that they shouldn't invest in Perl 5, since Perl 6 was coming soon. I've heard multiple people in the Perl community discuss hearing this directly from execs.
Of course, hindsight is 20/20 and all that.
Also, even if Perl 6 had never happened the way it did and instead we'd just had smaller evolutions of the language in major versions, I think usage would still have shrunk over time.
A lot of people just dislike Perl's weird syntax and behavior. Many of those people were in a position to teach undergrads, and they chose to use Python and Java.
And other languages have improved a lot or been created in the past 20+ years. Java has gotten way better, as has Python. JavaScript went from "terribly browser-only language" to "much less terrible run anywhere language" with a huge ecosystem. And Go came along and provided an aggressively mediocre but very usable strongly typed language with super-fast builds and easy deploys.
Edit: Also PHP was a huge factor in displacing Perl for the quick and dirty web app on hosted services. It was super easy to deploy and ran way faster than Perl without mod_perl. Using mod_perl generally wasn't possible on shared hosting, which was very common back in the days before everyone got their own VM.
All of those things would still have eaten some of Perl's lunch.
This is exactly how Rust works, except there it's built into the compiler, and there's no such as nil in most code.