Rust is cool but there is way too much dogma around its memory safety and static typing in general being a panacea. Most errors are not type errors. Two days after Cloudfare's little Rust hiccup that took the internet down for a day I saw people posting about Rust "if it compiles it runs".
I actually don't think this is true. I do think that most programming errors are type errors, in the broader sense of one part of a system making one set of assumptions about the properties of some data, that aren't shared by another part of the system; and that would've been caught automatically by sufficiently sophisticated static correctness checking. I do not think that Rust has a maximally sophisticated type system (nor is it trying to), and while this is reasonable for Rust as a project to decide, I do expect that there will be languages in the future that do more complex things with type systems that might supplant Rust in some domains.
The Cloudflare incident was caused by a confluence of factors, of which code written in Rust was only one. I actually think that Rust code worked reasonably well given the other parts of the system that failed - a developer used unwrap() to immediately crash instead of handling an error condition they thought would never happen; when that error condition did happen the Rust program crashed immediately exactly as expected; and if Cloudflare decided that they wanted to ban not handling an error like this in their codebase, it's a pretty easy thing to lint for with automatic tooling.
If it helps finally acknowledging basic stuff like bounds checking matters, great, this from a guy that rather use system languages with automatic resource management.
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
-- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"
From 1980!
C++26 will finally have hardening on the standard library, something that I could already enjoy in 1990's with Turbo Vision, OWL, MFC, VCL, but was too much to ask for on the standard library apparently, even if compilers kept having each own their approach.
It took governments and companies to start mapping CVEs to money spent fixing them, to finally acknowledge something had to change.
Meanwhile on C land, business as usual regarding Hoare's quote.
It's interesting how it's Obviously Impossible to write OSes in garbage-collected languages, and this is proven by the fact successful OSes were written in garbage-collected languages back in the Stone Age, or 1980s, whichever. My current laptop has enough RAM to swallow the entire state of a Symbolics workstation (RAM and disk) without noticing, but it's obviously too wimpy to run an OS written in anything other than C.
(Nitpickers' Corner: "Successful" and "the most commercially successful" are, in fact, two different words. Gots all them different letters an' everything. Therefore, Genera not being as profitable as such Sophisticated Top-Of-The-Line Pieces of Professional-Grade Enterprise-Ready software as MS-DOS doesn't mean Genera wasn't successful.)
Yeah its funny what we can get away with using different design tradeoffs on modern computers.
I've been reading through the SeL4 source code lately. SeL4 isn't a multithreaded kernel. It supports SMP - so, it can use all the cores on your computer. But the kernel itself uses a big mutex. Complex syscalls can't run concurrently.
And you know what? I think its fine. A tiny microkernel like SeL4 offloads almost everything to separate processes anyway. The only things in the core kernel are the bootloader, scheduler and thread cap tables. Device drivers are multithreaded because they all run in separate processes.
Having the kernel itself effectively single threaded reduces a whole class of bugs and complexity, at a (hopefully) negligible performance cost. Its smart.
This industry pretends to be driven by technical considerations, yet, with some exceptions, is mostly driven by fads, folk knowledge and aesthetic choices.
Folk knowledge may, and often is, grounded in reality and real experience, but let us not forget that most heated debates in programming of today are rooted mostly in tribal logic and fad chasing.
Static vs dynamic typing is a chief example. Empirical evidence that static typing makes some real difference in terms of bugs or safety is inconclusive at best. Yet it doesn't prevent some people from literally shaming those that prefer dynamic languages. Same with OOP - for years it was everywhere, now you may have an impression that it is a sin to ever use it. But now, as much as back then, there is no evidence to support claim that using or not using OOP is "one true way".
Now, memory safety is a real concern, and we can confidently say that we have found ways (exemplified in Rust) to prevent whole class of issues, but suddenly we are in the situation that every single bit of code out there is supposed to put memory safety as a chief concern, no matter if we are talking about some high perf web server, missile control logic, simple script solving Lotka-Volterra equations or simple calculator app.
Rust doesn't eliminate all bugs. But anecdotally, by the time the type checker and borrow checker have humbled me, my programs really do often work the first time I run them. Its quite remarkable.
This isn't a special thing about rust. All languages are on a spectrum of "detect all bugs statically" to "detect all bugs dynamically". Rust programs run correctly "first time" more than javascript, more than typescript. But still less than haskell.
You can still write bugs in rust, obviously. I've written plenty. As you say, so has cloudflare. But strong typing does find a lot of bugs in practice.
If you follow good strong typing principles, you can ensure that most errors are type errors. Yaron Minsky’s phrase, “Make illegal states unrepresentable”, captures this. But it doesn’t happen by accident just because you’re using a strongly typed language.
Also, if Cloudflare had run the standard Clippy linter on their Rust code, and taken the results seriously, it would have prevented the issue you referenced. Static checks don’t help if you ignore them.
I don't think your comment deserves the downvotes (upvoted to compensate) but I do think that it's questionable if "Most errors are not type errors" is true.
Rust's culture of pushing things into type checking does eliminate a huge swathe of bugs and I wouldn't be surprised if it was the majority.
The hurdle of negotiating translation between filesystem strings and unicode strings strikes me as a good example of a place where most languages don't protect you from bugs and a strongly typed one does. The downside, of course, is that you have to handle these cases (even if it's to explicitly say "I don't care").
I still create dumbass bugs in Rust, but they are usually simple logical errors that are pretty obvious when debugging.
With a sufficiently strong type system all errors are type errors! Rust doesn't have that of course, but it does have quite a strong type system so this is a very bold assertion with no evidence.
Rust does have an "if it compiles it works" feel. Nobody means that literally (this should be really obvious). They just mean that once you get it to compile the chance that it works first time is quite high (like 20% maybe?) compared to most other languages where it's more like 1%.
When skiddies use other people's scripts to pop some outdated wordpress install they are absolutely are responsible for their actions. Same applies here.
My experience with flat structure is the most stubborn opinionated people end up making all the decisions because they dont budge and get to escape all responsibility for bad calls. Better to have a designated lead.
Excessive amounts of interviews is more likely they were not enthusiastic about him but didnt have anybody else better and were stringing him along until they found somebody else.
I don't buy it. Seems like a waste of everyone's time. Even if you don't respect the candidate's time, it's still a waste of the employee's time, which is valuable to the company.
Certainly we have lots of horrible inefficiencies in my team, but stringing along hiring was not one of them. I understand this is not universal even at our company.
Yeah, I've seen someone get strung along and then finally hired. What happened was that it was a bit of a downturn so there was a limit to the hiring. Another dept somehow convinced the division head that their role was more urgent, so our department was left without approval even though we wanted the guy. It was a poor job market so he didn't land anywhere else even though it was a few months before the approval finally arrived. Everyone felt kind of shit about it. The guy was quite jittery to start with.
That sounds like it was a terrible place, but it was a good department in a somewhat hard nosed company. He ended up staying there 10 years.
Way too much work having AI generate slop which gets dumped on a human reviewer to deal with. Maybe switch some of that effort into making better review tools.
Sure, but I suspect also harder because it's full of contrarians that will point out at least five better ways of solving the problem and people that upon being greeted with anything that looks like disguised marketing copy will spontaneously combust. And if you do manage to sneak a URL into a discussion without anyone thinking it's marketing, the next four comments will be about whether the design of the landing page is unsuited for people with 2400 pixel wide monitors or people with noscript enabled
(Also it's the kind of website where you absolutely can get good responses from "Show HN: A thing you might want to use and here's how much profit I'm making from it already" until a bunch of green usernames say nice things about it)
More evidence for my theory that the only reason Uber et al are able to exist is because they have an infinite supply of suckers signing up as drivers. Any McJob pays better now.
But driving for Uber is much more pleasant than having a McJob. You can listen to music. You can set your own schedule. If you need more hours to make rent you can work more. If you get tired you can just go home.
Always possible, but the points here are too good to be out of a random brainstorm of what an evil company would do. It sounds very plausible as an exhaustive list of the most important dastardly things an evil delivery company would do.
I remember when everyone was talking how we would all be gig workers and it was going to be the best thing ever. I am eagerly awaiting seeing whose legal department if any poop their pants tomorrow. Maybe if we're lucky we'll even see an 8-K soon.
some countries do a better job of protecting their population from corp psychopath companies.
Australia is one.
but its not enough and the moment the right wing side of Gov gets in they start rolling back a lot of the labor law protections the left wing work at putting in.
> Arguably, the latter isn't really a labor law issue, its an immigration quota issue.
Immigration quotas should probably be considered part of labor laws though, given the impact immigration can have on wages and the job/housing market for natives.
It's really getting in the way of all the daily AI opinion pieces I come here to read.
More seriously, there are tens of thousands of people who come to HN. If Fourier stuff gets upvoted, it's because people find it informative. I happen to know the theory, but I wouldn't gatekeep.
I tried getting into Scala several times and kept going back to Clojure. Unless you are into type system minigames Clojure has many of the things Scala advertises but without the dumptruck of Scala overhead and complexity. Another commenter briefly touched on this but it's a language made by academics for academics to play with language design. It was a little weird it blew up in industry for a while.
> it's a language made by academics for academics to play with language design. It was a little weird it blew up in industry for a while.
Yep. They have always been pretty honest about this.
I think that it blew up in industry because it really was ahead of its time. Type systems were pretty uncool before Scala. It proved that you could get OO and FP in a single type system.
Actually, a big part of reason for doing Scala 3 was rebasing the language on a more rigorous basis for unifying OO and FP. They felt that for all their other big ideas, it was time to rethink the fundamentals.
I’m not up on programming language engineering as much as I should be at 37, could you elaborate a bit here? (To my untrained ear, it sounds like you’re saying Scala was one of the first languages that helped types break through? And I’m thinking that means, like, have int x = 42; or Foo y = new Foo()”
Not types, type-safety. Things like covariant and contravariant type declarations, implicit types (variables looked up by type instead of by label), and other things that you need to make a type safe system/service/application. The problem is that that feature of a language is massively oversold. Its nice but to pretend it prevents bugs or is even a great design goal is questionable and not backed up by research (as they claim).
> Its nice but to pretend it prevents bugs or is even a great design goal is questionable and not backed up by research (as they claim).
That's why people use JavaScript instead of Rust for critical systems, right?
Claiming in the year 2025 that strong static types don't provide massive advantages is almost laughable, TBH. This was settled long ago, and the whole industry now understands that type safety is inevitable to create reliable and scalable systems.
I don't see the chart with changes of number of companies using Scala over time. But even without the chart - if after 15 years there are less than 300 companies in total, that's a bit depressing.
Of course legacy never goes away, and even 20 years down the line there will still be some demand for Scala programmers. Similar to how Cobol still lives on. But in my experience the language isn't growing anymore, even slowly dwindling in userbase. And this became way worse after Scala 3 mess.
The website is a private undertaking which started literally a few days ago. It's not some official complete tracker.
The point was to show that big corps are dependent on Scala, often at their core.
Scala is likely not for everybody, but where you need to write safe high level code there is more or less no alternative, not even on the horizon. Scala is simply very likely where Rust will end up after the honeymoon, when people realize that feature rich, safety first languages aren't for the mass market, where mostly only the cost of initial development counts.
True, Scala (the language) offers lots of great functionality. And Scala 3 brought some important improvements.
But safety is not the only important aspect of a programming language. For me personally the community (libraries, tools, forums, blogs, etc) became much more important over the years, and I feel that Scala 3 really hurt the community angle.
> But safety is not the only important aspect of a programming language.
That's also part of what I've said.
The point still being: Where you need a safe language there is no way around it, and Scala is still one of the very few options you have at all. Scala is in that regard indispensable.
> I feel that Scala 3 really hurt the community angle
I don't see that.
Everything relevant, besides Spark, is now on Scala 3, and this is already like that since a few years.
But I agree that Scala documentation / references / tutorials are to this very day lacking. This was and still is a real issue, and that's actually a very relevant one. I really hope this gets better with time.
The sub-optimal situation regarding docs does though not prevent people from starting new projects in Scala.
In fact Scala 3 is again ahead of the pack. It provides features not seen so far in any real world language and will almost certainly again pioneer the implementation of new language concepts in the large, as it did already in the past with its pragmatic approach to a OOP / FP fusion.
Just see for yourself what is currently happening:
The simplicity of closure is certainly a main part of its appeal. I’ve never done OOP in it, but I don’t think I want to. I have a lot of respect for it though.
reply