[lawl]

> It pursues its minimal language design further after removing several features from Go like pointers, mutability,

I don't consider pointers and mutability to be features, but I consider immutability and trying to hide pointers a feature. One that I don't want. Allocating too much/too often has been like 95% of the performance issues i had.

Computers use pointers and data in ram is mutable. How is pretending that's not the case removing a feature? It's the exact opposite. One of the reasons I like go is that I can have some control over memory when necessary. But most of the time I don't need to think about it unless the profiler tells me that's where the bottleneck is.

Small edit to not be so negative: The language looks interesting and I think it's well presented. Just not for me, and that above irked me in particular.

[grumpyprole]

Modern machines are essentially distributed computers, multiple levels of cache per core, RAM allocated per core. The flat shared memory address space is an illusion. With such an architecture, immutability and not exposing pointers is a very reasonable approach for many parallel/concurrent workloads. It enables many optimisations.

An algorithm written for such an abstraction is also much more easily adapted to work across multiple machines (e.g. map-reduce).

[anfelor]

Since Pen claims to be inspired by Koka, I would hope that they eventually implement Perceus reference counting [0], which (partially) solves the problem of too many allocations. The idea is that with immutable datastructures you often free a constructor just before allocating the same one again (for example during a map function). But with reference counting we can check if the old constructor is dead and if so use it in-place for the new constructor. Applied carefully, you can build functional programs that use no further memory.

[0]: https://news.ycombinator.com/item?id=25464354

[curryst]

I didn't think there was a massive memory gap between functional languages and other paradigms? I had always made the assumption that it was because immutable data allows the compiler to make optimizations that it normally can't.

For example, you could pass all values by reference implicitly, because they can't be mutated.

There are probably others. It seems like the paradigm is different enough that the pitfalls are also slightly different.