4 ms·

"Is it possible to create a truly safe language without the dizzying complexity?" Yes! The good news is, they even already exist. There's even at least two va

by jerf 4y ago

"Is it possible to create a truly safe language without the dizzying complexity?" Yes! The good news is, they even already exist. There's even at least two variants of them: Pure immutable values (Haskell, Erlang) and languages that aren't pure functional but involve lots of little execution units that can't send mutable references between the units (Elixir, Pony) which when used even slightly properly makes unaccounted-for mutation a non-problem. Those are not intended as complete lists, either. I gather Clojure can be used to a large degree this way, for instance. Nor is this a full list of all the possible solutions, just the ones that leap to my mind. The bad news is, the complexity in Rust is still there for a reason. I see the earlier efforts as something like the same picture as Rust is trying to be, but blurred. Immutability and inability to mutate across threads at all both solve the safety problems, but with a bigger hammer and a blunter flattening of the problem space. Technically, Rust's greater complexity allows it to hug the true parameters of the safety problem space more closely. I suspect that tradeoff is fundamental and you can't have Rust's feature set without roughly equivalent complexity. Fortunately, not every language has to be Rust. Fortunately, Rust exists for those times when we really, really need it. There can't be one language to rule them all, and Rust isn't going to fill that nonexistent niche. That's OK. Rust only has to be the best Rust it can be, and those other languages can be the best languages they can be, and in the end that's just as good as it can get. (Also, while this isn't a solution to the safety problem, you can still get a lot of mileage by adopting solutions from those domains into languages that technically unsafe, but work fairly well if you program them with a collection of reasonably safe patterns. I work a lot in Go. It is not particularly safe, technically; safer than C but that's a low, low bar. But in practice I don't have a lot of safety problems with it because I spent years cutting my teeth on Erlang and Haskell and my designs are informed by that.)

resonious 4y ago
Aren't Haskell and Erlang both GC? I don't think anyone is touting Rust as newly immutable. The only differentiator (to my understanding) is Rust's safety without GC.
- mikepurvis 4y ago
  I don't know that that's really the whole story. I mean, C++ has smart pointers that do reference counting, same as Rust's do. But C++ can't provide most of the rest of guarantees that Rust can, like that you didn't hold a reference to that argument, or return a pointer to a local variable that's about to go out of scope, or that these threads aren't both touching that thing at the same time.
  - resonious 4y ago
    That's true, a lot of Rust's features do exist in C++. I guess the main difference is that Rust is safe by default and you have to go out of your way to be unsafe. C++ is basically unsafe by default. In C++, the standard syntax for allocating memory gives you a completely unchecked pointer that you can freely use from whatever thread you want.
  - Gibbon1 4y ago
    > or return a pointer to a local variable that's about to go out of scope I thought of that recently. I wonder about using escape analysis to detect that and simply don't release the stack frame until the reference goes out of scope.
    - mikepurvis 4y ago
      Static analysis/tracing absolutely can do a bunch of that kind of thing, particularly catching trivial cases. But I think it's still a pretty important upgrade when those things are being checked by the compiler, for free, with guarantees, as part of every build, rather than using some side-tool that may be proprietary, deliver oodles of false positives, and so on.
      - Gibbon1 4y ago
        What I mean is just fix that so it works. If you have split stacks the one for data doesn't have to track function call chains. The advantage of using analysis tools is you only pay for that once. Not with every compile. And the tools are smarter than Rust. You also don't have safe vs unsafe code like you do with Rust.
mikepurvis 4y ago
I wonder too if we might see a world where a lot of application and business-logic code in Rust gets written essentially in the style of Python or Ruby— lots of immutability and copying stuff around because perf doesn't matter at that layer. But then the heavy processing part of the application can call down into vetted crates which do take advantage of Rust's more sophisticated features. Am thinking here of the relationship between Python and Numpy/Pandas. Lots of companies use Numpy heavily but wouldn't dream of trying to hack on it or build such a thing themselves from scratch. Similar story with places which do things like ban writing their own template code, but permit the use of std container classes.
stormbrew 4y ago
I don't think it's really possible to seriously consider Haskell as somehow less "dizzyingly complex" than rust unless you're already a math postgrad. I like haskell, don't get me wrong, but it is not in any way simple to write or read or work with by comparison. And while rust has some heady concepts in its design, for the most part even advanced users don't actually need to understand most of them to use it (I think this is actually rust's biggest innovation). I do wish rust had borrowed syntactically more from haskell than C++, though.
- hither_shores 4y ago
  > I don't think it's really possible to seriously consider Haskell as somehow less "dizzyingly complex" than rust unless you're already a math postgrad. This seems clearly false to me. Haskell has a higher abstraction ceiling than Rust, but unless you want to contribute to a particularly heavyweight library (`lens` comes to mind) you can get by just fine without going anywhere near it. In practice, most code in both languages maxes out at or below the mathematical sophistication of an introductory algebra class.
