First Impressions

[KieranP]

I've just finished porting my Conway's Game of Life implementation (GOL) to Inko. You can view the result here: https://github.com/KieranP/Game-Of-Life-Implementations/tree/master/inko

Here are my initial impressions after finishing. Feel free to take it with a grain of salt. All the best as you continue to develop the language.

• The language design reminds me of Rust in a lot of ways, minus the lifetimes and easier/less in your face borrowing/moving mechanic. Nice work.

• Documentation is sparse - for example, I couldn't find anything on the website about how to use Arrays, Maps, or Options. I had to dive into the source code to find out. Thankfully the std library is well documented and easily to follow. Would be helpful if this was published.

• Performance is lacking. Even with aggressive optimisations enabled, Inko sadly currently ranks as 2nd to last in my GOL rankings. The majority of the time appears to be in a method which makes a lot of calls to map.opt() and unwrapping the result. I use the same approach in other compiled language implementations, and they are about 20x-25x faster. So some room for improvement there. Feel free to use my implementation for profiling and optimising if you so wish.

• Inko is lacking some language features compared to other mainstreams, namely class static fields (e.g. let static @field = ...), class instance field default values (e.g. let pub @tick = 0), method default values (e.g. add_cell(alive: Bool = false)), and a clearer way to loop X times than what I'm currently doing:

let mut y = 0
while y < @height {
  let mut x = 0
  while x < @width {
    # Do something
    x += 1
  }
  y += 1
}

Perhaps something like:

loop(@height).each fn (y) {
  loop(@width).each fn (x) {
    # Do something
  }
}

• Expanded std library. The main one that came to mind while ding the GOL implementation was a form of iter.count, like below:

neighbours.iter.count fn (neighbour) {
  neighbour.alive
}

Anyway, thanks for reading. All the best and will keep an eye on future releases.

[yorickpeterse]

@KieranP Thanks for the feedback, this is really helpful 😃

Documentation is sparse - for example, I couldn't find anything on the website about how to use Arrays, Maps, or Options. I had to dive into the source code to find out. Thankfully the std library is well documented and easily to follow. Would be helpful if this was published.

This is a good point: it seems I completely forgot to cover Array and Map as part of the recent documentation overhaul. I'll add this to the documentation.

Performance is lacking. Even with aggressive optimisations enabled, Inko sadly currently ranks as 2nd to last in my GOL rankings. The majority of the time appears to be in a method which makes a lot of calls to map.opt() and unwrapping the result. I use the same approach in other compiled language implementations, and they are about 20x-25x faster. So some room for improvement there. Feel free to use my implementation for profiling and optimising if you so wish.

You're right that performance isn't great. I haven't spent a lot of time optimizing things yet and the LLVM IR we produce is horrible. I suspect that even with aggressive optimizations enabled, LLVM has a hard time improving things. In particular, functions aren't inlined at all: LLVM IIRC can't inline across separate modules, and we don't do any inlining on our own IR just yet. In addition, I suspect we're probably not providing enough metadata in the LLVM IR for LLVM to do a good job of optimizing things.

Fortunately, all of this can be solved (i.e. it's not some fundamental language problem), we just haven't gotten there yet 😄 The following issues are worth keeping an eye on:

• Figure out which LLVM optimisation passes are worth enabling #595
• Inlining of methods #343

Inko is lacking some language features compared to other mainstreams, namely class static fields (e.g. let static @field = ...), class instance field default values (e.g. let pub @tick = 0), method default values (e.g. add_cell(alive: Bool = false))

These features probably won't make it into the language. Static fields wouldn't work well as this results in global mutable state, which is exactly what we don't want in Inko. Default values for fields isn't terribly useful as you can simply use static/factory methods for that.

Default argument values is something we used to have a long time ago, but it was removed due to how this complicates code generation and type checking. This may be reintroduced at some point, but there are no concrete plans for it at this stage.

and a clearer way to loop X times than what I'm currently doing:

There are a few ways you can do this:

Using ranges (mostly useful if you want to e.g. map values):

y.until(@height).iter.each fn (v) { ... }

Using Int.times:

@height.times fn (h) {
  @width.times fn (w) {
    ...
  }
}

Expanded std library. The main one that came to mind while ding the GOL implementation was a form of iter.count, like below:

You can do this as follows:

neighbours.iter.select fn (n) { n.alive }.count

select returns an iterator yielding values for which the provided closure returns true, which you can then count using count.

I'll be working on #333 in the coming 2-3 months (currently working on #334, so not sure yet when I'll start), which should make it a lot easier to work with the standard library 😄

[KieranP]

@yorickpeterse Thanks for the information re: Int.times. This is exactly what I was hoping for. I'd recommend putting this in the Control Flow > Loops section of the current docs. On one of the loops though, I ran into an issue (`error(invalid-assign): variables captured by non-moving closures can't be assigned new values). I would have thought this code would work. Any idea what I'm missing here?

    let mut alive_neighbours = 0
    neighbours.size.times fn (n) {
      let neighbour = neighbours.get(n)
      if neighbour.alive {
        alive_neighbours += 1
      }
    }
    alive_neighbours

Regarding neighbours.iter.select fn (n) { n.alive }.count, I have that snippet commented out in my GOL implementation. But if I'm not mistaken, this would create a second array, increasing time and memory. Might be nice to implement a Iter.count method in such a way that a new array is not created.

Regarding class static fields, is it possible to add the restriction that such fields are always immutable? The use case I'm thinking of is making World.cached_directions a static and unchanging array of coordinates. You could think of it like a class constant, something locked in at compile time?

