5 ms·

This looks enough like rust that I'm not sure why I'd pick it over rust. What would be some concrete programs that would be difficult or tedious to write in rus

This looks enough like rust that I'm not sure why I'd pick it over rust. What would be some concrete programs that would be difficult or tedious to write in rust and easy in inko? Could really use a section on "here's rust code you'd like to write but compiler won't let you" and how inko works.

alex_lav 3y ago
You’ll note lifetimes aren’t a thing here, which is enough for me to give it a shot.
- singingboyo 3y ago
  Apparently it's just moving that to runtime, which is kind of terrifying and misses the point. "If the owned value is dropped but references to it still exist, a panic is produced and the program is aborted; protecting you against use-after-free errors." [1] That "protection" seems pretty worthless to me, since a non-trivial number of the use-after-free bugs I've seen are triggered only in rare cases, which means you're still crashing in prod. Overall, Rust's lifetimes are sometimes hard, but generally only when memory safety is also hard. Inko's docs claim it makes it easier to implement self-referential data structures without unsafe/raw pointers, but to be honest the references here don't seem significantly safer than raw pointers. [1] https://docs.inko-lang.org/manual/latest/getting-started/memory-management/#references-and-borrowing https://docs.inko-lang.org/manual/latest/getting-started/mem...
  - alex_lav 3y ago
    So use Rust. I’m not understanding these complaints.
    - pzmarzly 3y ago
      How many times did you write `for<'a>` keyword or manually used `Pin<...>` type, or specified `where 'a: 'b`? I personally didn't need to reach for this "dark art" in at least last 2 years - thanks to Rust compiler developers making lifetime inference much better compared to how it's been few years ago. But there are still some warts around e.g. generic async functions, where you do sometimes need to think very hard about lifetimes and know plenty of tricks. Arguably those are situations where memory management is hard, but it's not something that e.g. TypeScript, C#, Swift or Scala would make you think about.
      - alex_lav 3y ago
        You seem to misunderstand the intent of my comment. The feedback (from Rust devs, at least) on this language seems to boil down to "But why isn't it Rust?", which also seems to be kind of a resounding sentiment around many different languages that Are Not Rust. Conversations around Zig and Go get derailed (by Rust devs) all the time. So my question is, if a language Is Not Rust, and ultimately your demand is to use Rust, why even bother complaining? Just use Rust. The rest of us don't want Rust, so languages in this space (this space being defined as "Statically typed, compiled languages that Are Not Rust"), can be interesting. Derailing to poke at all the ways a language isn't Rust is just a waste of everybody's time.
  - azakai 3y ago
    This sounds like very useful protection to me: yes, you can have crashes in prod, but those are unexploitable at least. That's a very big deal in some systems.
  - rizky05 3y ago
    [dead]
  - stefs 3y ago
    crashing in prod is still a hundred times better than silent data corruption and security issues from use-after-free.
YorickPeterse 3y ago
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 :-)
lawn 3y ago
From a quick glance, a "simpler" Rust with an Erlang like concurrency model seems like a very appealing language. It's also a sentiment I've seen repeated quite often.

alex_lav 3y ago

You’ll note lifetimes aren’t a thing here, which is enough for me to give it a shot.

singingboyo 3y ago
Apparently it's just moving that to runtime, which is kind of terrifying and misses the point. "If the owned value is dropped but references to it still exist, a panic is produced and the program is aborted; protecting you against use-after-free errors." [1] That "protection" seems pretty worthless to me, since a non-trivial number of the use-after-free bugs I've seen are triggered only in rare cases, which means you're still crashing in prod. Overall, Rust's lifetimes are sometimes hard, but generally only when memory safety is also hard. Inko's docs claim it makes it easier to implement self-referential data structures without unsafe/raw pointers, but to be honest the references here don't seem significantly safer than raw pointers. [1] https://docs.inko-lang.org/manual/latest/getting-started/memory-management/#references-and-borrowing https://docs.inko-lang.org/manual/latest/getting-started/mem...
- alex_lav 3y ago
  So use Rust. I’m not understanding these complaints.
  - pzmarzly 3y ago
    How many times did you write `for<'a>` keyword or manually used `Pin<...>` type, or specified `where 'a: 'b`? I personally didn't need to reach for this "dark art" in at least last 2 years - thanks to Rust compiler developers making lifetime inference much better compared to how it's been few years ago. But there are still some warts around e.g. generic async functions, where you do sometimes need to think very hard about lifetimes and know plenty of tricks. Arguably those are situations where memory management is hard, but it's not something that e.g. TypeScript, C#, Swift or Scala would make you think about.
    - alex_lav 3y ago
      You seem to misunderstand the intent of my comment. The feedback (from Rust devs, at least) on this language seems to boil down to "But why isn't it Rust?", which also seems to be kind of a resounding sentiment around many different languages that Are Not Rust. Conversations around Zig and Go get derailed (by Rust devs) all the time. So my question is, if a language Is Not Rust, and ultimately your demand is to use Rust, why even bother complaining? Just use Rust. The rest of us don't want Rust, so languages in this space (this space being defined as "Statically typed, compiled languages that Are Not Rust"), can be interesting. Derailing to poke at all the ways a language isn't Rust is just a waste of everybody's time.
- azakai 3y ago
  This sounds like very useful protection to me: yes, you can have crashes in prod, but those are unexploitable at least. That's a very big deal in some systems.
- rizky05 3y ago
  [dead]
- stefs 3y ago
  crashing in prod is still a hundred times better than silent data corruption and security issues from use-after-free.

YorickPeterse 3y ago

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 :-)

lawn 3y ago

From a quick glance, a "simpler" Rust with an Erlang like concurrency model seems like a very appealing language. It's also a sentiment I've seen repeated quite often.