- jerf 4y ago
  Haskell is not really that complicated. What it is is capable of hosting dizzying complexity on top of its relatively simple core, which it is capable of hosting precisely because the core is so simple. It is similar to Lisp in that regard. There's also rather a lot of spazzing out because some very simple concepts like "monad" in Haskell somehow managed to pick up a lot of very bad explanations and an aura of mystique they don't deserve. They're really only complicated if you go in assuming they must be, and that if you have a simple understanding it must be wrong because it has to be complicated. Rust fans may be familiar with the process; I see the borrow checking starting to pick up a bit of a similar mystique with the greater community, though I don't think it'll ever quite reach the same level of fever pitch as "monad" has. And I think there's even a similar process; start with Rust, print out Hello World, then immediately try to jump to writing a custom network application in Tokio and, yeah, the borrow checker is going to look pretty complicated since you're basically trying to swallow it all in one shot. The solution is, don't do that. I detect some of that mystique in your post. It is a complete myth that you need to be a math postgrad to understand Haskell. It is a complete myth that you must understand group theory to use Haskell. It has even been observed that knowing too much Haskell can make group theory a bit harder to learn, and knowing too much group theory can make Haskell a bit harder to learn, because Haskell has a very programming-language centric view of group theory that means that even though some terminology is shared, everything is just a bit askew from the other. You no more need to be a math postgrad to use Haskell than you do to use a structured programming language, which also used to be a weird math nerd thing. Now it's just how programming languages work.

by jerf 4y ago

resonious 4y ago

Aren't Haskell and Erlang both GC? I don't think anyone is touting Rust as newly immutable. The only differentiator (to my understanding) is Rust's safety without GC.

mikepurvis 4y ago
I don't know that that's really the whole story. I mean, C++ has smart pointers that do reference counting, same as Rust's do. But C++ can't provide most of the rest of guarantees that Rust can, like that you didn't hold a reference to that argument, or return a pointer to a local variable that's about to go out of scope, or that these threads aren't both touching that thing at the same time.
- resonious 4y ago
  That's true, a lot of Rust's features do exist in C++. I guess the main difference is that Rust is safe by default and you have to go out of your way to be unsafe. C++ is basically unsafe by default. In C++, the standard syntax for allocating memory gives you a completely unchecked pointer that you can freely use from whatever thread you want.
- Gibbon1 4y ago
  > or return a pointer to a local variable that's about to go out of scope I thought of that recently. I wonder about using escape analysis to detect that and simply don't release the stack frame until the reference goes out of scope.
  - mikepurvis 4y ago
    Static analysis/tracing absolutely can do a bunch of that kind of thing, particularly catching trivial cases. But I think it's still a pretty important upgrade when those things are being checked by the compiler, for free, with guarantees, as part of every build, rather than using some side-tool that may be proprietary, deliver oodles of false positives, and so on.
    - Gibbon1 4y ago
      What I mean is just fix that so it works. If you have split stacks the one for data doesn't have to track function call chains. The advantage of using analysis tools is you only pay for that once. Not with every compile. And the tools are smarter than Rust. You also don't have safe vs unsafe code like you do with Rust.

mikepurvis 4y ago

I wonder too if we might see a world where a lot of application and business-logic code in Rust gets written essentially in the style of Python or Ruby— lots of immutability and copying stuff around because perf doesn't matter at that layer. But then the heavy processing part of the application can call down into vetted crates which do take advantage of Rust's more sophisticated features. Am thinking here of the relationship between Python and Numpy/Pandas. Lots of companies use Numpy heavily but wouldn't dream of trying to hack on it or build such a thing themselves from scratch. Similar story with places which do things like ban writing their own template code, but permit the use of std container classes.

stormbrew 4y ago

I don't think it's really possible to seriously consider Haskell as somehow less "dizzyingly complex" than rust unless you're already a math postgrad. I like haskell, don't get me wrong, but it is not in any way simple to write or read or work with by comparison. And while rust has some heady concepts in its design, for the most part even advanced users don't actually need to understand most of them to use it (I think this is actually rust's biggest innovation). I do wish rust had borrowed syntactically more from haskell than C++, though.

hither_shores 4y ago
> I don't think it's really possible to seriously consider Haskell as somehow less "dizzyingly complex" than rust unless you're already a math postgrad. This seems clearly false to me. Haskell has a higher abstraction ceiling than Rust, but unless you want to contribute to a particularly heavyweight library (`lens` comes to mind) you can get by just fine without going anywhere near it. In practice, most code in both languages maxes out at or below the mathematical sophistication of an introductory algebra class.
jerf 4y ago
Haskell is not really that complicated. What it is is capable of hosting dizzying complexity on top of its relatively simple core, which it is capable of hosting precisely because the core is so simple. It is similar to Lisp in that regard. There's also rather a lot of spazzing out because some very simple concepts like "monad" in Haskell somehow managed to pick up a lot of very bad explanations and an aura of mystique they don't deserve. They're really only complicated if you go in assuming they must be, and that if you have a simple understanding it must be wrong because it has to be complicated. Rust fans may be familiar with the process; I see the borrow checking starting to pick up a bit of a similar mystique with the greater community, though I don't think it'll ever quite reach the same level of fever pitch as "monad" has. And I think there's even a similar process; start with Rust, print out Hello World, then immediately try to jump to writing a custom network application in Tokio and, yeah, the borrow checker is going to look pretty complicated since you're basically trying to swallow it all in one shot. The solution is, don't do that. I detect some of that mystique in your post. It is a complete myth that you need to be a math postgrad to understand Haskell. It is a complete myth that you must understand group theory to use Haskell. It has even been observed that knowing too much Haskell can make group theory a bit harder to learn, and knowing too much group theory can make Haskell a bit harder to learn, because Haskell has a very programming-language centric view of group theory that means that even though some terminology is shared, everything is just a bit askew from the other. You no more need to be a math postgrad to use Haskell than you do to use a structured programming language, which also used to be a weird math nerd thing. Now it's just how programming languages work.