Should programming languages be safe or powerful?

https://lambdaland.org/posts/2024-11-21_powerful_or_safe_languages/

by soegaard • 2 years ago

92 130 2 years ago

kazinator7• 2 years ago

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.

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.

doublerabbit3• 2 years ago

Programming languages should be safe by default

I disagree. Programming languages should teach you how to program safely.

It's the same with construction, here's your brick. You can either use cement or not. Both will build a tower but one will topple and one will not.

Programming is the same. Here's your compiler, program your tower without garbage collection and watch it topple.

If you don't wish to learn how to program safely then choose a language that does it for you. But don't moan because you refuse to learn how to program safely.

Most languages are derived from C anyway so your coding in C but just in the way how the developer wants you to code in C.

kazinator7• 2 years ago

You can't program safely in an unsafe language. You can program correctly so nothing bad happens, but it's still unsafe code. Just like a tightrope walk between two buildings without a safety net is unsafe even if you're very good at it and never fall down.

A programming language has multiple safety modes and is safe by default could be used as a tool for teaching a range of concepts.

nicoburns2• 2 years ago

> Programming languages should be safe by default
I disagree. Programming languages should teach you how to program safely.

One of the best things about safe-by-default languages is that they do teach you to program safely! If your program fails to compile you then have to go and find out why, and that's a fantastic learning opportunity.

In languages where there are no guard rails, it's much more difficult to work out what you don't know that you don't know.

CJefferson2• 2 years ago

Let's compare to building (this is in the UK, but I think most countries have similar rules).

If someone asks you to build a house, you need to make a plan, and get it signed off. There are lots of rules on what you can, and can't do.

If you build a house without cement, by just piling bricks up, you will get fined and be told to take it down and build it again. If that house you badly built falls down and kills someone, you go to jail.

yearolinuxdsktp2• 2 years ago

I bet we disagree on what unsafe means. Many here think tåhat shipping a non-final/open/inheritable class is unsafe. I think doing so stunts your code base’s and ecosystem’s evolution.

And when push comes to shove and you have to address an issue in a 3rd party library, and you are unable to override a single thing that would fix your problem because everything is closed by default, then you will tell your manager it can’t be done, and serious money or opportunity will be wasted and customers will suffer for longer, because you are coding in a really safe language. Is this progress for humanity? I think not!

mike_hearn4• 2 years ago

That's a slightly different issue. I don't think people consider visibility attributes under the rubric of safety, usually, except in sandboxed contexts.

That's more a problem of build tooling. It should be possible to modify visibility/finality levels in libraries as you download them. Gradle can do something like this with some work, but someone should make a plugin to automate it. That way the upstream can set things private/final/sealed as correct for their API guarantees and design, and downstream can apply hacks to open things up if that's easier than forking the source code, and there's a single place in the build system that collects all the places where there's a mismatch.

kazinator7• 2 years ago

I've made it explicit what I believe safe means. I could discuss it in more detail, but I won't be changing my definition.

I would never do such a barbaric thing as adding a non-inheritable class to an object system. Or, if I were convinced to, it would be purely for performance, not as a way of restricting the programmer; i.e. for speeding up things due to the compiler knowing that the class is final.

tasuki2• 2 years ago

Composition over inheritance! (If you absolutely must do OOP)

buggy6257• 2 years ago

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/4 of the article telling you about it.

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

zahlman• 2 years ago

Since we're avoiding clickbait: the language in question is Racket.

zelphirkalt2• 2 years ago

Ha, funny, because I thought: "Both, of course. Like for example Schemes." and while Racket is not a Scheme according to the maintainers, it certainly shows the similar safety and power that other languages like it show.

ashton3143• 2 years ago

Haha, yeah it’s a little clickbaity. Less clickbaity might have been “Safety and power needn’t be a trade-off”.

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.

tasuki2• 2 years ago

Many people care more about shipping (perhaps buggy) software rather than the theoretics of programming languages. I used to despise that, these days I think I understand it.

Still, I'm sad the industry is stuck with languages such as Python and Java, rather than say Racket and Idris...

adrian_b• 2 years ago

The thesis that safety and power are incompatible seems mostly a straw man, because there are very few cases when a tradeoff between them may be necessary.

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).

codethief• 2 years ago

I agree the title is a bit clickbaity but I don't think it's justified to dismiss the entire article on that basis. The author makes some very good points and while I had heard of Racket, I wasn't aware of how its macro system differed from Lisp & Scheme. Moreover, discovering you can implement type systems as macros[0] alone made reading the blog post worth my while. But as always YMMV.

[0] https://lambdaland.org/posts/2023-08-14_types_with_macros/

