Not quite what you're asking for, but I wish Erlang had gotten popular before Java took off. I think that could have massively changed the course of "mainstream" languages. Maybe the JVM itself would have been BEAM-inspired. Heck, in an ideal world, the Netscape corporation and Brendan Eich would have created something based on Erlang/BEAM to ship with Navigator, instead of inventing JavaScript.
Cool! Oracle, a company famous for making good-will decisions, and open to being "urged" into doing the right thing. 🙄
I suppose the open letter is a nice gesture, and I hope that the petition to cancel the trademark succeeds.
Unlikely, unless his view has changed substantially in the last seven years: https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html
I think his views on how to achieve good quality software are nearly antithetical to the goals of Rust. As expressed in that blog post and in Clean Code, he thinks better discipline, particularly through writing lots and lots of explicit unit tests, is the only path to reliable software. Rust, on the other hand, is very much designed to make the compiler and other tooling bear as much of the burden of correctness as possible.
(To be clear, I realize you're kidding. But I do think it's important to know just how at odds the TDD philosophy is from the "safe languages" philosophy.)
I was hoping this might start with some actual evidence that programmers are in fact getting worse. Nope, just a single sentence mentioning "growing concern", followed by paragraphs and paragraphs of pontification.
You get admin privileges on MacOS like a big boy. You can use bash or zsh commands in Terminal all you want.
Cool. So try updating to a version of Bash from the last 15 years, because the pre-installed one is Bash 3, because Bash 4 and 5 are under the GPLv3 license, which Apple won't comply with.
...ah, no, you can't update the pre-installed Bash, because it's on a section of the file system that is read-only even with admin access. You can install Bash 5 as a separate shell, and use that as your default terminal shell, but any scripts written with the standard #!/bin/bash instead of the more flexible #!/usr/bin/env bash will still use Bash 3.
This "handholding" (or really, a safety net) is arguably a good thing, or at least a positive tradeoff; but you can't claim it doesn't exist.
The programming languages you use, and the variety of languages you learn, deeply influence how you think about software design.
Software would be much more reliable (in general) if Erlang had become one of the dominant languages for development.
Go sacrifices too much for superficial simplicity; but I would like to see a language that's nearly as easy to learn, but has a better type system and fewer footguns.
Unit testing is often overrated. It is not good for discovering or protecting against most bugs.
Build/test/deploy infrastructure is a genuinely hard problem that needs better tooling, particularly for testability.
Rust's 1.0 release (i.e. the date on which the language received any sort of stability guarantee) was in 2015, and this article was written in 2019. Measuring the pace of feature development of a four-year-old language by its release notes, and comparing against a 50-year-old language by counting bullet points in Wikipedia articles, is absolutely ridiculous.
Yes, younger languages adopt features more quickly, and Rust was stabilized in a "minimal viable product" state, with many planned features not yet ready for stabilization. So of course the pace of new features in Rust is high compared to older languages. But Wikipedia articles are in no way comparable to release notes as a measure of feature adoption.
I think C is faster, more powerful, and more elegant.
"More elegant" is a matter of opinion. But "faster" and "more powerful" should be measurable in some way. I'm not aware of any evidence that C is "faster" than Rust, and in fact this would be extremely surprising since they can both be optimized with LLVM, and several of the features Rust has that C doesn't, such as generics and ubiquitous strict aliasing, tend to improve performance.
"Powerful" can mean many things, but the most useful meaning I've encountered is essentially "flexibility of application" : that is, a more powerful language can be used in more niches, such as obscure embedded hardware platforms. It's really hard to compete with C in this regard, but that's largely a matter of momentum and historical lock-in: hardware vendors support C because it's currently the lowest common denominator for all hardware and software. There's nothing about Rust the language that makes it inappropriate for hardware vendors to support at a low level. Additionally, GCC is probably the toolchain with the broadest hardware support (even hardware vendors that use a bespoke compiler often do so by forking GCC), and Rust currently has two projects (mrustc and gccrs) working to provide a way to use GCC with Rust. So even the advantage C has in terms of hardware support is narrowing.
But note that there are also niches for which C is widely considered less appropriate than Rust! The most obvious example is probably use in a front-end web application. Yes, C should in theory be usable on the front-end using emscripten, but Rust has had decent support for compiling to WebAssembly almost as long as it's been stabilized.
The trope will be "old" once the mainstream view is no longer that C-style memory management is "good enough".
That said, this particular vulnerability was primarily due to how signals work, which I understand to be kind of unavoidably terrible in any language.
The author also makes some incorrect or misleading claims, specifically about emacs. I acknowledge there's a high bar for entry there and don't personally like emacs, but it's not modal, and it does have the ability to display images and markdown previews.
I was a professional C++ developer for several years, and came to the conclusion that any professional C++ developers who don't acknowledge its flaws have a form of Stockholm Syndrome.
Oh jeeze, you have no idea. You can watch it yourself: https://youtu.be/WiPp9YEBV0Q?si=b3OB4Y9LU-ffJA4c&t=1548
That timestamp is about where the audience member (a maintainer of ext4 and related utilities) starts speaking. The "here's the thing" quote is around 28:40.
It would be a valid point if he weren't literally speaking over the people trying to tell him that they're not demanding he learn Rust: https://youtu.be/WiPp9YEBV0Q?si=b3OB4Y9LU-ffJA4c&t=1548
I know several world class programmers, and interestingly, the commonality among them is that they all seem to use Vim as their code editor. Many people I know who think of themselves as world class programmers use Emacs.
What a burn!
That's true in C as well, though. This is what people mean when they say things like "undefined behavior can result in time travel".
The difference is twofold:
unsafe code are not completely formalized yet. This means that there are open questions about whether particularly complex patterns in unsafe code will be guaranteed by future versions of the compiler to be sound. Conversely, the C and C++ spec are generally sufficient to determine whether any particular piece of code has undefined behavior, even if actually analyzing it to find out is not possible automatically using existing static analysis tools.Rust is extremely geared toward maintainability at the cost of other values such as learnability and iteration speed. Whether it's successful is of course somewhat a matter of opinion (at least until we figure out how to do good quantitative studies on software maintainability), and it is of course possible to write brittle Rust code. But it does make a lot of common errors (including ones Go facilitates) hard or impossible to replicate.
It also strongly pushes toward specific types of abstractions and architectural decisions, which is pretty unique among mainstream languages, and is of course a large part of what critics dislike about it (since that's extremely limiting compared to the freedom most languages give you). But the ability for the compiler to influence the high-level design and code organization is a large part of what makes Rust uniquely maintainability-focused, at least in theory.
And in fact it's not specific to Rust, and Rust is the first language with a fix available. (Thanks to some other comments for pointing this out.) Java has apparently declared it "won't fix."
[warning: "annoying Rust guy" comment incoming]
I don't think Rust is perfect, but arguably I do "idolize" it, because I genuinely think it's notably better both in design and in practice than every other language I've used. This includes:
C
C++
Java
C#
Kotlin
Scala
Python
Ruby
JavaScript (...I've barely used this, but I doubt my opinion would change on this one)
Perl
Go
Bash (...look, I've had to write actual nontrivial scripts with loops and functions, so yes, Bash is a real language; it just sucks)
Tcl/Tk (if you don't know, don't ask)
CommonLisp (...again, I've barely used this, and I wish I had more experience with this and other Lisps)
In a literal sense, I agree that all (practical) languages "are flawed." And there are things I appreciate about all of the above languages (...except Tcl/Tk), even if I don't "like" the language overall. But I sincerely believe that statements like "all languages are flawed" and "use the best tool for the job" tend to imply that all (modern, mainstream) languages are equally flawed, just in different ways, which is absolutely not true. And in particular, it used to be true that all languages made tradeoffs between a fairly static, global set of binary criteria:
safety/correctness versus "power" (i.e. low-level system control)
safety/correctness versus run-time efficiency (both parallelism and high single-thread performance)
ease-of-use/ease-of-learning versus "power" and runtime-efficiency
implementation simplicity versus feature-richness
build-time versus run-time efficiency
type-safety versus runtime flexibility
Looking at these, it's pretty easy to see where most of the languages in my list above fall on each side of each of these criteria. What's special about Rust is that the core language design prevents a relatively novel set of tradeoffs, allowing it to choose "both" for the first two criteria (though certainly not the latter three; the "ease-of-use" one is debatable) at the expense of higher implementation complexity and a steeper learning curve.
The great thing about this isn't that Rust has "solved" the problem of language tradeoffs. It's that Rust has broadened the space of available tradeoffs. The assumption that safety necessarily comes at a runtime cost was so pervasive prior to Rust that some engineers still believe it. But now, Rust has proven, empirically, that this is not the case! And so my ultimate hope for Rust isn't that it becomes ubiquitous; it's that it inspires even better languages, or at least, more languages that use concepts Rust has brought to the mainstream (such as sum-types) as a means to explore new design tradeoff spaces. (The standard example here is a language with a lightweight garbage-collecting runtime that also has traits, sum-types, and correct-by-default parallelism.)
There are other languages that, based on what I know about them, might inspire the same type of enthusiasm if I were to actually use them more:
...but, with the exception of Swift, these are all effectively "niche" languages. One notable thing about Rust is that its adoption has actually been rather astounding, by systems language standards. (Note that D and Ada never even got close to Rust's popularity.)
Neovim is a fork; it's compatible with those.
rm - rf is the only version that makes sense, since the only reason to delete and re-clone is to recover from an unexpected .git/ state, and git rm won't remove that.
Perl programs are, by definition, text. So "paint splatters are valid Perl" implies that there's a mapping from paint splatters to text.
Do you have a suggested mapping of paint splatters to text that would be more "accurate" than OCR? And do you really think it would result in fewer valid Perl programs?
Go if you want a real mental challenge
I don't mean to be rude, but I find this baffling; what do you mean by it? One of the primary design goals of Go is to be simple to learn (this is fairly well documented), and it's one of the few things I really have to give the language credit for. Rob Pike has specifically discussed wanting it to be accessible to recent CS graduates who have mostly used Java. I have never heard anyone before describe learning Go as a "challenge."
This is as funny as the Clyde response, arguably funnier.
Surprised nobody has complained so far about the Rust comparison. I guess any objection would appear to prove the point, or at least reinforce the "evangelist" stereotype.
There are a fair number of them: https://en.m.wikipedia.org/wiki/Non-English-based_programming_languages
But arguably, as long as the compiler supports unicode, it shouldn't matter that much what language the keywords are in. There are other more important issues impacting how easy it is to program in non-English languages:
It's probably just easier to do all arithmetic in bc so that there's no need to analyze expressions for Bash support and have two separate arithmetic codegen paths.
He spent four years as the project maintainer. That's hardly "flouncing off."
I don't really understand the connection between the blog post and your comment. Could you expand on the connection between his stance against CLAs and your paraphrase about mega-corps and how we should "suck it up because of principles"?
The animation that goes with this is pretty slick: https://x.com/Phantom_TheGame/status/1748457358521426375?s=20
...why not both? An auto-formatter for personal use, a linter for CI checks on PRs.
I read "happy ___ starts with ___" as stating that happiness was the eventual result of a process that started with ___.
Oh hey, it's modern ed!
The reason C becomes relevant to Python users isn't typically because the interpreter is written in C, but because so many important libraries (especially numpy) are implemented in C.
I haven't worked on any teams where all members committed "every 24 hours", and there have always been some branches that live longer than we'd like (usually just unfinished work that got deprioritized but still kept as an eventual "todo"), but most teams I've worked on have indeed followed the basic pattern of only one long-lived branch, reviews and CI required prior to merge, and all feature-branches being short-lived.
What do you mean, "breaking"? This isn't a new encoding scheme, it's an informational page showing ASCII encoding.
I'm pretty sure that when programmers and other techies call themselves "hackers", they don't mean in the security-breaching sense. It means that you can "hack together" something.
It's relevant because there are still platforms that don't have actual Bash (e.g. containers using Busybox).
sh is not just a symlink: when invoked using the symlink, the target binary must run in POSIX compliant mode. So it's effectively a sub-dialect.
Amber compiles to a language, not to a binary. So "why doesn't it compile to sh" is a perfectly reasonable question, and refers to the POSIX shell dialect, not to the /bin/sh symlink itself.
In this context, stabilization refers to the adoption growth curve flattening out.
By Ada getting it right, I assume you mean throwing an exception on any overflow? (Apparently this behavior was optional in older versions of GNAT.) Why is Ada's preferable to Rust's?
In Rust, integer overflow panics by default in debug mode but wraps silently in release mode; but, optionally, you can specify wrapping, checked (panicking), or unchecked behavior for a specific operation, so that optimization level doesn't affect the behavior. This makes sense to me; the unoptimized version is the same as Ada, and the optimized version is not UB, but you can control the behavior explicitly when necessary.
Well, except "robust", unless you have very strict code standards, review processes, and static analysis.
(And arguably it's never elegant, though that's almost purely a matter of taste.)
The logo and "join our Discord" text are more than half cut off for me. Is that the original cropping, or is it a client (Jerboa) issue?