5 ms·

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 8y ago
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 8y ago
  > 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 8y ago
    Just of curiosity, how does the error model of Midori relate an advanced exception system, such as that found in Common Lisp?
    - YorickPeterse 8y ago
      I haven't used Common Lisp, so sadly I'm not sure if the two are related (or how much).
- cpeterso 8y ago
  For those who haven't heard of Joe Duffy's error model post (like me): http://joeduffyblog.com/2016/02/07/the-error-model/ http://joeduffyblog.com/2016/02/07/the-error-model/
v0ldem0rt 8y ago
Couple of questions: - What is your plan on package management? - With concurrent languages I always see a great potential of building something that is better than Go lang and not backed by Google. For that to happen you need native Async IO support. Do you plan to make it part of core? - Do you plan to support something like green-threads, coroutines, or go routines? Take my opinion as a biased web developer who is looking for a better performing compiled language than Node.js or Go lang.
- YorickPeterse 8y ago
  > What is your plan on package management? There is no fixed plan yet. My idea is to take an approach similar to CPAN: the registry (where you manage your account, packages, etc) and mirror (where you download the packages from) are two separate systems. This makes it easier to set up your own mirror. The mirror would just be a static file server of some kind (e.g. an S3 bucket). Security wise I was thinking of using TUF (https://theupdateframework.github.io/ https://theupdateframework.github.io/), though I have yet to actually sit down and read through it. > For that to happen you need native Async IO support. Do you plan to make it part of core? In Inko, similar to Erlang and Elixir, you don't really need async IO. This is because IO operations are offloaded to a separate thread pool. Inko may one day use async IO operations for this under the hood, though it certainly wouldn't be exposed directly to the language. In practise this means that instead of this: file.open('foo/bar.txt', function(handle) { handle.read(function(data) { ... } } You just do this: import std::fs::file let handle = try! file.read_only('foo/bar.txt') let data = try! handle.read "try!" here just means "try this operation, panic (= terminate) if it fails". In the above example, `read_only` opens a file in read-only mode, and `read` reads from it. Both are blocking operations, but both run on a separate thread pool. > Do you plan to support something like green-threads, coroutines, or go routines? This is built-in using the `std::process` module, one of the core foundations of Inko. If you're interested, you can read more about this here: https://inko-lang.org/manual/getting-started/concurrent-programming/ https://inko-lang.org/manual/getting-started/concurrent-prog...
  - stephen82 8y ago
Zalastax 8y ago
At a quick glance it seems like you're adopting the Active Objects model, is that correct? What are your thoughts on protocol safety? Methods being static mean that we can't guarantee protocol adherence, but perhaps that's overkill? There's a lot of interesting work going on in this field so to save you some research I suggest looking through at least the related works section of my thesis (see profile).
- YorickPeterse 8y ago
  Not exactly. Inko doesn't have an RPC mechanism built in, at least not like languages such as Pony. When you send a message to a process you just send it some arbitrary object (a string, array of integers, etc), and it's up to the receiving process to act upon it in some way. When you see code such as `process.send`, that means we're sending the "send" message to the "process" module, which ends up calling a corresponding method. This method then sends the actual message to a process.
  - Zalastax 8y ago
    I don't quite get how messages and method calls interact. Could the process intercept the method call by explicitly receiving or somehow influence the process module to do something else? Channels are a great idea! What capabilities (send on channel/receive on channel) can you forward to other processes? As Cloud Haskell explain, in distributed systems we must not allow send on channel to be forwarded. Regarding channels, both linear channels and mailbox types for unordered interactions are interesting ideas worth looking into. Great project!
    - YorickPeterse 8y ago
      > I don't quite get how messages and method calls interact. The term "message passing" is a bit confusing in this case, because it applies to both objects and actors, but both use a different approach. When you send a message to a regular object, usually a method with the same name is called. For example, when using `process.send` the "send" method in the "process" module is called. This however can change, as objects can implement the method "unknown_message" to handle messages for which no method is explicitly defined. In case of processes, sending a message is just that: you send a message, this gets put into a special queue, and then it's up to the receiving process to do something with it (whatever that might be). If you want to implement some kind of RPC system you'll need to see what kind of message you have, then dispatch accordingly. Inko's test suite does this using polymorphing: every message the test runner receives implements the "Command" trait, which defines a "run" method. The test runner then simply sends "run" to these command objects, letting them figure things out from there. > Channels are a great idea! What capabilities (send on channel/receive on > channel) can you forward to other processes? As Cloud Haskell explain, in > distributed systems we must not allow send on channel to be forwarded. I'm not sure if I fully understand this question. A channel in Inko consists out of two objects: a Sender and a Receiver. The Sender just wraps the PID of the receiving process, the Receiver is just used for storing the type of the message at compile time, and providing some methods. As to what you can send: everything that is compatible with the type of the channel. For example: import std::process let sender = process.channel!(Integer) lambda (receiver) { receiver.receive } sender.send('foo') This will fail, because our channel only allows `Integer` values, whereas "foo" is of type `String`. > Regarding channels, both linear channels and mailbox types for unordered > interactions are interesting ideas worth looking into. It is worth mentioning that despite the name "channel" being used for the method, it's not an actual channel data structure (e.g. like in Go). The messages are still stored in the mailbox of the receiver, just like when using `process.send`. Instead, the Sender/Receiver API is just a simple trick that allows the compiler to know what types of messages are being sent and received. I called this "channel", because after several hours of thinking I still couldn't come up with a better name.
devxpy 8y ago
> data race conditions impossible. Are you sure? Using message passing doesn't magically make stuff immune to races. You Still have to think about atomicity. Here is an excerpt from the documentation on my multiprocessing library, zproc. http://zproc.readthedocs.io/en/latest/user/atomicity.html http://zproc.readthedocs.io/en/latest/user/atomicity.html
- jaytaylor 8y ago
  zproc looks like am interesting approach to concurrency in python. For anyone else curious about it, here is the github project: https://github.com/pycampers/zproc https://github.com/pycampers/zproc
  - devxpy 8y ago
    Honestly though, it Just a really fancy wrapper over zmq. I just gave everything I learned from the zmq guide a pythonic interface. :)