roca3• 2 years ago

If you want to write device drivers, then C is great for you.

No, it really isn't. It's 2024, people who should know better should stop saying this.

yjftsjthsd-h4• 2 years ago

Alright, I'll assume you know better; what should we use? Preferably on a variety of OSs; ex. I imagine you can write Windows or Haiku drivers in C++, but I'm only aware of C being an option in any BSD, and Linux support for anything but C is spotty (obviously Rust is making headway, but last I heard you could only write certain kinds of drivers using it as the underlying support is built out).

samatman2• 2 years ago

If your platform is supported by LLVM, Zig is worth serious consideration. It is able to target any of the operating systems you mention, from any of the operating systems you mention. Linking to the syscall interface / libc / C libraries is straightforward, exporting functions which respect the local ABI is quite simple.

gpm• 2 years ago

For what it's worth, on Windows Rust is also a Microsoft supported, though "not yet recommended for production use", option.

https://techcommunity.microsoft.com/blog/surfaceitpro/open-s... / https://github.com/microsoft/windows-drivers-rs

roca3• 2 years ago

C being the only option doesn't make it a great option.

adastra22• 2 years ago

Whatever else your platform supports. Literally anything else would be better, other than raw assembly.

Usually there are some options. Rust is supported (to a degree) on both Linux and Windows. Both macOS and Windows support C++, which if used correctly is at least safer than C.

elcritch2• 2 years ago

I've wanted to try writing a Linux driver in Nim for fun.

I've ported and used Nim in a couple of RTOS'es and it's pretty straightforward. Of course there wouldn't be official support or anything, but it wouldn't be too hard. Mapping pointers to Nims RC refs would be a bit tricky, but doable.

glouwbug2• 2 years ago

In reality, if you know your requirements up front, you do not need to dynamically allocated memory

kstrauser7• 2 years ago

My requirement is to store and process arbitrary uploaded data. How’s that work out?

Rochus3• 2 years ago

What else would you use instead of C?

roca3• 2 years ago

Rust if possible. But really my point was that even if C is your only option, it should not be considered "great".

AzzieElbab• 2 years ago

tldr - should your language be Lisp or Haskell?

lizzas2• 2 years ago

Hard and soft tacos :) Racket is both.

sourcepluck• 2 years ago

Could you elaborate?

Motivation: looking at racket these days, and have ordered "how to design programs" in the library :)

CodeWriter232• 2 years ago

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.

stvltvs• 2 years ago

Funny, I would expect the opposite, or at least there would be a different class of problems with LLM assisted C. What guardrails would prevent this, and if there are no tradeoffs with the power of C, why haven't we put those guardrails on for human crafted code?

glouwbug2• 2 years ago

Static analyzers be entering a new era

superb_dev• 2 years ago

How? I don’t see the connection

wffurr• 2 years ago

Generated C code can be safer than hand written C code if you can prove properties of the generator or carefully test and review the generator itself.

2 examples that come to mind are wuffs and wasm2c. Both produce C code that can be shown to be safe due to the properties of the code generator and its input language.

I am not sure LLM output is amenable to same kind of analysis, but you could conceive of an LLM trained on exclusively safe code.

ashton3143• 2 years ago

Strong disagree. Unless you're talking about using an LLM to help transform C into e.g. Rust. I don't see formal methods being unseated by probabilistic techniques (LLMs included) any time soon.

Rochus3• 2 years ago

I don't understand why people downvote this comment. It is perfectly reasonable and we can assume with no doubt that AI based analyzers become much better in future in analyzing large code bases and discovering unhandled states, or deviations from specifications, or contradictions or specification gaps.

acdha2• 2 years ago

C is unsafe by design, especially once you think about things like your code calling and being called by other code which you don’t develop. An IDE can only help so much unless what we’re saying is that you’re using it to convert logic into an actually-safe language like Rust.

CodeWriter232• 2 years ago

IDC about being downvoted, got points to burn. But I would like some downvoters to explain how given:

A) “safe” languages at compile time or run time can avoid vulnerabilities

B) it is possible for a human to code safe patterns in an unsafe language (human error notwithstanding)

C) an LLM can detect patterns even adapt to an individual coder’s style

And then conclude:

There’s no possible way an LLM in real time can detect known vulnerability-causing patterns and recommend safe patterns

I’ll wait…

MrMcCall3• 2 years ago

Regardless of the safety constructs or lack thereof in a programming language/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"m concerned with.

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.

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.

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.

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 all our technologies depend on software systems.

kstrauser7• 2 years ago

It doesn’t help that the customer asks us for a bridge for a bicyclist, uses it as a highway for semi trucks, and refuses to perform scheduled maintenance on it while attackers shoot rockets at the foundation.

