08:57 <Candle> andarp: I have a maven plugin for dep management and project comprehension - https://github.com/CandleCandle/pony-maven-plugin though it doesn't support arbitrary github/etc dependencies; it is in maven central.

08:59 <Candle> I havn't tried running it on Windows, as my pony dev is on unix based systems, but I don't have any reason to believe that it won't work.

14:26 <lillis> Hi! Playing devil's advocate here: the point of capabilities in pony is to be able to safely share data between actors - but simply using immutable data that is copied upon modification solves the same problem. So why go through all the trouble of using Pony and it's capabilities?

14:41 <abeaumont> I guess that because pony's capabilities give you a warranty that that's precisely what you are doing

14:44 <vaninwagen_> lillis, because copying can be pretty expensive. and sharing and passing mutable data around allows for really fast AND safe concurrency

14:45 <lillis> So is speed and actual guarantees the main reasons?

14:45 <lillis> are*

14:45 <vaninwagen_> lillis, at least for me :)

15:09 <lillis> If anyone else wants to chip in I'd be happy for more. I'll leave the channel now but @andarp is me as well so I'll read it later :)

15:56 <Praetonus> lillis, andarp: Yes, the main reasons for capabilities are safety and performance (the main paper about Pony's type system being titled "Deny capabilities for safe, fast actors"). Aside from the obvious performance benefit of not having to copy message contents, pretty much every part of the runtime benefits from the safety guarantees

16:00 <jemc> lillis, andarp: even languages/frameworks that have the paradigm that all data should be in immutable/persistent data structures still often have a concept of temporary mutability while "setting up" a data structure - for convenience and performance reasons

16:01 <jemc> in Pony this is a first-class language concept, with `trn`

16:05 <jemc> passing of an isolated reference to a mutable object is also a common idiom among performance-oriented concurrent applications (though in many languages/frameworks, the safety of your application is relying only on humans' careful implementation of that convention, and not by compiler guarantees)

16:05 <jemc> and of course that is also a first-class language concept in Pony, in the form of `iso`

16:07 <jemc> Pony is not a rejection of either of these paradigms (immutable data structures, isolated references), but rather a affirmation of both, and a proof of the concept that both paradigms can coexist together in compiler-guaranteed safety

16:09 <jemc> that is, as an application developer using Pony I have both sets of tools available at all times, and can apply whichever makes the most sense for what I'm doing rather than trying to force every solution into one or the other category

16:16 <jemc> also, I think it's a bit of a straw man to say "why go through all the trouble of using Pony and it's capabilities" as compared to only using immutable data structures - you can write programs in Pony that only use immutable data structures, and if that's all you're doing I think you'll find that difficulties relating to satisfying capabilities should largely disappear - whenever I've worked on objects that

16:16 <jemc> were all `val` capability, everything just kind of works with no fuss (with regard to capabilities)

16:17 <jemc> that is, everything "just works" other than stuff that you shouldn't be allowed to do with immutable data, like mutate it :P

16:18 <jemc> for example, much of the mental overhead for dealing with capabilities in writing generic classes melts away if you make the class a `val` and constrain the type parameter to `val` or `#share`

16:19 <andarp> Praetonus, jemc: thanks a lot for the answers, they are along the lines of what I guessed except more eloquently put and reasoned about :)

16:20 <andarp> I'm planning on learning pony to a decent degree and then have a short presentation about it at work (I work in fintech). So I'm trying to beat the most common instinctive reactions to the punch when faced with a new concept

16:20 <andarp> i.e. "this looks complex and i dont need it because i can solve it this other way i always have"

16:21 <jemc> right, it's definitely a good question to think about, as it's at the core of the value prop for Pony

16:22 <andarp> Personally I would've been sold on Pony if it was just "Go with generics" but that's because it seems the general language design/syntax just perfectly aligns with my taste. Obviously "Go with generics" isn't close to an accurate description of the language

16:23 <andarp> The capabilities are just pure genius though

16:24 <andarp> I'm rambling :) I'm just excited to get excited about a programming language again

16:24 <jemc> I was sold on Pony after dealing with oher actor systems that had zero-copy mechanisms, but had no way to guarantee the safety of what I was doing with them - it was always just relying on me being really careful, which is rather unnerving over time

16:25 <andarp> Yes, I find those types of solutions constrain the way you reason about the problem you're trying to solve, being scared about what you can and can't do.

16:25 <jemc> I had spent some time trying to come up with various framework aids to make breaking safety harder to do, but upon finding Pony I was definitely quite excited that it seemed to have solved the problem properly from the ground up

16:26 <andarp> The pony docs/vids I've seen talk a lot about "reasoning locally" and I think that really hits the nail on the head

16:27 <andarp> The smaller your scope of worries and abstractions the better

21:33 <andarp> Watching the "Writing Generic Code" VUG I see a lot of places where you'd normally pass a function but instead interfaces (?) implemented on primitives are used

21:33 <andarp> if this a common pattern?

21:33 <andarp> e.g. the HashFunction[K] in HashMap

22:55 <SeanTAllen> andarp: so.. primitives. secretly they are also a bit like a module

22:56 <SeanTAllen> in fact you can use them a bit like an OCaml module

22:56 <SeanTAllen> and in those places that you are highlighting, yes its a somewhat common pattern and a way to specialize non stateful code

22:58 <SeanTAllen> I've discussed with Sylvan and Joe using that same pattern for FFI calls that would allow you to swap out the real FFI calls with another primitive that would allow you to insert testing code

22:58 <SeanTAllen> andarp: what you've noticed could be explained and written up as a Pony Pattern.

22:58 <SeanTAllen> if you feel like giving that a go, let me know. explaining the ins and outs of a topic is a great way to learn it.

22:59 <SeanTAllen> i'd be happy to help anyone who write that usage of primitive up as a Pony Pattern.

23:58 <andarp> SeanTAllen: Thank you, that is really interesting. I recognize the pattern in some ways from e.g. Java and C#, using interfaces as a way to plug in functionality for e.g. a comparate function. But the way it's expressed in the code shown is a lot more terse and clean

23:59 <andarp> compare*