4 ms·

Couple of questions: - What is your plan on package management? - With concurrent languages I always see a great potential of building something that is bette

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
  When I saw `try`, the first thing that came in my mind was Zig language; that's where I first saw this: https://ziglang.org/documentation/master/#try https://ziglang.org/documentation/master/#try
mamcx 8y ago
> What is your plan on package management? I wonder how avoid to build one, and just reuse a good one. How feasible is it?
- YorickPeterse 8y ago
  As far as I know it technically is an option, just not a very nice one. Most package managers tend to be _very_ specific in how they do things, making it hard to extend them beyond that. Arch Linux' package manager might be an exception, but I'm not sure how reusable it is.

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
When I saw `try`, the first thing that came in my mind was Zig language; that's where I first saw this: https://ziglang.org/documentation/master/#try https://ziglang.org/documentation/master/#try

mamcx 8y ago

> What is your plan on package management? I wonder how avoid to build one, and just reuse a good one. How feasible is it?

YorickPeterse 8y ago
As far as I know it technically is an option, just not a very nice one. Most package managers tend to be _very_ specific in how they do things, making it hard to extend them beyond that. Arch Linux' package manager might be an exception, but I'm not sure how reusable it is.