
Show HN: Inko – A safe and concurrent object-oriented programming language - YorickPeterse
https://inko-lang.org/
======
YorickPeterse
Author here. Both the language and website are still very much a work in
progress, so I'm happy to answer any questions here.

~~~
ainar-g
Looks pretty good. I see _someone_ has been reading "The Error Model" by Joe
Duffy, eh?

The example I would like to see is the one that shows the language's object-
orientedness and message-passing. Something like "public_send" or
"define_method". And maybe show runtime reflection capabilities, if Inko has
them.

Also, some questions you might want to answer on the main page/in examples:

* What platforms are supported?

* How big is the standard library?

* How do I encode/decode JSON/XML?

* What's the C FFI story?

* Are there benchmarks?

~~~
YorickPeterse

        > Looks pretty good. I see someone has been reading "The Error Model" by Joe
        > Duffy, eh?
    

Yes! It was a _huge_ inspiration. In fact, I wasn't sure what error handling
mechanism to use until I read the article.

    
    
        > Something like "public_send" or "define_method". And maybe show runtime
        > reflection capabilities, if Inko has them.
    

Good call, I'll note this down. Technically this is possible at the moment,
but it's not exactly user friendly.

Regarding your list of suggestions, I agree that having those would be nice,
and I'll see how I can best add those.

The state of the standard library can best be described as "very young". For
example, only recently did I manage to add enough building blocks to build a
testing standard library, and one of the next goals is to make sure everything
is tested before adding more.

Benchmarks aren't available yet because I think it's too early. FFI is
planned, but not yet supported.

~~~
kuwze
Just of curiosity, how does the error model of Midori relate an advanced
exception system, such as that found in Common Lisp?

~~~
YorickPeterse
I haven't used Common Lisp, so sadly I'm not sure if the two are related (or
how much).

------
transfire
Well it looks like somone finally got all the pieces right for a true OOP as
originally envisioned. Look forward to seeing it mature.

Note I could not find any docs.

~~~
YorickPeterse

        > Note I could not find any docs.
    

Maybe I should rephrase the Documentation page ([https://inko-
lang.org/documentation/](https://inko-lang.org/documentation/)) a bit to make
the link to the manual stand out more. The manual can be found here:
[https://inko-lang.org/manual/](https://inko-lang.org/manual/), all the
chapters can be found in the sidebar.

Note that if you are on a mobile device, you need to tap the "Toggle sidebar"
link at the top to display it.

------
eridius
What's the intended niche for this language? What types of programs do you
expect to be written in it?

~~~
YorickPeterse
I see it as a competitor to languages such as Python, Ruby, and Node.js,
specifically for writing web services. Eventually it would be a competitor to
Erlang/Elixir, but there is a lot of work (and especially testing and tuning)
to do before we get to that point, as BEAM/OTP is a pretty solid platform.

~~~
Ceezy
I think you should really be more focus because ruby and Erlang have very
little in common. Go is more for low level programming, Erlang not really,
Ruby, is more about expression. NodeJS can t do multithreading... Do you have
a problem that your laguage can solve really better than others. Or are you
still figuring out?

~~~
YorickPeterse
Ruby and Erlang/Elixir have more in common than one might think, especially
with frameworks such as Phoenix gaining more popularity.

I don't really see Inko as a direct competitor to Go, as Go's compiled nature
makes it quite different in use cases. Maybe when we have a JIT and an easy
way of distributing the VM + code, Inko could be a competitor to Go.

    
    
        >  Do you have a problem that your laguage can solve really better than others.
        > Or are you still figuring out?
    

Ignoring that Inko is still a very new language, there are already a couple of
benefits compared to Ruby such as: no need to pause everything during garbage
collection, easier to write concurrent programs, preemptive multitasking
(using more than one OS thread under the hoods, unlike both Ruby and Node),
more straightforward syntax (at least I think so), etc.

~~~
jashmatthews
Great work! I've started building a YARV compatible VM in Rust so it's always
great to see more examples of VMs and GC in Rust.

JRuby actually already has concurrent GC and no GIL.

------
jakecodes
Congrats Yorick! Super impressive! The site looks great! I'm trying it out and
so far its fantastic!

------
soylentgraham
Am I the only person who thinks divbyzero shouldn't take down a whole process?

And along those lines, how would you envision handling processes that panic, I
presume they don't send out Hail Mary messages to sibling processes? Does one
process take down them all with the intent of restarting the lot (with an
external watchdog?)

~~~
YorickPeterse
A panic will take down the entire system, and print a stacktrace for the
process that triggered the panic. I think this is a fundamental requirement,
as it dramatically cuts back the amount of exceptions you have to handle.

Runtime exceptions can't bubble up implicitly, and they can't be thrown at the
top-level. This prevents an exception 15 call stacks deep taking down the
entire system unexpectedly.

I do agree that zero division errors are a bit of an odd case to deal with, as
it's not unlikely for them to happen during runtime. Having said that, in the
past 10 years of coding I have never seen code that handled zero division
exceptions and didn't just straight up ignore them (something I don't want to
promote).

I believe Pony returns 0 for zero division errors. As crazy as this may be, I
do somewhat understand their choice. I think integer divisions would be easier
if there was something like NaN but for integers.

    
    
        > And along those lines, how would you envision handling processes that panic
    

Several years into the future, I envision there is a way to somehow act upon
them (e.g. logging them in Sentry or a similar service), but the system would
still shut down after this has been completed. I however will not add a
mechanism that allows you to just swallow a panic.

~~~
cphoover
So even if a panic happens in a subprocess the parent is killed? Why not allow
the parent to handle restarting of the child? Maybe I misunderstand.

~~~
YorickPeterse
Panics are not meant to be retried, as they are used exclusively for handling
bugs. Examples include: division by zero, sending a message to an object that
doesn't support it (if you manage to bypass the compiler), etc. Whenever these
occur, your program is broken. Restarting a process in that case won't change
anything, as it will run into the same problem again and again.

Expected errors such as network timeouts will use exceptions, and these have
to be explicitly handled. For example, if you try to open a file that you
don't have access to, an exception is raised.

~~~
cphoover
So these are errors that should have been caught by the compiler but were not?

I'm just thinking generally for production code you have a process supervisor
daemon automatically restart when there are fatal errors (out-of memory errors
for example). But in languages like erlang that support processes, one of the
advantages is that you can support this mechanism through the process model.
If I hit a divide by zero error in an edge-case branch of code, I will still
want my process restarted no?

~~~
YorickPeterse

        > So these are errors that should have been caught by the compiler but were not?
    

Some of them yes, others no. For example, the compiler can't statically
guarantee that there are no divisions by zero.

    
    
        > If I hit a divide by zero error in an edge-case branch of code, I will still want my process restarted no?
    

Sure, and so Inko may at some point have a system for running "clean up" code
of sorts, to report the error, etc. Actually restarting of things is something
I prefer to have done by a system daemon, as there is no guarantee a program
can continue after a panic (e.g. memory might be corrupted based on the nature
of the panic).

