Topics

Pony *usage* Videos/Presentations/Talks

Dmitry Kakurin
 

Hi Pony fans,

I've watched a number of presentations describing the Pony language itself, its type system, actors, reference capabilities, GC, etc. Good stuff!

Now I'm looking for a presentation demonstrating (preferably on concrete example(s)) how solving a particular problem in Pony was easier/faster/simpler/safer/more pleasant, etc.

In other words people doing real projects in Pony and describing how they've benefited from choosing Pony over any other language.

The closest talk I can think of is VUG 7 on PonyGame, and even that one mentions Pony benefits somewhat tangentially and mostly as a future work.

Any pointers?

Also (unrelated) what's the story with implementation of Value Dependent Types described in VUG 4? I've tried and they are still not supported.

 

Hi Dimitry,

This talk given by Sean T. Allen at Code Mesh last year describes a Stream Processor written in Pony. It doesn't go too deep into the reasons for choosing Pony over other languages but it's a good talk nonetheless. 

 


On Mon, Jan 9, 2017 at 8:41 PM, Dmitry Kakurin <dmitry.kakurin@...> wrote:
Also (unrelated) what's the story with implementation of Value Dependent Types described in VUG 4? I've tried and they are still not supported.

Luke is closing in on having this ready to be merged. That said, we keep moving the target underneath him.

 

Hi Dmitry,

There's not a lot of people doing "real work" with Pony right now. I think your best bet is to talk to one of them.
One of us from Sendence is probably a good person to talk to.

Here's my anecdote for you.

I'm rather experienced. I'm one of those people who is pretty good at writing multithreaded code that mutates values.
I rarely introduce data races, deadlocks compared to my colleagues.

And when I started writing Pony code, the compiler would regularly point out error where I was trying to do something unsafe.
Sometimes I would spend 15-20 minutes puzzling over what the issue was. In almost every case, I eventually realized what the
compiler was protecting me from and how the bug would almost never happen and would take months to track down if it was
ever going to be possible to reproduce.

If you want to go fast and you want it to be correct and safe, Pony has the tools to help you do it.

In return, you have to be willing to have:

- tooling that is going to lag behind over languages for the foreseeable future.
- a relatively small standard library
- few 3rd party libraries
- wrap C libraries if you really need functionality X and can't write it yourself
- deal with occasional weird compiler issues

and a variety of other things that come with an immature language

In return you will get:

- a type system that can help you do unsafe things safely
- the ability to write really fast safe code
- freedom from thinking about most data races
- the chance to make a lasting imprint upon a community

I've been using Pony every day for over a year now. We at Sendence have invested heavily in Pony.
I'm not at all sorry that we did. If we had gone with C++, I'd still be chasing down weird data sharing
issues and null pointer issues.

Pony is not right for everyone but if your needs fit Pony's existing sweet spot, I don't think you'll regret
choosing it.

-Sean-



On Mon, Jan 9, 2017 at 8:41 PM, Dmitry Kakurin <dmitry.kakurin@...> wrote:

Hi Pony fans,

I've watched a number of presentations describing the Pony language itself, its type system, actors, reference capabilities, GC, etc. Good stuff!

Now I'm looking for a presentation demonstrating (preferably on concrete example(s)) how solving a particular problem in Pony was easier/faster/simpler/safer/more pleasant, etc.

In other words people doing real projects in Pony and describing how they've benefited from choosing Pony over any other language.

The closest talk I can think of is VUG 7 on PonyGame, and even that one mentions Pony benefits somewhat tangentially and mostly as a future work.

Any pointers?

Also (unrelated) what's the story with implementation of Value Dependent Types described in VUG 4? I've tried and they are still not supported.

Dmitry Kakurin
 

Thanks Sean,

It's interesting to me that most presentations (and your anecdote) is an appeal to developers using lower-level languages like C++ with a promise of safety. I suspect it's the fintech influence.

It looks like there is also great potential for attracting devs using higher-level languages like Erlang/Elixir with a promise of increased performance and controlled mutation.

Also Go and and Java devs would benefit from both race-freedom and perf :-).

 

Speaking as the VP of Engineering at Sendence and not as a Pony core member:

We chose Pony because (this is the shortened list)

1- We didn't think we could get the perf we needed from Erlang
2- We didn't trust ourselves with C++
3- We didn't want to write off heap Java

There have been tradeoffs with Pony but, that's engineering. Overall we are happy.

Speaking as a Pony core member:

Indeed. Different developers will have different paths to Pony.

-Sean-