There are many parts of our discipline that are immature, in addition to the implementation bits.

MrMcCall3• 2 years ago

Nothing could be more immature, in my experience, than the non-technical folks that ask for software from us within the corporate environment.

And, yes, you are bang-on correct. For one thing, our specifications, themselves, are sorely lacking in specifications!

It's half-assed all the way down.

zeroCalories• 2 years ago

Yes, this was another boring shill article for Haskell/Rust. The hard part of software engineering is correctly understanding and modeling the domain. Most other issues are trivially resolved by good practices. This only solves issues for codebases that have a train ran on them by interns and junior devs, which is great if you're in that situation, but is unbelievable frustrating for people that don't have that issue

voidhorse• 2 years ago

If only I could upvote this comment more. The software engineering industry has a loooong way to go, and we'd be much better served if more people actually got it and thought like you instead of wasting time on things like language wars. That's not to say we shouldn't continually strive for better languages, just as we continually strive for better materials to build bridges with, but proselytizing for a language is a complete waste of time when half of the so-called engineers in this so-called engineering discipline do not even realize that engineering is not mere programming. It'd be analogous to the civil engineering discipline spending thousands of hours debating which materials are better before even figuring out how to actually construct a bridge, out of any material consistently and within boundary conditions.

The fact that we call software engineering "engineering" is still a complete joke in the majority of cases (there are exceptions of course) at this point in time.

MrMcCall3• 2 years ago

Yes yes.

I use the term "software engineering" aspirationally, not as statement of fact :-)

revskill• 2 years ago

Engineering only when the software is correctly verified.

kstrauser7• 2 years ago

Well, to a point. It feels like some engineers are proposing to start building bridges out of wood, and others want to keep building them out of spoons and toothpaste, just like their pappy did.

ghssds• 2 years ago

I have a hard time understanding why programmers so much want to be called software engineers. Lawyers don't want to be called contract engineers. Writers don't want to be called text engineers. Film directors don't want to be called movie engineers. The industry has a long way to go for sure, but maybe it's not to become better engineers but to better understand that they aren't engineers after all.

djbusby• 2 years ago

brutally test them

I cut my teeth in the industry on the test side at MS; it was a bit adversarial with the dev side. And there was a third side to get us both on documentation.

It was frustrating but, I think we made Good Stuff (NT4, Win2k).

I have not seen that rigor since.

jghn2• 2 years ago

I'm getting pretty tired of hearing about "safe" rust. And I love Rust. The language's promoters are pushing a vision of a world that's just not true. And while memory bugs are an important class of issues, logic bugs are even larger.

kstrauser7• 2 years ago

Sure! On the other hand, if the compiler’s keeping me from writing memory bugs, I have more time and mental bandwidth to spend on avoiding logic bugs.

The same’s true with languages other than Rust, too. It’s not the only popular memory safe language.

Animats• 2 years ago

This article is mostly about macro systems. Those are usually troublesome. But they are independent of run-time safety issues.

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's "derive" facility and the serialize/deserialize functions. Those have a simple user interface which hides the internal complexity.

throwaway17_172• 2 years ago

I know, based on your very informative and large post history, that your point is surely more nuanced. But this just reads as any macros that are not Rust macros are wrong, even when they are very similar.

I just do not understand the implied difference (and I have seen comments similar to this sentiment more than just this once). Rust has macros, both of the procedural and ‘syntax-case’ style. Semantically, AFAIK, they are true macros like in Racket or any other language with full meta-syntactic programming options. They are not better typed nor more resilient to errors, nor are they used less pervasively that other languages with macros. Why is it that Rust gets a pass, when other language receive the ‘Macros is bad’ treatment?

lizzas2• 2 years ago

They mean bug unsafe generally not memory unsafe specifically.

I was gonna say "what about Racket"! And that is what they land on.

FpUser• 2 years ago

Summary: Ode to the things author loves - immutability and Racket.

"name = get_user_name(user)"
"and I didn’t have to worry about user getting modified in the call to get_user_name."

If you have this case it is not the language you should worry about but a moron programmer you work with.

rafram• 2 years ago

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.

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value'

ashton3143• 2 years ago

When you call `unwrap` you know that you’re opting-in to unhandled panics at that specific point. At no time to you have to assume something is null—the type system prohibits consuming a value of type Option<T> as if it were a naked T.

winstonewert• 2 years ago

But the great thing about Rust is that the panic traces back to the exact place where I thought something couldn't be None, but it was. In Java, I frequently found it mysterious why some variable or parameter was unexpectedly null.

mike_hearn4• 2 years ago

