4 ms·

I’d love to see a language that kept everything as familiar as possible and implement memory safety as “the hard bit”, instead of the Rust approach of cooking i

I’d love to see a language that kept everything as familiar as possible and implement memory safety as “the hard bit”, instead of the Rust approach of cooking in multiple different new sub languages and concepts.

brabel 2y ago
The author of the post is trying pretty much that with his language, Vale.
phicoh 2y ago
As a long time C programmer I like Rust because it combines two things from C that are important to me (low runtime overhead, no runtime system required) with a focus on writing correct programs. Memory safety is just one aspect where the compiler can help making sure a program is correct. The more the compiler helps with static analysis, the less we need to rely on creating tests for edge cases.
- zamalek 2y ago
  > Memory safety is just one aspect I feel as though not enough attention is given to how std is designed. For example: [u8], str, Path, and OsStr may be confusing at first, but when you understand why they are there any other approach feels icky. std guides you down a path of caring about things that really should matter (at least if you're only unwrapping provably safe values). Have you considered what happens if not-utf8 data winds up in an environment variable that you are writing to stdout? What if it contains malicious VT commands?
  - shiomiru 2y ago
    > Have you considered what happens if not-utf8 data winds up in an environment variable that you are writing to stdout? What if it contains malicious VT commands? Unless you're talking about terminal bugs in parsing invalid UTF-8 - and parsing invalid UTF-8 is easier than rendering valid UTF-8 - VT commands are UTF-8 compatible. You just need to embed an ASCII escape character.
    - adgjlsfhk1 2y ago
      yeah I think this is an area where rust (and python) just get it wrong. files, the Internet and input devices can all give you invalid Unicode. IMO it's better to have a primary string type that includes invalid Unicode since most algorithms will handle it correctly anyway, and the ones that won't can pretty clearly check and throw errors appropriately (especially since very few algorithms work correctly for all of Unicode in the first place)
      - dwattttt 2y ago
        There's a primary type that holds invalid utf8; it's [u8]. If you want a string from that, you try turn it into a string, and deal with the errors then. If an algorithm works for invalid Unicode, it should probably be an algorithm on bytes, not strings.
ramon156 2y ago
Tbf I would already consider a different language when it has al the nice syntax sugar and design choices of Rust. I like almost every choice they made, and I miss things like `if let Some` or unwrapping in other languages. It's just not the same
chrismorgan 2y ago
As an experienced Rust developer, I have absolutely no idea what you mean by this. Could you write a little more about what you have in mind, and even what you mean by sub-languages and concepts in Rust?
karmakurtisaani 2y ago
Isn't that just C/C++?
frou_dh 2y ago
"Familiar" is subjective so it's not really something to hang your hat on.
nicoburns 2y ago
Familiar to whom? I came from a JavaScript background, and Rust's syntax and "functional lite" style felt very familiar.
pornel 2y ago
Safety is not an extra feature a'la carte. These concepts are all inter-connected: Safety requires unions to be safe, so unions have to become tagged enums. To have tagged enums usable, you have to have pattern matching, otherwise you'd get something awkward like C++ std::variant. Borrow checking works only on borrowed values (as the name suggests), so you will need something else for long-lived/non-lexical storage. To avoid GC or automatic refcounting, you'll want moves with exclusive ownership. Exclusive ownership lets you find all the places where a value is used for the last time, and you will want to prevent double-free and uninitialized memory, which is a job for RAII and destructors. Static analysis of manual malloc/realloc and casting to/from void* is difficult, slow, and in many cases provably impossible, so you'll want to have safely implemented standard collections, and for these you'll want generics. Not all bounds checks can be eliminated, so you'll want to have iterators to implement typical patterns without redundant bounds checks. Iterators need closures to be ergonomic. …and so on. Every time you plug a safety hole, it needs a language feature to control it, and then it needs another language feature to make this control fast and ergonomic. If you start with "C but safe", and keep pulling that thread, nearly all of Rust will come out.
- AlotOfReading 2y ago
  I've experienced that frustration myself several times and tried to do "rust but simpler". I just recently failed attempt #4 at not reinventing rust but worse. Attempt #2 ended with Erlang but worse, which was a pleasant surprise.
- mpweiher 2y ago
  Hm...Smalltalk is also safe. So there are obviously different ways of addressing this.
  - pornel 2y ago
    Bash is also memory-safe. Almost every programming language is memory-safe, but Smalltalk and most high-level dynamically typed languages require a fat runtime, and have a much higher overhead than C or Rust. For languages that can be credible C and C++ competitors, the design space is much smaller.

brabel 2y ago

The author of the post is trying pretty much that with his language, Vale.

phicoh 2y ago

As a long time C programmer I like Rust because it combines two things from C that are important to me (low runtime overhead, no runtime system required) with a focus on writing correct programs. Memory safety is just one aspect where the compiler can help making sure a program is correct. The more the compiler helps with static analysis, the less we need to rely on creating tests for edge cases.

zamalek 2y ago
> Memory safety is just one aspect I feel as though not enough attention is given to how std is designed. For example: [u8], str, Path, and OsStr may be confusing at first, but when you understand why they are there any other approach feels icky. std guides you down a path of caring about things that really should matter (at least if you're only unwrapping provably safe values). Have you considered what happens if not-utf8 data winds up in an environment variable that you are writing to stdout? What if it contains malicious VT commands?
- shiomiru 2y ago
  > Have you considered what happens if not-utf8 data winds up in an environment variable that you are writing to stdout? What if it contains malicious VT commands? Unless you're talking about terminal bugs in parsing invalid UTF-8 - and parsing invalid UTF-8 is easier than rendering valid UTF-8 - VT commands are UTF-8 compatible. You just need to embed an ASCII escape character.
  - adgjlsfhk1 2y ago
    yeah I think this is an area where rust (and python) just get it wrong. files, the Internet and input devices can all give you invalid Unicode. IMO it's better to have a primary string type that includes invalid Unicode since most algorithms will handle it correctly anyway, and the ones that won't can pretty clearly check and throw errors appropriately (especially since very few algorithms work correctly for all of Unicode in the first place)
    - dwattttt 2y ago
      There's a primary type that holds invalid utf8; it's [u8]. If you want a string from that, you try turn it into a string, and deal with the errors then. If an algorithm works for invalid Unicode, it should probably be an algorithm on bytes, not strings.

ramon156 2y ago

Tbf I would already consider a different language when it has al the nice syntax sugar and design choices of Rust. I like almost every choice they made, and I miss things like `if let Some` or unwrapping in other languages. It's just not the same

chrismorgan 2y ago

As an experienced Rust developer, I have absolutely no idea what you mean by this. Could you write a little more about what you have in mind, and even what you mean by sub-languages and concepts in Rust?

karmakurtisaani 2y ago

Isn't that just C/C++?

frou_dh 2y ago

"Familiar" is subjective so it's not really something to hang your hat on.

nicoburns 2y ago

Familiar to whom? I came from a JavaScript background, and Rust's syntax and "functional lite" style felt very familiar.

pornel 2y ago

Safety is not an extra feature a'la carte. These concepts are all inter-connected: Safety requires unions to be safe, so unions have to become tagged enums. To have tagged enums usable, you have to have pattern matching, otherwise you'd get something awkward like C++ std::variant. Borrow checking works only on borrowed values (as the name suggests), so you will need something else for long-lived/non-lexical storage. To avoid GC or automatic refcounting, you'll want moves with exclusive ownership. Exclusive ownership lets you find all the places where a value is used for the last time, and you will want to prevent double-free and uninitialized memory, which is a job for RAII and destructors. Static analysis of manual malloc/realloc and casting to/from void* is difficult, slow, and in many cases provably impossible, so you'll want to have safely implemented standard collections, and for these you'll want generics. Not all bounds checks can be eliminated, so you'll want to have iterators to implement typical patterns without redundant bounds checks. Iterators need closures to be ergonomic. …and so on. Every time you plug a safety hole, it needs a language feature to control it, and then it needs another language feature to make this control fast and ergonomic. If you start with "C but safe", and keep pulling that thread, nearly all of Rust will come out.

AlotOfReading 2y ago
I've experienced that frustration myself several times and tried to do "rust but simpler". I just recently failed attempt #4 at not reinventing rust but worse. Attempt #2 ended with Erlang but worse, which was a pleasant surprise.
mpweiher 2y ago
Hm...Smalltalk is also safe. So there are obviously different ways of addressing this.
- pornel 2y ago
  Bash is also memory-safe. Almost every programming language is memory-safe, but Smalltalk and most high-level dynamically typed languages require a fat runtime, and have a much higher overhead than C or Rust. For languages that can be credible C and C++ competitors, the design space is much smaller.