On Wed, Jan 11, 2017 at 4:51 PM, Dmitry Kakurin <dmitry.kakurin@...> wrote:

Thanks Sean,

It's interesting to me that most presentations (and your anecdote) is an appeal to developers using lower-level languages like C++ with a promise of safety. I suspect it's the fintech influence.

It looks like there is also great potential for attracting devs using higher-level languages like Erlang/Elixir with a promise of increased performance and controlled mutation.

Also Go and and Java devs would benefit from both race-freedom and perf :-).

Robert Hastings
 

I'm looking at moving from Java to Pony because of the race freedom.

 

It's been a boon to us for the project we are working on.

On Wed, Jan 11, 2017 at 11:57 PM, Robert Hastings <mr.robert.hastings@...> wrote:
I'm looking at moving from Java to Pony because of the race freedom.

Manas Marthi
 

On Mon, Jan 9, 2017 at 08:36 pm, Sean T. Allen wrote:
Pony is not right for everyone but if your needs fit Pony's existing sweet spot, I don't think you'll regret
choosing it.

 Hi Sean,

   I watched one of your talks about how you are using pony at sendence for stream processing and analytics. 

   But I am not clear on what type of problems pony is not the right choice..Are they like GUI applications that that need blocking calls or where explicit thread prioritization and preemtpive scheduling is needed?  Could you please elaborate more on this..

thanks

Manas

 

That would be an exhaustive list. I think it would be easier to answer specific use cases and go with that. That said, here are a few:

You don't a problem where concurrency is helpful. Due to how the Pony garbage collector works, a "single threaded" application that is done entirely in the Main actor is going to potentially run into serious memory problems.

You don't know how to solve the problem in a non-blocking fashion. I don't believe there are many problems that require the use of blocking calls. It's a matter of expressing the problem in a different way. Sometimes, the blocking approach feels far more natural. Either way, if you aren't familiar with doing async programming then Pony might not be the right tool for you. If your problem can be solved in a blocking fashion, with the performance you need, then do it in the language you are used to.

You need a variety of libraries that don't exist in Pony. If you have 2 months to finish a GUI project, Pony is not your language. You aren't going to get it done. There's too much groundwork for you to have to do first.

If you have a specific use case in mind and are able to talk about your constraints, I'm happy to work through whether Pony is the right language for you to try to use. If you can't divulge some information in a public forum but can over private email, I'm happy to discuss in that fashion.

As to what Pony is good for: highly concurrent programs where you are manipulating state and want to make sure you don't mess it up. That's a sweet spot, there's more but it starts there. 

-Sean-


On Thu, Mar 9, 2017 at 4:40 AM, Manas Marthi <manas.marthi@...> wrote:
On Mon, Jan 9, 2017 at 08:36 pm, Sean T. Allen wrote:
Pony is not right for everyone but if your needs fit Pony's existing sweet spot, I don't think you'll regret
choosing it.

 Hi Sean,

   I watched one of your talks about how you are using pony at sendence for stream processing and analytics. 

   But I am not clear on what type of problems pony is not the right choice..Are they like GUI applications that that need blocking calls or where explicit thread prioritization and preemtpive scheduling is needed?  Could you please elaborate more on this..

thanks

Manas

Andrew Turley
 

I'll add my 2 cents here (I work with Sean so I use Pony for work, but I also spend some time with it on my own projects) ...

I think one of the best use cases I've found for Pony is writing server applications (long-running applications that take input and do something with it). Pony's notification-based libraries make it easy to write programs that take input messages and process them, and the actor model gives you a very safe and flexible way of communicating between entities in the program.

At the risk of being booed off stage, I'd say that Pony is a bit like Node.js in this respect. I know that Node.js is being used for just about everything these days (for better or for worse), but the original pitch was that you could use it to quickly set up a custom server for specific protocols like HTTP, or whatever protocol you decided you wanted to handle. Some of Pony's libraries aren't as developed as the Node.js libraries, but I've found Pony to be very pleasant to use when writing servers or clients that connect to servers.

I've been slowly putting together a project that I call "Minfrastructure" (mini infrastructure) that consists of simple Pony implementations of common pieces of infrastructure (a message queue, a pub-sub system, a key-value store, etc) to show how Pony can be used to solve these kinds of problems.

andy

On Thu, Mar 9, 2017 at 8:05 AM, Sean T. Allen <sean@...> wrote:
That would be an exhaustive list. I think it would be easier to answer specific use cases and go with that. That said, here are a few:

