eriksvedang

OK, I see what you mean now. Thanks for the feedback, I'll make sure to think about this more before stabilising the modules.

The ”IO_” part is the namespace, so no clashes!

Normal usage of arrays (and structs) is through an immutable api, internally it uses mutation though. See example/updating.carp for example.

Correct, not at the moment. Overall the type system is less expressive but also less dependent on annotations. Differentiating between immutable and mutable refs is probably coming though, it’s a useful distinction for sure.

Primarily stand-alone.

Thanks for the links!

The short answer is that safety is handled similar to Rust, using lifetime analysis. It's quite a bit more simplistic than Rust at the moment though. Also, some checks are done at runtime (like bounds checking on arrays, when turned on).

It will require roughly the same amount of practice as when learning Rust, so a pretty significant learning effort I'm afraid.

I'll try to do as much checking as possible in the interpreter so that the transition from interpreted to compiled code is smooth. Right now there is none though.

No tail recursion at the moment but it's something I'd be interested in adding later.

I'm being very conservative with adding different type constructs but sure, Rust & Go certainly gets a lot of things right in that department and I'll consider their solutions for the future development of Carp.

Interesting, thanks a lot for the tip!

Yes, only the statically compiled code is GC free.

1. Yes, and yes!

2. No plans for inheritance at the moment, probably some kind of interfaces but that's not a top priority right now. Custom types are limited to structs, I will add union types soon

3. This has not been decided yet, I want to do more research before settling on any particular solution. It will be a high priority though, since I want to use it for the games I write

Thanks, Erik