Hacker News Reader

Comment by thrtythreeforty | Hacker News Reader

I find the section on "syntactic salt" interesting:

> The opposite of syntactic sugar, a feature designed to make it harder to write bad code. Specifically, syntactic salt is a hoop the programmer must jump through just to prove that he knows what’s going on, rather than to express a program action.

This is perhaps an uncharitable way to describe it, but the concept does ring a bell. Rust's unsafe {}, C++'s reinterpret_cast<>(), etc - all slightly verbose. More important than jumping through hoops, the verbosity helps when reading code to know that something out of the ordinary is going on.

View on HN

And then there's Perl's "syntactic syrup of ipecac".

https://en.wikipedia.org/wiki/Syrup_of_ipecac

This reminds me of Reacts "dangerouslySetInnerHTML" prop.

https://reactjs.org/docs/dom-elements.html#dangerouslysetinn...

> syntactic salt

I feel like this describes Rust's lifetime annotations pretty well too.

Not just lifetimes but types used to do more complex lifetimes that are normalized by other languages like RefCell, Arc, etc.

I disagree about lifetime annotations being syntax salt. At least with my interpretation of what syntax salt.

From syntax perspective lifetime annotations are almost as short as possible assuming you want to explicitly convey this information at all ('a is just two symbols and one of them is identifier). The alternative of not specifying it at all comes with major tradeoffs of either in memory safety (like in C) or runtime performance (like most programming languages with dynamic memory management). In theory there is third option of compiler fully deducing lifetimes, but that's far from trivial, has it's own costs and realistically even further narrow down what programs the compiler considers valid and increasing compilation time.

There are strong similarities with typing strategies. Just because there are programming languages with dynamic typing doesn't mean that explicit static typing is salt. Dynamic typing has performance cost, and static inferred typing has worse self documentation properties and slightly bigger compilation time cost since you can't process each function independently.

On the other hand reinterpret_cast<Foo*>(expr) doesn't provide to compiler any extra information that couldn't be conveyed with simpler less verbose syntax like R(Foo*)expr or (expr as Foo*). Same with unsafe{} blocks, compiler already know which operations are unsafe.

What I can't stand about Rust is that the language developers think they know better than language users developing software. They stack on syntactic salt to make it more unpleasant to write the equivalent of correct C++ programs with aliased mutation or manual freeing, in situations where the idiomatic Rust ways are also unpleasant to write (Cell, RefCell, raw pointers), have runtime overhead (RefCell), are busywork to implement in working programs (restructuring your entire program around an ownership tree with only ephemeral stack-allocated cross-linking &mut, which is only sometimes possible without reducing performance or increasing memory use), or are easy, tempting, and undefined behavior in Rust but not C++ (casting *mut to &mut in an unsafe block in a safe function).

"Man tries to hammer in screw. Angry at hammer manufactures for not being screwdriver manufactures"

----

I'll just edit this comment to clarify: Rust does a lot of thing really well. Non-RC manual memory management for a tree/graph structure is absolutely not it.

As for the verbose 'unsafe' pointer/memory manipulations, i really don't see the issue. I've written my share and I think its fine to add a roadblock if you want to shoulder the ability to add segfaults and other issues into a codebase. Additionally, it usually helps that you decide to encapsulate it into the least number of unsafe functions, instead of 'doing it manually' all over a codebase.

Rust is intended to be a systems language capable of replacing C++ in its niche, and interfacing with existing C++ at a fairly coarse-grained level like Firefox's oxidation (though cxx is trying to enable rich interop passing richer types than C-ABI ones), so it's trying to be a better screwdriver more so than a hammer. So difficulty expressing C++ concepts is arguably a flaw, and difficulty implementing all software with the same CPU/memory overhead as C++ (which I'd argue is the case, though some would disagree) is definitely a flaw.

It's like creating a new screwdriver bit or handle, trying to convert the world to it, then attracting a legion of followers arguing that manufacturing flat-head screwdrivers should expose you to legal liability for anyone who slips it out of the socket and injures themselves (ignoring that flat-head screws existed and will continue to exist).

“Left-handed person tries to put screw in with screwdriver shaped for right-handed holding. Right-handed people are surprised when left-handed person decides screwdriver isn’t for them and uses something easier instead.”

We saw this for years with C++ and the new-style casts. The principle of making casting behaviours more specific and clarifying the risk of using each of them was fine. In practice, if someone asks programmers to start writing verbose, syntactically awkward stuff like reinterpret_cast<X*>(p) instead of (X*)p and either will work, obviously in the real world many will choose the latter. Empirically, the in-your-face syntax turned out to be a deterrent to adopting the better tools the language offered and so devalued those tools for everyone.

This entire conversation is assuming that `unsafe` in Rust is designed to be syntactic salt to discourage unsafe code, but this is false. The `unsafe` keyword exists to make it easier to understand, review, and audit where memory-safety invariants might ultimately be violated in a zillion-line program, so that instead of needing to carefully consider a zillion lines you only need to consider a tiny fraction of those. It's not there to make programmers' lives harder, it's intended to make programmers' lives easier.

This is not an accurate characterization of the Rust language developers. Neither of these features were designed as "syntactic salt!" They are compromises, made on a time budget to achieve goals which were higher priority for the project- but the door is still open to improve them. This is a far cry from "knowing better than language users," which implies that they could have simply left that syntax out while still achieving their goals. (Or worse, that their goal was specifically to annoy people...?)

For instance, they are not satisfied with the current raw pointer syntax either, as it interacts poorly with lvalue/place syntax in ways that make unsafe code harder to audit. There are regular proposals for how to improve things like `(*ptr).field` or the use of raw pointers as method receivers.

The situation with interior mutability is similar: compile-time memory safety inherently requires some limitations on programming style, but I regularly see proposals for how to improve "field projection" syntax.

> undefined behavior in Rust but not C++ (casting *mut to &mut in an unsafe block in a safe function).

The question of "syntactic salt" aside, this is simply false.

Casting mut to &mut in a safe function is unsound, and UB if the result is used alternatingly with an earlier &mut to the save object (I've seen this in a library I tried using). In C++ casting a to a & is sound, and casting a * into a __restrict & might be unsound but restrict is so rarely used that it doesn't matter, whereas safe Rust nearly requires using &mut for mutating through a pointer.

As for "compile-time memory safety inherently requires some limitations on programming style", I find compile-time lifetime safety to be a tradeoff, and often a net negative in not only performance but ease of programming for low-level code maintained by the same individual preserving a "theory" of the code over time (whereas I don't find compile-time bounds checking or thread safety to be a net negative to programmer experience nearly as often). And when I see people on crusades to stop programmers from writing code in unsafe languages (taking away programmers') ability to opt out of this tradeoff, I will stop at nothing to oppose these people.

> Casting mut to &mut in a safe function is unsound, and UB if the result is used alternatingly with an earlier &mut to the save object (I've seen this in a library I tried using). In C++ casting a to a & is sound, and casting a * into a __restrict & might be unsound but restrict is so rarely used that it doesn't matter, whereas safe Rust nearly requires using &mut for mutating through a pointer.

I'm not 100% sure I know what you're trying to say here due to the autoformatting doing a number on your pointers, but if I'm correct, you're unhappy that being able to cast a raw pointer to a reference in Rust is unsafe when casting a pointer to a reference is sound in C++. What do you think should happen if the pointer is null? I don't think this is sound in C++ either; this simple example[1] segfaults for me, and I imagine that it's undefined behavior and that even a segfault isn't guaranteed. In Rust, you can call this method[2] to convert a raw mutable pointer to an Option of a mutable reference, which will contain None if the raw pointer is null. If you absolutely don't want to check that it's null, you can always unwrap that. Yes, `unsafe { foo.as_mut().unwrap() }` is more verbose than `foo as &mut _`, but it doesn't really strike me as controversial that the syntax is being optimized for other uses.

> As for "compile-time memory safety inherently requires some limitations on programming style", I find compile-time lifetime safety to be a tradeoff, and often a net negative in not only performance but ease of programming for low-level code maintained by the same individual preserving a "theory" of the code over time (whereas I don't find compile-time bounds checking or thread safety to be a net negative to programmer experience nearly as often).

I think that's a fair opinion to hold, even though I don't happen to agree with it personally.

> And when I see people on crusades to stop programmers from writing code in unsafe languages (taking away programmers') ability to opt out of this tradeoff, I will stop at nothing to oppose these people.

This is where you lose me. Developing a language with verbose for casting a possibly null pointer to a type that assumes it's not null is worth "stopping at nothing to oppose"? This sounds like you're the one going on a crusade to stop people from using languages you don't like. I don't really see why you'd assume that the people who develop Rust are the same ones who are evangelizing it in a way you don't like, but I guess that it doesn't matter if that's accurate or not if you're going to stop at nothing.

[1]: https://godbolt.org/z/fvfc8cGda [2]: https://doc.rust-lang.org/std/primitive.pointer.html#method....

Rust is a language with advances and flaws compared to C++ (and presumably C too). I think Rust made some bad decisions to the point I would avoid using it for certain classes of software (generally low-level code, or emulators with complex shared mutability by design). My ire is directed at people like pcwalton who argue that it's wrong to design non-watertight-safe languages like Zig at all for application development, and mjg59 who argue unsafe language creators should be held legally liable for users harmed by programs written in those languages.

> Casting *mut to &mut in a safe function is unsound, and UB if the result is used alternatingly with an earlier &mut to the save object

This is a very different statement than your first comment, and still wrong. Casting *mut to &mut is not, itself, unsound or UB- it is, for example, how `Mutex` and `RefCell` are implemented in the standard library!

Alternating &muts is of course UB, but that has nothing to do with raw pointers- that's just the definition of &mut, however you obtain one. Even if it were not strictly UB, it would still need to be forbidden, because thread safety and library code (like `Mutex`) relies on it.

> I find compile-time lifetime safety to be a tradeoff

Yes, this is exactly what I said in the first place- my further point was that the other side of the trade-off is not fixed, and the ergonomics of raw pointers and interior mutability can, have, and will continue to improve over time.

Or in other words, the Rust language developers are not "on a crusade to stop programmers from writing code in unsafe languages." Rather, they looked (and continue to look) for ways to expand the space of programs that can be written in safe languages. This is an important distinction, and you appear to be causing yourself a lot of grief ("stop at nothing"? really?) by conflating one with the other.

I'll reconsider Rust as a low level language once improved raw pointer syntax becomes a reality. And regarding the crusade, I wasn't targeting Rust's creators (I think safe programs are currently too limited and unsafe too difficult to call "replacing C++" a success, but I can pick alternative low-level language when needed), but:

> My ire is directed at people like pcwalton who argue that it's wrong to design non-watertight-safe languages like Zig at all for application development, and mjg59 who argue unsafe language creators should be held legally liable for users harmed by programs written in those languages.

> More important [...] the verbosity helps when reading code to know that something out of the ordinary is going on

This applies to JS as well with its strict equality check (triple equals). Bad practices within the NodeJS ecosystem, however, have led to circumstances where triple equals has been cargo culted as the "right" thing to do for any equality comparison. The consequences of this include code that is more verbose, is no more type safe (and often doesn't do the right thing for some inputs—whereas with double equals, in contrast, it would...), and that the appearance of triple equals is no longer a strong signal that there's something happening that's worth paying attention to.

Can you give some examples of inputs where === doesn't do the right thing?

Suppose you're working on a compiler. You want to add a feature flag or otherwise be able to produce a build that when run attaches rich diagnostics information to the emitted tokens to assist in debugging—let's say you're really interested in the source offset where a given token appeared, for example. Unless you've already really gone off the rails in other ways, then you can trivially do this just by making special mode compiler pass around String objects where your token processing routines expect a string—making sure you define a `position` property at the time of creation. This is possible because your input isn't overconstrained. It's an abstract data type.

Using triple equals, on the other hand, will screw this up. Your inputs are now overconstrained—they must be string primitives. In other words, you've invented an unnecessary requirement <https://www.teamten.com/lawrence/programming/dont-invent-unn...>.

Wow that's a well thought out and interesting example, thank you. I recently learned about `new String()` and wondered where people might use/get burned by that.

Glad you found it useful. I was worried it would come off as too esoteric/contrived. There are lots of other legitimate, substantive scenarios, but it's generally hard to give examples that have both the intended effect of really resonating with a wide audience and that can also be described succinctly. The tokenizer use case is something I struck upon a few months ago and remains the best thing that reasonably stands alone to work as an example that I've found so far.

I've heard it called "syntactic vinegar" instead.

I wonder if there's a term for syntactic useless stuff, like commas in Clojure quasiquoted lists.

I propose "syntactic konnyaku".

> Konnyaku is a rubbery, flavorless zero-calorie food made of yams that are high in fiber and added to various Japanese foods for its squishy texture.

Reply on news.ycombinator.com