You don't a problem where concurrency is helpful. Due to how the Pony garbage collector works, a "single threaded" application that is done entirely in the Main actor is going to potentially run into serious memory problems.

You don't know how to solve the problem in a non-blocking fashion. I don't believe there are many problems that require the use of blocking calls. It's a matter of expressing the problem in a different way. Sometimes, the blocking approach feels far more natural. Either way, if you aren't familiar with doing async programming then Pony might not be the right tool for you. If your problem can be solved in a blocking fashion, with the performance you need, then do it in the language you are used to.

You need a variety of libraries that don't exist in Pony. If you have 2 months to finish a GUI project, Pony is not your language. You aren't going to get it done. There's too much groundwork for you to have to do first.

If you have a specific use case in mind and are able to talk about your constraints, I'm happy to work through whether Pony is the right language for you to try to use. If you can't divulge some information in a public forum but can over private email, I'm happy to discuss in that fashion.

As to what Pony is good for: highly concurrent programs where you are manipulating state and want to make sure you don't mess it up. That's a sweet spot, there's more but it starts there. 

-Sean-


On Thu, Mar 9, 2017 at 4:40 AM, Manas Marthi <manas.marthi@...> wrote:
On Mon, Jan 9, 2017 at 08:36 pm, Sean T. Allen wrote:
Pony is not right for everyone but if your needs fit Pony's existing sweet spot, I don't think you'll regret
choosing it.

 Hi Sean,

   I watched one of your talks about how you are using pony at sendence for stream processing and analytics. 

   But I am not clear on what type of problems pony is not the right choice..Are they like GUI applications that that need blocking calls or where explicit thread prioritization and preemtpive scheduling is needed?  Could you please elaborate more on this..

thanks

Manas


Manas Marthi
 
Edited

On Thu, Mar 9, 2017 at 06:54 am, Andrew Turley wrote:
ve been slowly putting together a project that I call "Minfrastructure" (mini infrastructure)

 Is it on github.. I guess it would be good to have priority list of libraries that need to be implemented/ported to Pony

 I believe some sort rails or node libraries would be ideal.

 I once saw a talk by a principal engineer VMWare about JVM performance. And he mentioned in their clientele 70-80% of Java applications were web applications. In my own experience, the number of developers creating web based data entry screens is quite high. Next to it were End of day batch program developers. Rails, CakePHP, Groovy on Grails were pitched showing how easy it is to do CRUD screens. But in my experience we never developed so dumb screens. There will at least be maker checker operations involved backed by stored procedures..

 Another thing I noticed is that tech companies try to be ahead in the jargon bandwagon - "We do RestFUL microservices, we are also reactive, we support Apache Kafka". (I doubt if RestFUL webservices is the best way to develop micro services. I think using ZeroMQ is better than doing RestFUL webservices for message passing between services. But I did not got a chance to make a pitch for it, because someone decided that it would be Restful webservices before I joined my current company)

 To sum up my thoughts, it takes some sort of Rails/Node to make Pony popular among hipsters. But is Pony looking to become popular among hipsters or is it targeting enterprises with deep pockets and specialized applications. Not sure what's the vision of the core team for Pony.


 

A quick note:

I don't believe setting up dichotomies like Hipster/Enterprise is helpful.

Re: "the vision"

The vision of the core team to fashion Pony into a tool that is great for solving our problems and serves the community while remaining true to the Pony philosophy. In the end, it matters little where we want Pony to go. If the community ends up focusing on web development, so be it. The core team is but a few people. We will never on our own make Pony popular. The community that grows around this little language we love will, in the end, decide where Pony ends up. Will we act as stewards? Yes. Will we reject some things because they don't fit with the Pony philosophy? Yes.

For anyone who is interested in helping to evolve Pony, I suggest that you play around with the language, get a good feel for its warts and strengths and then start scratching your issues via libraries and if it requires core changes, via our RFC process: 


-Sean-


On Thu, Mar 9, 2017 at 1:23 PM, Manas Marthi <manas.marthi@...> wrote:

[Edited Message Follows]
[Reason: My edits were lost due to inactivity]