- YorickPeterse 8y ago
  > Are you sure? Using message passing doesn't magically make stuff immune to races. > You Still have to think about atomicity Sure, _just_ using message passing doesn't do much. But Inko doesn't have shared memory (well apart from a permanent heap, but that's a different story and it has a very specific purpose). Perhaps I phrased things the wrong way, but the idea is that because there's no shared memory, you can't have data races due to concurrent modifications.
  - devxpy 8y ago
    Happens with me too. I sometimes don't realize how my words come out. Anyway, is there any reason as to why one would not use more mature languages like erlang and recently, dart? They also have the concept of isolates, that can't share memory. Apart from the written in rust part which is really cool.
    - 8y ago
ModernMech 8y ago
Why did you decide to license under MPL? Just curious as I haven't seen many projects licensed this way. Most projects go MIT or Apache2.
- YorickPeterse 8y ago
  Details on this can be found at https://inko-lang.org/faq/#header-why-does-inko-use-the-mpl-20 https://inko-lang.org/faq/#header-why-does-inko-use-the-mpl-.... The summary is: it protects the project better than the MIT license does. As far as I know the only difference with Apache 2 is that MPL 2.0 requires that modifications are licensed under the same license.

ainar-g 8y ago

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 8y ago
> 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 8y ago
  Just of curiosity, how does the error model of Midori relate an advanced exception system, such as that found in Common Lisp?
  - YorickPeterse 8y ago
    I haven't used Common Lisp, so sadly I'm not sure if the two are related (or how much).
cpeterso 8y ago
For those who haven't heard of Joe Duffy's error model post (like me): http://joeduffyblog.com/2016/02/07/the-error-model/ http://joeduffyblog.com/2016/02/07/the-error-model/

v0ldem0rt 8y ago

Couple of questions: - What is your plan on package management? - With concurrent languages I always see a great potential of building something that is better than Go lang and not backed by Google. For that to happen you need native Async IO support. Do you plan to make it part of core? - Do you plan to support something like green-threads, coroutines, or go routines? Take my opinion as a biased web developer who is looking for a better performing compiled language than Node.js or Go lang.

