4 ms·

Perhaps you'd be interested in Inko (https://inko-lang.org/ https://inko-lang.org/). It's obviously not there yet in terms of tooling and what not, but it might

Perhaps you'd be interested in Inko (https://inko-lang.org/ https://inko-lang.org/). It's obviously not there yet in terms of tooling and what not, but it might scratch an itch for those looking for something a bit like Rust, but easier to use. Disclaimer: I'm the author of said language :)

justinpombrio 3y ago
Lots of languages are aiming for "like Rust, but easier to use" -- I think I could name half a dozen. It's a laudable goal! I'm curious how references in your language work. I see the very small example, but it doesn't explain much. Some questions in that regard: Is `&T` a type? Can you store it in a structure, or return it? Can you have a reference to a reference? If you can have a function `f(&T, &T) -> &T`, how do you distinguish whether the reference it returns lives as long as the first or second argument? If references can't be stored in structs, how do you do non-owned iterators, or string slices?
- YorickPeterse 3y ago
  If you scroll past the code examples, there are a few more details, though for more you'll need to look at the documentation (specifically https://docs.inko-lang.org/manual/main/getting-started/memory-management/ https://docs.inko-lang.org/manual/main/getting-started/memor...). > Is `&T` a type? Inko's syntax for references is `ref T` for immutable references/borrows, and `mut T` for mutable ones. Unlike Rust, you can't implement methods/traits _only_ for references, instead you can only implement them for the underlying "base" type. So `impl ToString for String { ... }` is valid, but `impl ToString for ref String { ... }` isn't. > Can you store it in a structure, or return it? Yes. > Can you have a reference to a reference? No, `ref ref T` is "collapsed" into just `ref T`, and the language has no notion of pointers and pointer-pointers. > If you can have a function `f(&T, &T) -> &T`, how do you distinguish whether the reference it returns lives as long as the first or second argument Inko doesn't have a borrow checker, so it doesn't. Instead it relies on runtime reference counting to prevent dropping of values that still have references to them. Over time I hope to implement more compile-time analysis to reduce this cost as much as possible, but borrow checking/lifetime analysis like Rust isn't something Inko will have. Or to put it differently, I want the compiler to catch say 80-90% of the obvious "this ref outlives its pointee" errors without complicated borrow checkers. For the remaining 10-20% the runtime check should suffice.

justinpombrio 3y ago

Lots of languages are aiming for "like Rust, but easier to use" -- I think I could name half a dozen. It's a laudable goal! I'm curious how references in your language work. I see the very small example, but it doesn't explain much. Some questions in that regard: Is `&T` a type? Can you store it in a structure, or return it? Can you have a reference to a reference? If you can have a function `f(&T, &T) -> &T`, how do you distinguish whether the reference it returns lives as long as the first or second argument? If references can't be stored in structs, how do you do non-owned iterators, or string slices?

YorickPeterse 3y ago
If you scroll past the code examples, there are a few more details, though for more you'll need to look at the documentation (specifically https://docs.inko-lang.org/manual/main/getting-started/memory-management/ https://docs.inko-lang.org/manual/main/getting-started/memor...). > Is `&T` a type? Inko's syntax for references is `ref T` for immutable references/borrows, and `mut T` for mutable ones. Unlike Rust, you can't implement methods/traits _only_ for references, instead you can only implement them for the underlying "base" type. So `impl ToString for String { ... }` is valid, but `impl ToString for ref String { ... }` isn't. > Can you store it in a structure, or return it? Yes. > Can you have a reference to a reference? No, `ref ref T` is "collapsed" into just `ref T`, and the language has no notion of pointers and pointer-pointers. > If you can have a function `f(&T, &T) -> &T`, how do you distinguish whether the reference it returns lives as long as the first or second argument Inko doesn't have a borrow checker, so it doesn't. Instead it relies on runtime reference counting to prevent dropping of values that still have references to them. Over time I hope to implement more compile-time analysis to reduce this cost as much as possible, but borrow checking/lifetime analysis like Rust isn't something Inko will have. Or to put it differently, I want the compiler to catch say 80-90% of the obvious "this ref outlives its pointee" errors without complicated borrow checkers. For the remaining 10-20% the runtime check should suffice.