On Thu, Mar 9, 2017 at 06:54 am, Andrew Turley wrote:
ve been slowly putting together a project that I call "Minfrastructure" (mini infrastructure)

 Is it on github.. I guess it would be good to have priority list of libraries that need to be implemented/ported to Pony

 I believe some sort rails or node libraries would be ideal.

 I once saw a talk by a principal engineer VMWare about JVM performance. And he mentioned in their clientele 70-80% of Java applications were web applications. In my own experience, the number of developers creating web based data entry screens is quite high. Next to it were End of day batch program developers. Rails, CakePHP, Groovy on Grails were pitched showing how easy it is to do CRUD screens. But in my experience we never developed so dumb screens. There will at least be maker checker operations involved backed by stored procedures..

 Another thing I noticed is that tech companies try to be ahead in the jargon bandwagon - "We do RestFUL microservices, we are also reactive, we support Apache Kafka". (I doubt if RestFUL webservices is the best way to develop micro services. I think using ZeroMQ is better than doing RestFUL webservices for message passing between services. But I did not got a chance to make a pitch for it, because someone decided that it would be Restful webservices before I joined my current company)

 To sum up my thoughts, it takes some sort of Rails/Node to make Pony popular among hipsters. But is Pony looking to become popular among hipsters or is it targeting enterprises with deep pockets and specialized applications. Not sure what's the vision of the core team for Pony.


Andrew Turley
 

Minfrastructure is not on github at this point, but I'm working on getting it there. I'll post a link here when I have something.

"I guess it would be good to have priority list of libraries that need to be implemented/ported to Pony"

I don't know that there's necessarily a prioritized list of things that need to be done. Folks will build things as they have the need. If other people find those libraries useful, they'll use them. Those libraries can start as independent libraries, and if they're useful they can be incorporated into the standard library. If there's something that you really believe should be in the standard library then you should bring it up as an RFC using the process Sean mentioned.

To add my own thoughts to what Sean said, the Pony core team has a philosophy that will control where the language goes, but the people writing libraries and frameworks and applications will determine how it gets used.

If somebody wants to write a framework that lets you create a CRUD application with 20 lines of Pony, that wouldn't inherently violate the Pony philosophy. On the other hand, if they started pushing for language changes to make it easier specifically to write CRUD applications then that would be an issue.

One way of looking at it is that Pony isn't a language specifically designed for writing servers, but the decisions that were made in implementing the language make it a good language for writing servers.

andy (Microsoft Certified Enterprise Hipster)

On Thu, Mar 9, 2017 at 2:27 PM, Sean T. Allen <sean@...> wrote:
A quick note:

I don't believe setting up dichotomies like Hipster/Enterprise is helpful.

Re: "the vision"

The vision of the core team to fashion Pony into a tool that is great for solving our problems and serves the community while remaining true to the Pony philosophy. In the end, it matters little where we want Pony to go. If the community ends up focusing on web development, so be it. The core team is but a few people. We will never on our own make Pony popular. The community that grows around this little language we love will, in the end, decide where Pony ends up. Will we act as stewards? Yes. Will we reject some things because they don't fit with the Pony philosophy? Yes.

For anyone who is interested in helping to evolve Pony, I suggest that you play around with the language, get a good feel for its warts and strengths and then start scratching your issues via libraries and if it requires core changes, via our RFC process: 


-Sean-


On Thu, Mar 9, 2017 at 1:23 PM, Manas Marthi <manas.marthi@...> wrote:

[Edited Message Follows]
[Reason: My edits were lost due to inactivity]

On Thu, Mar 9, 2017 at 06:54 am, Andrew Turley wrote:
ve been slowly putting together a project that I call "Minfrastructure" (mini infrastructure)

 Is it on github.. I guess it would be good to have priority list of libraries that need to be implemented/ported to Pony

 I believe some sort rails or node libraries would be ideal.

 I once saw a talk by a principal engineer VMWare about JVM performance. And he mentioned in their clientele 70-80% of Java applications were web applications. In my own experience, the number of developers creating web based data entry screens is quite high. Next to it were End of day batch program developers. Rails, CakePHP, Groovy on Grails were pitched showing how easy it is to do CRUD screens. But in my experience we never developed so dumb screens. There will at least be maker checker operations involved backed by stored procedures..

 Another thing I noticed is that tech companies try to be ahead in the jargon bandwagon - "We do RestFUL microservices, we are also reactive, we support Apache Kafka". (I doubt if RestFUL webservices is the best way to develop micro services. I think using ZeroMQ is better than doing RestFUL webservices for message passing between services. But I did not got a chance to make a pitch for it, because someone decided that it would be Restful webservices before I joined my current company)

 To sum up my thoughts, it takes some sort of Rails/Node to make Pony popular among hipsters. But is Pony looking to become popular among hipsters or is it targeting enterprises with deep pockets and specialized applications. Not sure what's the vision of the core team for Pony.



Previous Topic Next Topic