Earlier quoted context omitted.
[flagged]
This is textbook no true scotsman fallacy, you're aware, right?
And? Doesn't mean it's not true. It just means you can't use it to win an argument against a nerd.
Pony: An actor-model, capabilities-secure, high-performance programming language
131–140 of 284 posts
Re: Pony: An actor-model, capabilities-secure, high-performance programming language
#132Earlier quoted context omitted.
> Does it means that if I tried to implement a python interpreter in Pony it will statically reject the implementation? How could that be true? You'd be emulating the language particularities, so deadlocks would be just virtual states. Your interpreter itself being free of deadlocks doesn't mean it cannot represent them. It's like thinking that you cannot write e.g. console emulators in Rust, because people typically…
Well, yes, that's my point. So what does it means that Pony is deadlock-free?
It means that the language and runtime both agree not to look at your dead-end state, so no-one can say it's their fault ;)
For example I can define a notsemaphore actor that calls a callback once an internal count reaches 0, and then I can forget to decrement it and so it will never reach 0. But technically this didn't involve synchronization so there isn't a stack trace to tell me why is my program stuck and somehow this is better.
Re: Pony: An actor-model, capabilities-secure, high-performance programming language
#133Earlier quoted context omitted.
Then make your arguments instead of making us try to read your mind. Why is Pony special?
See: https://www.ponylang.io/discover/why-pony/ I don't think that Pony is claiming to be novel in the area of syntax?
If “reference capabilities” are the important thing about Pony, they should have a max 100-200 LoC example on the front page that uses them.
As far as I can tell reading here, “reference capabilities” don’t do anything that properly-used C semaphores haven’t done for near half a century. Or that their abstraction of that isn’t nicer to use than, say, Elixir’s, or better than Rust’s borrow checker for managing mutability. A code example could convince me otherwise.
Show us code that uses “reference capabilities” to do something. This “the syntax doesn’t matter” talk just comes off as bullshit to devs wanting to actually use a language. It would be better to commit to a syntax, post some damn examples on the site, and let devs get used to “reference capabilities.” If the syntax needs revising, just do that in Pony v2.
If you want devs to be enthusiastic about your language, make it easy for them to understand why they should be enthusiastic. That means code, front and center, first thing.
Re: Pony: An actor-model, capabilities-secure, high-performance programming language
#134I wish these language websites would put an example of some code right there on the homepage so I can see what the language "feels" like. I finally found some code in the tutorials https://tutorial.ponylang.io/getting-started/hello-world
I think Nim has a good homepage, with some bullet points explaining what the language is all about coupled with several code examples. I'm not saying Nim is better, but I visited the page the other day and thought it was neat. https://nim-lang.org/
Nim feels like the perfect language to me. Keep meaning to give it a shot for something.
Re: Pony: An actor-model, capabilities-secure, high-performance programming language
#135Re: Pony: An actor-model, capabilities-secure, high-performance programming language
#136It's a great concept but the ecosystem, tooling, and stewardship are really crap.
It's sad that the only company using it in production switched to using Rust.
The only company "publicly" using it. I know Sean has mentioned there's a lot of fintech (i think) using it, just not blogging about it.
Re: Pony: An actor-model, capabilities-secure, high-performance programming language
#137Earlier quoted context omitted.
And? Doesn't mean it's not true. It just means you can't use it to win an argument against a nerd.
> Doesn't mean it's not true. True, it just means that it's idiotic, rather.
oof I'm pretty sure that's a fallacy, let me just consult the manual here...
Re: Pony: An actor-model, capabilities-secure, high-performance programming language
#138Earlier quoted context omitted.
Ok, partially evaluate the interpreter against a python always-deadlocking program. Now it no longer implement arbitrary logic, but it is a very specific program. Yet it deadlocks. So what does it means that Pony is deadlock free if it can implement deadlocking programs? A better, more rigorous claim would be that the pony runtime is deadlock free or that there are no primitive blocking operations.
Within the context of your Pony program you'll never be deadlocked. The virtual machine you implement capable of universal compute, and not enforcing this constraint, can be internally deadlocked, but this doesn't prevent your other Pony code from progressing necessarily - the deadlock is an internal state for that virtual machine, formally guaranteed to be confined to it. I'd be hesitant to call this a "Pony runtime…
That's a bit like saying that pthreads is deadlock free because the Unix kernel can still schedule other programs. It is an useful guarantee, but it doesn't help fix my broken program.
Re: Pony: An actor-model, capabilities-secure, high-performance programming language
#139I keep being irritated by the fact that Pony does not have operator precedences. You have to parenthesize arithmetics.
Re: Pony: An actor-model, capabilities-secure, high-performance programming language
#140Earlier quoted context omitted.
Well, yes, that's my point. So what does it means that Pony is deadlock-free?
It means that the language and runtime both agree not to look at your dead-end state, so no-one can say it's their fault ;) For example I can define a notsemaphore actor that calls a callback once an internal count reaches 0, and then I can forget to decrement it and so it will never reach 0. But technically this didn't involve synchronization so there isn't a stack trace to tell me why is my program stuck and someho…
As someone that has spent the last week debugging a possible deadlock in pure async message passing code, I'm not amused :).