YorickPeterse 8y ago
> What is your plan on package management? There is no fixed plan yet. My idea is to take an approach similar to CPAN: the registry (where you manage your account, packages, etc) and mirror (where you download the packages from) are two separate systems. This makes it easier to set up your own mirror. The mirror would just be a static file server of some kind (e.g. an S3 bucket). Security wise I was thinking of using TUF (https://theupdateframework.github.io/ https://theupdateframework.github.io/), though I have yet to actually sit down and read through it. > For that to happen you need native Async IO support. Do you plan to make it part of core? In Inko, similar to Erlang and Elixir, you don't really need async IO. This is because IO operations are offloaded to a separate thread pool. Inko may one day use async IO operations for this under the hood, though it certainly wouldn't be exposed directly to the language. In practise this means that instead of this: file.open('foo/bar.txt', function(handle) { handle.read(function(data) { ... } } You just do this: import std::fs::file let handle = try! file.read_only('foo/bar.txt') let data = try! handle.read "try!" here just means "try this operation, panic (= terminate) if it fails". In the above example, `read_only` opens a file in read-only mode, and `read` reads from it. Both are blocking operations, but both run on a separate thread pool. > Do you plan to support something like green-threads, coroutines, or go routines? This is built-in using the `std::process` module, one of the core foundations of Inko. If you're interested, you can read more about this here: https://inko-lang.org/manual/getting-started/concurrent-programming/ https://inko-lang.org/manual/getting-started/concurrent-prog...
- stephen82 8y ago

Zalastax 8y ago

At a quick glance it seems like you're adopting the Active Objects model, is that correct? What are your thoughts on protocol safety? Methods being static mean that we can't guarantee protocol adherence, but perhaps that's overkill? There's a lot of interesting work going on in this field so to save you some research I suggest looking through at least the related works section of my thesis (see profile).

YorickPeterse 8y ago
Not exactly. Inko doesn't have an RPC mechanism built in, at least not like languages such as Pony. When you send a message to a process you just send it some arbitrary object (a string, array of integers, etc), and it's up to the receiving process to act upon it in some way. When you see code such as `process.send`, that means we're sending the "send" message to the "process" module, which ends up calling a corresponding method. This method then sends the actual message to a process.
- Zalastax 8y ago
  I don't quite get how messages and method calls interact. Could the process intercept the method call by explicitly receiving or somehow influence the process module to do something else? Channels are a great idea! What capabilities (send on channel/receive on channel) can you forward to other processes? As Cloud Haskell explain, in distributed systems we must not allow send on channel to be forwarded. Regarding channels, both linear channels and mailbox types for unordered interactions are interesting ideas worth looking into. Great project!
  - YorickPeterse 8y ago
    > I don't quite get how messages and method calls interact. The term "message passing" is a bit confusing in this case, because it applies to both objects and actors, but both use a different approach. When you send a message to a regular object, usually a method with the same name is called. For example, when using `process.send` the "send" method in the "process" module is called. This however can change, as objects can implement the method "unknown_message" to handle messages for which no method is explicitly defined. In case of processes, sending a message is just that: you send a message, this gets put into a special queue, and then it's up to the receiving process to do something with it (whatever that might be). If you want to implement some kind of RPC system you'll need to see what kind of message you have, then dispatch accordingly. Inko's test suite does this using polymorphing: every message the test runner receives implements the "Command" trait, which defines a "run" method. The test runner then simply sends "run" to these command objects, letting them figure things out from there. > Channels are a great idea! What capabilities (send on channel/receive on > channel) can you forward to other processes? As Cloud Haskell explain, in > distributed systems we must not allow send on channel to be forwarded. I'm not sure if I fully understand this question. A channel in Inko consists out of two objects: a Sender and a Receiver. The Sender just wraps the PID of the receiving process, the Receiver is just used for storing the type of the message at compile time, and providing some methods. As to what you can send: everything that is compatible with the type of the channel. For example: import std::process let sender = process.channel!(Integer) lambda (receiver) { receiver.receive } sender.send('foo') This will fail, because our channel only allows `Integer` values, whereas "foo" is of type `String`. > Regarding channels, both linear channels and mailbox types for unordered > interactions are interesting ideas worth looking into. It is worth mentioning that despite the name "channel" being used for the method, it's not an actual channel data structure (e.g. like in Go). The messages are still stored in the mailbox of the receiver, just like when using `process.send`. Instead, the Sender/Receiver API is just a simple trick that allows the compiler to know what types of messages are being sent and received. I called this "channel", because after several hours of thinking I still couldn't come up with a better name.

devxpy 8y ago

> data race conditions impossible. Are you sure? Using message passing doesn't magically make stuff immune to races. You Still have to think about atomicity. Here is an excerpt from the documentation on my multiprocessing library, zproc. http://zproc.readthedocs.io/en/latest/user/atomicity.html http://zproc.readthedocs.io/en/latest/user/atomicity.html

jaytaylor 8y ago
zproc looks like am interesting approach to concurrency in python. For anyone else curious about it, here is the github project: https://github.com/pycampers/zproc https://github.com/pycampers/zproc
- devxpy 8y ago
  Honestly though, it Just a really fancy wrapper over zmq. I just gave everything I learned from the zmq guide a pythonic interface. :)
YorickPeterse 8y ago
> Are you sure? Using message passing doesn't magically make stuff immune to races. > You Still have to think about atomicity Sure, _just_ using message passing doesn't do much. But Inko doesn't have shared memory (well apart from a permanent heap, but that's a different story and it has a very specific purpose). Perhaps I phrased things the wrong way, but the idea is that because there's no shared memory, you can't have data races due to concurrent modifications.
- devxpy 8y ago
  Happens with me too. I sometimes don't realize how my words come out. Anyway, is there any reason as to why one would not use more mature languages like erlang and recently, dart? They also have the concept of isolates, that can't share memory. Apart from the written in rust part which is really cool.
  - 8y ago

ModernMech 8y ago

Why did you decide to license under MPL? Just curious as I haven't seen many projects licensed this way. Most projects go MIT or Apache2.

YorickPeterse 8y ago
Details on this can be found at https://inko-lang.org/faq/#header-why-does-inko-use-the-mpl-20 https://inko-lang.org/faq/#header-why-does-inko-use-the-mpl-.... The summary is: it protects the project better than the MIT license does. As far as I know the only difference with Apache 2 is that MPL 2.0 requires that modifications are licensed under the same license.