Should programming languages be safe or powerful?

For those skipping to comments based on title alone, this isn’t really much discussion about a trade off. It starts that way and then goes “but with my favorite language you can have both!” And spends 3&#x2F;4 of the article telling you about it.<p>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.<p>This article isn’t bad but the name is terrible and a bit clickbaity

Regardless of the safety constructs or lack thereof in a programming language&#x2F;environment, our job as software engineers is to construct programs that perform as per their dataflow requirements. That is the only kind of safety I&quot;m concerned with.<p>That can be accomplished for most software projects in most programming environments and their languages, to more or less extent within their limitations, given a proper amount of hard graft to choose the proper constructs and then brutally test them.<p>Power, on the other hand, must be dependent on what is required to wring safety out of the limitations, weaknesses, and pitfalls of the chosen implementation tooling. Power can include speed of development, speed of execution, amount of concurrency, fault tolerance, and so on. Regardless, power must be built upon safe software constructs, safe in the sense that the resulting system performs as intended.<p>A civil engineer will know that a specific kind of bridge constructed out of certain materials using certain techniques will be able to withstand certain events like an earthquake of a certain magnitude and will be able to perform at a certain level, such as tons of traffic at a time or somesuch. As well, they will have a pretty good idea of how long it will take to build it. Such is the maturity (and relative simplicity!) of bridge building.<p>We have no such framework in our industry. Focusing on programming languages shows the immaturity of our industry, which is the most difficult we have yet undertaken as a technological civilization. The proof of that statement is that <i>all</i> our technologies depend on software systems.

Programming languages should be safe by default, except in clearly delimited sections of code (as small as a single expression) where the programmer requests less safety.<p>Safety is the property that erroneous situations are intercepted and diagnosed, rather than running off with incorrect results or behaving unpredictably. It can be a continuum based on the number and kinds of situations that are treated safely.

Should all arguments be phrased using the false choice fallacy or should we have ice cream for dinner?

Isn&#x27;t a language being &quot;powerful&quot; mostly about having comprehensive libraries (&quot;import antigravity&quot; and such)?<p>And then of course &quot;safe&quot; means you can&#x27;t express things you shouldn&#x27;t want to express, like buffer overflows or arithmetic overflows or SQL injections, or these days prompt injections.

Both. It should be a inverted pyramid,starting at the likes of lua, condense to something c#, then the training wheels come off for deep low level access and stranger high level concepts.<p>All within one engine, your elders giving and taking your freedom.

for me personally, the trade off between me writing in memory safe rust vs comparably &quot;powerful&quot; C++ is coding speed. I think C++ is a mess and have been using rust for my personal projects for the past 2 years but I still feel like I code faster in C++ because I don&#x27;t lose time wrestling with the borrow checker. Rust has some fantastic design decisions and features (despite it being a relatively immature language) so I&#x27;ve always thought it was weird how people discuss the trade-off as safety vs powerfulness

They mean bug unsafe generally not memory unsafe specifically.<p>I was gonna say &quot;what about Racket&quot;! And that is what they land on.

have had this argument for library code<p>I have met a style of programmer who thinks, on some level, that generally reusable code is unsafe -- like the `sum` function (stupid reductive example) is not okay unless it has a bunch of business logic restricting the range of the numbers and takes a logger just in case, and the function name is eight words describing exactly what&#x27;s happening, and the base and the mantissa have different types<p>and you end up with no general code anywhere because reusability is not even an afterthought, it is counter to the project<p>if you&#x27;ve never met this person I sound insane but I swear they exist

As mentioned by others, the article does not really tackle the question. But it is an interesting question, and I think it would be great to have a language that you could adjust the safety without major rewrites. I.e. various degrees of strict modes. At the times of LLMs, I wonder if anyone looked into some sort of sliding-scale transformation of code from safer, to easier to write. (although I am not sure there are good languages that are expressive enough for that).

Summary: Ode to the things author loves - immutability and Racket.<p>&gt;&quot;name = get_user_name(user)&quot;<p>&gt;&quot;and I didn’t have to worry about user getting modified in the call to get_user_name.&quot;<p>If you have this case it is not the language you should worry about but a moron programmer you work with.

Is it really programming if you can&#x27;t do pointer arithmetic and poke memory addresses? I suppose so but you&#x27;re not really programming for a machine you&#x27;re playing in some language developer&#x27;s bubble-wrapped sandbox.

In my experience that it’s uncommon to find yourself thinking “I wish this language was less powerful” - far more common to find yourself thinking “I wish this language was less safe.”<p>Less safe more powerful gives you more options.<p>You can always make things less safe - it’s hard to make them more powerful.

&gt; Rust doesn’t have null like in Java, but you know when you get a pointer, you can safely dereference it and you don’t have to do all the null checking that you have to do in Java.<p>thread &#x27;main&#x27; panicked at &#x27;called `Option::unwrap()` on a `None` value&#x27;

Both, see rust.

tldr - should your language be Lisp or Haskell?

This article is mostly about macro systems. Those are usually troublesome. But they are independent of run-time safety issues.<p>Macros tend to be hard to read. LISP macros and C++ templates are the usual bad examples. As the article points out, Rust procedural macros are not all that great. They do, though, power Rust&#x27;s &quot;derive&quot; facility and the serialize&#x2F;deserialize functions. Those have a simple user interface which hides the internal complexity.

&gt; If you want to write device drivers, then C is great for you.<p>No, it really isn&#x27;t. It&#x27;s 2024, people who should know better should stop saying this.

I think the emergence of the LLM-integrated IDE can be leveraged to transform a powerful yet unsafe language like c into a safe language.