4 ms·

Generally speaking: if you're looking for a non-systems language that gives you similar guarantees as Rust, but with a lower mental cost, and you can stomach th

Generally speaking: if you're looking for a non-systems language that gives you similar guarantees as Rust, but with a lower mental cost, and you can stomach the drawbacks of a young language, then Inko might be worth looking into. As for comparisons to actual Rust programs: I haven't done any side-by-side comparisons, mainly because I worry they may come across as a bit disingenuous, as you'd never pick examples that make your language look worse than whatever language you're comparing to.

Varriount 3y ago
I know this is a purely subjective opinion, but I feel that Inko looks a lot nicer than Rust, from a syntactic perspective. I could never get over how many symbols and keywords Rust has, not to mention how it requires semicolons (despite them being unnecessary in all but a few cases).
keyle 3y ago
This is a good selling point because my main issue with Rust is the mental overload that comes with handholding myself throughout the development process. I'm sure a lot of people just roll out of bed and naturally dance with the borrow checker like it's an old friend, but to me it's an hindrance. Maybe because I don't just only do Rust. I do plenty of other languages, or my brain is inferior, or both.
- cies 3y ago
  I feel that using Rust for low level stuff, all the mental overhead is worth it compared to using C: dance with the borrow checker, or get bitten by subtle bugs -- you choose :) Using Rust for non-pref-critical web apps is a nice exercise, and yields a super fast and efficient app. But in that case the mental overhead is not worth it compared to a language and developer experience like Kotlin.
- ay 3y ago
  FWIW, for most of my Rust use cases I found I can get away with a relatively simple heuristic: - if you pass it is a parameter, pass a read-only reference. - if you return a value as a result of a function call, clone as necessary and return as an owned object, try to never return a reference. - if the above two don’t fit, it’s thinking time; either the structure of the program can still afford for them with some refactor, or it’s genuinely incompatible. The former avoids excessive copying and limits the bugs due to attempting to modify a cloned object, the latter limits the lifetime managing gymnastics required. The third allows to keep the program logic relatively simple except in the cases where it’s really required. Hope that this is of some use :-)
  - duped 3y ago
    - if you pass it is a parameter, pass a read-only reference. Completely breaks with a lot of async code

Varriount 3y ago

I know this is a purely subjective opinion, but I feel that Inko looks a lot nicer than Rust, from a syntactic perspective. I could never get over how many symbols and keywords Rust has, not to mention how it requires semicolons (despite them being unnecessary in all but a few cases).

keyle 3y ago

This is a good selling point because my main issue with Rust is the mental overload that comes with handholding myself throughout the development process. I'm sure a lot of people just roll out of bed and naturally dance with the borrow checker like it's an old friend, but to me it's an hindrance. Maybe because I don't just only do Rust. I do plenty of other languages, or my brain is inferior, or both.

cies 3y ago
I feel that using Rust for low level stuff, all the mental overhead is worth it compared to using C: dance with the borrow checker, or get bitten by subtle bugs -- you choose :) Using Rust for non-pref-critical web apps is a nice exercise, and yields a super fast and efficient app. But in that case the mental overhead is not worth it compared to a language and developer experience like Kotlin.
ay 3y ago
FWIW, for most of my Rust use cases I found I can get away with a relatively simple heuristic: - if you pass it is a parameter, pass a read-only reference. - if you return a value as a result of a function call, clone as necessary and return as an owned object, try to never return a reference. - if the above two don’t fit, it’s thinking time; either the structure of the program can still afford for them with some refactor, or it’s genuinely incompatible. The former avoids excessive copying and limits the bugs due to attempting to modify a cloned object, the latter limits the lifetime managing gymnastics required. The third allows to keep the program logic relatively simple except in the cases where it’s really required. Hope that this is of some use :-)
- duped 3y ago
  - if you pass it is a parameter, pass a read-only reference. Completely breaks with a lot of async code