The most value from this article is the clickbait title yielding some interesting discussion from people on that question outside of the actual article contents.
This article isn’t bad but the name is terrible and a bit clickbaity
The biggest difference is that in Racket, cons cells, and thus lists, are immutable (the Scheme #langs like r5rs use a different incompatible type for their conses). There's other more subtle changes but that's the one most likely to bite people used to Scheme. Well, that and `if` taking exactly 3 arguments.
Are they not both turing-complete?
"On the expressive power of programming languages" Matthias Felleisen
https://www.sciencedirect.com/science/article/pii/0167642391...
Abstract
The literature on programming languages contains an abundance of informal claims on the relative expressive power of programming languages, but there is no framework for formalizing such statements nor for deriving interesting consequences. As a first step in this direction, we develop a formal notion of expressiveness and investigate its properties. To validate the theory, we analyze some widely held beliefs about the expressive power of several extensions of functional languages. Based on these results, we believe that our system correctly captures many of the informal ideas on expressiveness, and that it constitutes a foundation for further research in this direction.
Two languages are theoretically equally powerful only if they can produce functionally identical machine code in any situation.
On the other hand I found using multiple cores much easier in GNU Guile.
[0]: https://lambdaland.org/posts/2023-08-14_types_with_macros/
I wrote this out of some frustrations I had from a conversation with a user on this site about macros, actually. This is why I spend so much time on Racket. I’m also a PL researcher and I work with Racket a bunch.
It’s not just Racket where the trade-off shouldn’t be necessary, but Racket is a good example because it’s like one big exercise in making some powerful language features safe.
For example adding to a programming language array operations in the APL style greatly increases its power while simultaneously increasing its safety by eliminating all bugs that can occur due to mishandling of indices a.k.a. subscripts that would be needed otherwise to access array elements.
There are a lot of other such examples where adding high-level operations increases the power of a programming language while also eliminating some classes of bugs.
The only kind of "power" that can conflict with safety is the necessity of implementing various kinds of low-level operations whose functionality is not provided by any high-level operation of that programming language, e.g. some that may need to access various data types as bit strings or to use directly certain features of the CPU that are normally ignored by that programming language.
In this case it is not actually "power" that is in conflict with safety, but the desire of portability, i.e. of independence on the architecture of the target CPU, which prevents the addition to the programming language of features corresponding to everything that a CPU can do.
For most features that are unsafe in practice, it might have been possible to define safer higher-level methods to use them, but the obstacle has been the lack of standardization, i.e. the fact that they may be implemented differently in every computing system, so it may be hard to design an equivalent feature included in a general-purpose programming language that could be mapped in an efficient way to what a certain hardware does.
Much of the lack of safety of some modern programming languages is not caused by too much power, but by too little power, because they have inherited the lack of power of the minicomputers and microcomputers of 50 years ago, where the restricted programming languages available for them had abandoned many of the powerful and safe features of the older programming languages, from 60 to 70 years ago, where it had been inconceivable to have a program where any computation error, like integer overflow, would not generate an exception, or where it would be possible to access memory through indices or pointers in areas not intended, also without generating an exception.
The lack of runtime error checks for a program is a lack of power, not a sign of power (while I use frequently languages like C or C++, I always compile them in the right way, enabling all runtime checks).
Still, I'm sad the industry is stuck with languages such as Python and Java, rather than say Racket and Idris...