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.
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.
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.
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 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."
Neovim is a fork; it's compatible with those.
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.
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.
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 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"?
Oh hey, it's modern ed!
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.
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.
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.
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.)
And even if releases are hosted on github, there should ideally be a download links page somewhere that presents the different binaries or installation files in an easier to understand format, especially if the software is designed for non-developers.
ed, the "standard editor" (according to its man page) and the predecessor of vi (the "visual editor"), is a terminal editor that doesn't automatically display any of the text you're working on; you have to use the p ("print") command to display the lines your wish to see.
I really like that it follows this up with, effectively, "we're done here, get out"
OOP is classes, and their accompanying language features (primarily inheritance) and design patterns (e.g. factories).
To be fair, I'm a pretty thorough code reviewer and I've definitely made a mistake of this kind.
I mean to be fair, that's a pretty useful tool.
git checkout ma
If you don't have autocomplete set up for your shell, get it working. If someone has a different branch named ma..., ask if you can delete it, and get your team to adopt a decent branch naming convention.
I've met people with C++ Stockholm Syndrome, and I think their trajectory is different. There's no asymptotic approach toward zero; their appreciation just grows or stays steady, even decades into their career.
I agree so, so much; and I've been saying similar things for years.
But I recognize that it's probably a hard problem. For one thing, auth is almost never going to work the same way in CI as it does locally.
...still, though, I feel like there could be some much nicer tooling here.
It's simply not true that there "aren't really that many definitions of OOP", much less that the guide you've linked is "comprehensive" when it is specifically about Java.
This is a good, brief post about the different conflicting definitions: https://paulgraham.com/reesoo.html
This is a much more comprehensive but also less focused overview, with many links, from a site that is effectively both a wiki and a forum: https://wiki.c2.com/?ReesOnObjectOrientedFeatures
I very much understand thinking that Rust has too much hype, but the differences between C and Rust are so fundamental that "switching between" them just to "keep your interest fresh" seems ill-advised to me. To be honest, your statements about both C and Rust so far seem pretty superficial; have you actually used Rust for anything nontrivial?
C syntax is simple, yes, but C semantics are not; there have been numerous attempts to quantify what percentage of C and C++ software bugs and/or security vulnerabilities are due to the lack of memory safety in these languages, and although the results have varied widely, the most conservative estimate (this blog post about curl; see the section "C is unsafe and always will be") ended up with an estimate of 40%, or 50% if you only count critical bugs. If I recall correctly, Microsoft did a similar study on one of their projects and declared a rate closer to 70%.
This means that the choice of language is not just about personal preference. Bugs aren't just extra work for software developers; they affect all users of software, which means they affect pretty much everyone. And, crucially, they're not just annoyances; cyberattacks of various kinds are extremely prevalent and can have a huge impact on people. So if 50% or more of critical software vulnerabilities are due to the choice of language, then that is a very good reason to pick a safer language.
Rust is not the only choice for memory-safe languages. If you like the simplicity of C, you should definitely learn Go (it's explicitly designed to be as simple as possible to learn). But I would also strongly recommend looking into Zig, which hews much closer to C than Rust does; in fact, it has probably the best interoperability with C of any modern language.
This is probably the most well-researched piece of writing on the matter: https://www.hillelwayne.com/post/are-we-really-engineers/
It's still pretty bad that the normal equality operator is as bad as it is.
BEAMScript!
Oof, slow compile times to target, of all things, the JVM? Implicit methods? Some(null)? Function call syntax where the difference between a tuple argument and a sequence of non-tuple arguments can be determined by whether or not there's a space before the parentheses?
There are definitely some major issues with Scala.
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?