Are there any statistics that compare this to some similar existing software?
Why we used Pony to write Wallaroo
61–70 of 87 posts
Re: Why we used Pony to write Wallaroo
#62I do enjoy reading these "Why we used to build " posts, as they're usually insightful and provide a glimpse into languages or frameworks I'm not familiar with. On the flip side, I can't help but wonder how likely they would have been to use Pony had none of their core team members been active in the Pony community.
Hope you enjoy this one as well. We weren't active in the Pony community until we decided to use it for Wallaroo. We felt it was very important to invest in the improvement of Pony. And to do that, we needed to be part of the community. Pony became our runtime instead of writing one ourself. That doesn't mean we don't have to work on our runtime. It means we are sharing the burden with others.
Oh wow, well I'm all the more impressed then. It's admirable to try out new tech and venture into the unknown. Kudos!
Re: Why we used Pony to write Wallaroo
#63I do enjoy reading these "Why we used to build " posts, as they're usually insightful and provide a glimpse into languages or frameworks I'm not familiar with. On the flip side, I can't help but wonder how likely they would have been to use Pony had none of their core team members been active in the Pony community.
Interestingly enough, none of us had even written anything significant in Pony when we made the initial tentative decision. After we came to the conclusion that it might be a good fit, we started a test project and a couple of us tried ramping up as fast as we could. It was actually only after we decided it was the right choice that we started to get actively involved in the community.
Very cool, thanks for sharing!
Re: Why we used Pony to write Wallaroo
#64> The standard JVM garbage collection strategy is “stop the world.” This is quite an over-simplification for what is a fundamental property to think about when designing a performance-oriented system. The default collector in HotSpot does, I think, stop the world when collecting. But it also does multiple small collections between larger major collections. It, by default, optimizes for throughput over latency since m…
Depends on the sizing I believe. One problem I see in Java-based DB like Cassandra and Elasticsearch is JVM busy doing garbage collection. The major collection kicks in all the time. Probably because of bad config and bad data usage pattern, but it is still a common problem for me. I am all ears for advice.
Re: Why we used Pony to write Wallaroo
#65Earlier quoted context omitted.
I'll take the liberty to speculate and assume your parent comment was asking if Pony classes have the same features as Java classes -- namely class-level attributes, instance-level attributes, different access levels to attributes and methods. Those things. So, does it?
Pony classes have methods. Pony classes have fields. Fields and methods can be public or private. Private is akin to Java's package private. There are no instance variables.
Thank you. And structs / records? I mean, if there are no instance fields, there has to be some kind of constructs that emulate them.
Re: Why we used Pony to write Wallaroo
#66From Pony documentation: Simplicity Simplicity can be sacrificed for performance. It is more important for the interface to be simple than the implementation. The faster the programmer can get stuff done, the better. It’s ok to make things a bit harder on the programmer to improve performance, but it’s more important to make things easier on the programmer than it is to make things easier on the language/runtime. Thi…
Simplicity should be sacrificed for performance.
For example, code that effectively makes the same decision three times is both slow and obscures the intent of the code.
And there are ways to compartmentalize optimizations so that people working in the general vicinity don’t have to bother with the ‘clever’ code on a daily basis.
Re: Why we used Pony to write Wallaroo
#67Earlier quoted context omitted.
Pony classes have methods. Pony classes have fields. Fields and methods can be public or private. Private is akin to Java's package private. There are no instance variables.
Thank you. And structs / records? I mean, if there are no instance fields, there has to be some kind of constructs that emulate them.
Sorry, I mispoke. There are no class fields. Only instance fields.
Re: Why we used Pony to write Wallaroo
#68> The standard JVM garbage collection strategy is “stop the world.” This is quite an over-simplification for what is a fundamental property to think about when designing a performance-oriented system. The default collector in HotSpot does, I think, stop the world when collecting. But it also does multiple small collections between larger major collections. It, by default, optimizes for throughput over latency since m…
Depends on the sizing I believe. One problem I see in Java-based DB like Cassandra and Elasticsearch is JVM busy doing garbage collection. The major collection kicks in all the time. Probably because of bad config and bad data usage pattern, but it is still a common problem for me. I am all ears for advice.
How much free space is there after a collection? The garbage collector benefits a lot from having enough extra free space to keep things with medium lifetimes in the first generation.
Re: Why we used Pony to write Wallaroo
#69> The standard JVM garbage collection strategy is “stop the world.” This is quite an over-simplification for what is a fundamental property to think about when designing a performance-oriented system. The default collector in HotSpot does, I think, stop the world when collecting. But it also does multiple small collections between larger major collections. It, by default, optimizes for throughput over latency since m…
Depends on the sizing I believe. One problem I see in Java-based DB like Cassandra and Elasticsearch is JVM busy doing garbage collection. The major collection kicks in all the time. Probably because of bad config and bad data usage pattern, but it is still a common problem for me. I am all ears for advice.
This was an anti-pattern of the runtime model that Java inherited from Smalltalk. Tuning the GC used to be an arcane art. There was also a lot of effort put in by programming shops to just reducing GC pressure as an optimization. This is why I appreciate Golang's pragmatic approach of not using the GC by avoiding the heap. The main benefit to having GC is to make initial development faster by reducing the severity and frequency of mistakes. It's really there as a safety net, not as a foolproof end-all be-all. Use tools in a way which plays up their strengths.
It's hard to tune a GC to be super-fast. It's easy to profile and find your biggest memory leaks.
Re: Why we used Pony to write Wallaroo
#70From Pony documentation: Simplicity Simplicity can be sacrificed for performance. It is more important for the interface to be simple than the implementation. The faster the programmer can get stuff done, the better. It’s ok to make things a bit harder on the programmer to improve performance, but it’s more important to make things easier on the programmer than it is to make things easier on the language/runtime. Thi…
The purpose of a program is to satisfy the users, not the developers or the managers, and if the next developer needs to study a thing or two before understanding the code that is OK.
Simplicity should be sacrificed for performance.
This is self contradictory. Programmer resources need to be allocated to pleasing the users. To please users, you need a certain amount of performance. Performance is not simply and end in itself. Programmer resources can be used to please users in other ways.