[yorickpeterse]

@KieranP

This is exactly what I was hoping for. I'd recommend putting this in the Control Flow > Loops section of the current docs

You're right, I'll add this 😄

I would have thought this code would work. Any idea what I'm missing here?

Closures capture by value instead of by reference. This means that when you assign a new value, it's only visible to the closure itself. If you use fn move instead you can assign a new value, but it won't be observed outside of the closure. In your case you probably want to use Iter.reduce, so something like this:

neighbours.iter.reduce(0) fn (acc, n) {
  acc + if n.alive { 1 } else { 0 }
}

However, in this case you're better off just using the count approach.

I'll adjust the documentation to discuss this more clearly.

Regarding neighbours.iter.select fn (n) { n.alive }.count, I have that snippet commented out in my GOL implementation. But if I'm not mistaken, this would create a second array, increasing time and memory. Might be nice to implement a Iter.count method in such a way that a new array is not created.

It doesn't create a new Array. Iter.select returns a new iterator that advances the iterator it's called upon, meaning it's lazy just like any other iterator. count just advances the iterator and increments a variable. In fact, the only method that creates an Array is the Iter.to_array method.

Regarding class static fields, is it possible to add the restriction that such fields are always immutable? The use case I'm thinking of is making World.cached_directions a static and unchanging array of coordinates. You could think of it like a class constant, something locked in at compile time?

Static fields isn't something I'll add to Inko. If the array values are known at compile-time, you can just use a constant instead, i.e:

let NUMBERS = [10, 20, 30]

If instead the data is calculated at runtime, I suggest just passing the data around as an argument or store it in a regular field where needed.

[KieranP]

@yorickpeterse Regarding closure captures, is there any way then to adjust a variable outside of the closure? I'm trying to simply this:

let mut rendering = ""
let mut y = 0
while y < @height {
  let mut x = 0
  while x < @width {
    let cell = cell_at(x, y)
    if cell.some? {
      rendering += cell.unwrap.to_char
    }
    x += 1
  }
  rendering += "\n"
  y += 1
}
rendering

to this:

let mut rendering = ""
@height.times fn (y) {
  @width.times fn (x) {
    let cell = cell_at(x, y)
    if cell.some? {
      rendering += cell.unwrap.to_char
    }
  }
  rendering += "\n"
}
rendering

but getting the error(invalid-assign): variables captured by non-moving closures can't be assigned new values error.

Any suggestions how something like this could be achieved, or not possible due to Inko's reference safety?

[yorickpeterse]

@KieranP You can use Iter.reduce as I suggested in https://github.com/orgs/inko-lang/discussions/700#discussioncomment-8633669, or you can capture mutable collections (e.g. Array or std.string.StringBuffer) and modify them in-place. In your particular example, modifying StringBuffer in-place is the easiest (and unlike String.+ doesn't allocate a new String for every concatenation):

import std.string.StringBuffer

let rendering = StringBuffer.new

@height.times fn (y) {
  @width.times fn (x) {
    rendering.push('...')
  }
}

rendering.into_string # => '...'

[yorickpeterse]

I ran a very quick profiling session using perf, resulting in output like this:

Overhead  Command       Shared Object         Symbol
  12.36%  proc 0        play                  [.] _IM_std.int.Int.+#
   5.05%  proc 0        play                  [.] _IM_std.int.Int.<<#
   4.18%  proc 0        play                  [.] _IM_std.int.Int.-#
   3.85%  proc 0        libc.so.6             [.] malloc
   3.47%  proc 0        play                  [.] _IM_std.int.Int.*#
   3.33%  proc 0        play                  [.] _IM_std.hash.siphash.SipHasher13.round#
   3.20%  proc 0        play                  [.] _IM_std.int.Int.>>>#
   3.18%  proc 0        play                  [.] _IM_std.array.bounds_check#
   3.17%  proc 0        play                  [.] _IM_std.int.Int.==#
   2.99%  proc 0        play                  [.] _IM_std.hash.siphash.SipHasher13.write#
   2.85%  proc 0        libc.so.6             [.] cfree
   2.78%  proc 0        play                  [.] _IM_std.crypto.math.rotate_left_u64#
   1.85%  proc 0        play                  [.] _IM_std.string.String.==#
   1.80%  proc 0        play                  [.] _IM_std.int.Int.>=#
   1.80%  proc 0        play                  [.] _IM_world.World.alive_neighbours_around#
   1.69%  proc 0        play                  [.] _IM_std.string.String.hash#o
   1.68%  proc 0        play                  [.] _IM_std.int.Int.format#
   1.60%  proc 0        play                  [.] _IM_std.map.Map.entries_index#so
   1.54%  proc 0        play                  [.] _IM_std.array.Array.get_unchecked#o
   1.53%  proc 0        play                  [.] _IM_std.int.Int.%#
   1.45%  proc 0        libc.so.6             [.] realloc
   1.41%  proc 0        play                  [.] _IM_std.int.Int.<#
   1.20%  proc 0        play                  [.] _IM_std.array.Array.get#r
   1.07%  proc 0        play                  [.] _IM_std.byte_array.ByteArray.reverse#
   1.02%  proc 0        play                  [.] _IM_world.World.cell_at#
   1.00%  proc 0        play                  [.] inko_string_concat
   0.94%  proc 0        play                  [.] _IM_std.hash.siphash.SipHasher13.finish#

I'm pretty sure what we're seeing here is just the cost of function calls that aren't inlined, and so once that's solved I'm sure this implementation will perform much better.