Kotlin fixes that, fwiw. Nullity is checked and casted away at the earliest possible time (modulo some ergonomic constraints like a.b.c but modern JVMs give better errors for cases like that).

bobnamob2• 2 years ago

grep for .unwrap() and you now have a handy list of every (potential) “null ptr” deref in your rust codebase, try doing the same in Java. You’d need to grep for “.”, I’m sure that’ll be a nice short list

lilly-lizard• 2 years ago

for me personally, the trade off between me writing in memory safe rust vs comparably "powerful" 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'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've always thought it was weird how people discuss the trade-off as safety vs powerfulness

jasfi• 2 years ago

I find Nim to have excellent trade-offs for writing system software. It's so much easier to write than Rust, but is also safe.

oneshtein• 2 years ago

C++ has ASAN, valgring, and other checkers to wrestle with.

seanhunter• 2 years ago

I wonder how it will pan out in aggregate when you amortise the productivity of sprinting to produce something vs crawling to fix the problems. In C++ although you are not wrestling with a borrow checker you do find yourself going fast down deep dark tunnels that take ages to get out of. In rust it might be you move instantaneously slower but faster on average but it might take time to gather that data.

For exampe I once had to help someone debug some C++ memory leaks in a vast codebase in jobs that took hours for each valgrind run. It was two of us for two weeks to eventually find and fix the problem and the fix was maybe (from memory) 10 lines tops. Not exactly productive. But the person writing the couple of hundred lines that created the problem probably felt quite productive while doing so.

mock-possum• 2 years ago

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.”

Less safe more powerful gives you more options.

You can always make things less safe - it’s hard to make them more powerful.

ChadNauseam• 2 years ago

On the other hand, when writing C++, I very regularly wish it was more safe, even if that would come at the cost of it being less expressive

tbrownaw2• 2 years ago

Isn't a language being "powerful" mostly about having comprehensive libraries ("import antigravity" and such)?

And then of course "safe" means you can't express things you shouldn't want to express, like buffer overflows or arithmetic overflows or SQL injections, or these days prompt injections.

bobnamob2• 2 years ago

Ime, language “power” is usually used to describe the expressivity and flexibility of the language itself.

As an extreme example, Starlark isn’t a powerful language, it isn’t even Turing complete afaik. This is advertised as a positive attribute for a build description language (I don’t have an opinion, never used it myself).

Conversely, C would classify as a powerful language even considering how barebones it is from a “feature” perspective . Poke any memory however you like is a pretty powerful power

more_corn• 2 years ago

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

bmicraft2• 2 years ago

Yes.

ashoeafoot• 2 years ago

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.

All within one engine, your elders giving and taking your freedom.

ramses0• 2 years ago

I actually like Deno's take on things, the ability to "drop privs" (or "allow-list") is super powerful.

Starlark is supposedly a limited version of python (https://github.com/bazelbuild/starlark), but what if you could say in python itself:

    def foo():
        """use strict; use no_func_calls; use idempotent; use no_loops; ..."""
        ...checked python here...

...or being able to make assertions within a body of a for loop or something.

I feel that programming languages need to evolve to deal with a hostile dependency ecosystem, eg:

    import leftpad as lp with {
      network: false,
      filesystem: false, 
      environment: false,
      max_cycles: 100_000,
      max_mem: 10_000,
      ...etc...
    }

...this is purely arbitrary and hypothetical, of course, but programs become safer when made from safer, more-structured components.

We're long past the "single programmer write all the code" phase, and in to the spiral of exponential code+complexity, but no programming languages give you the ability to wrestle with that complexity.

0points• 2 years ago

Both, see rust.

sega_sai2• 2 years ago

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).

evoke4908• 2 years ago

C# is the first thing to come to mind. If you so choose you can more or less inline C and trample all over memory, or you can write very strict, statically typed, safe code.

HdS84• 2 years ago

C# has unsafe, which extremely powerful. See ravens repo for heavy usage of that.

Otherwise python is also a good example of that. First start out in python. Not fast enough? Bring in python, which compiles down to c. Id that's not enough, drop to raw c.

LectronPusher• 2 years ago

You would likely be interested in Jamie Brandon's work on the Zest language [1] which has planned "lax", "strict", and "kernel" modes for varying levels of performance/safety

[1] https://www.scattered-thoughts.net/writing/zest-dialects-and...

awinter-py• 2 years ago

have had this argument for library code

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's happening, and the base and the mantissa have different types

and you end up with no general code anywhere because reusability is not even an afterthought, it is counter to the project

if you've never met this person I sound insane but I swear they exist

2OEH8eoCRo0• 2 years ago

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

Should programming languages be safe or powerful?

Related Stories