[klibertp]

You jealous?

Also, picking a right tool for the job can be a real advantage, which makes it easier to deliver features.

Getting so close to C implementation (in terms of speed) with Pony is actually insane if you look at the number of guarantees Pony gives you. Next time you dereference a NULL pointer please remember that it's impossible in Pony. Oh, and next time you spend a week debugging some hairy locking issue, consider that issue wouldn't happen in Pony at all. EDIT3: removed EDIT1 from here.

Currently, Pony is in direct competition with Go (but uses the other concurrency model) and Erlang/Elixir (but is natively compiled). People and companies frequently choose Go or Erlang, so I don't really understand why they shouldn't choose Pony if their use-case fits.

EDIT2: And here I am getting downvoted... I wonder, is anything I wrote not true?

[jetti]

>so I don't really understand why they shouldn't choose Pony if their use-case fits.

The difference between Pony and Go or Erlang (or even Elixir) is that the Pony team still are making breaking changes to the language. That means that your dev team may need to spend time to update features due to breaking changes in the language. Also, the ecosystem isn't there like it is for Go or Erlang.

[klibertp]

Yeah, but both Go and Elixir (Erlang less so - commercial and internal PLs work a bit differently) were in the same situation at some point: very small ecosystem, small community, lots of changes to the language. Adopting a language at this stage of evolution has a set of very well-known risks, but it has to be done by someone for the language to ever reach maturity. Trying to use it seriously is one of the best ways to contribute to the language.

In any case, if you are aware of the risks and plan to mitigate them - by, for example, employing people capable of debugging and fixing the language's implementation - you're left with some risk and a lot of advantage (if you're lucky and your domain is indeed the one your language is best suited for). It's a gamble, of course, but then nearly every decision (other than buying IBM) is one.

[spooneybarger]

Those are excellent points that we considered when we went with Pony. So far, we feel it has worked out well. A large number of those breaking changes have originated with us at Wallaroo Labs so they've been pretty easy for us to stay on top of.

[manigandham]

Actor style concurrency exists for many other language platforms. See Akka for JVM/Scala or Seastar for C++.

I'm somewhat skeptical of GC pauses being a problem in anything that's not actual hard real time like avionics or manufacturing equipment or similar. What difference will a few hundred millisecond pause even make in an distributed async data pipeline? And that's on the higher end of pauses these days.

[spooneybarger]

There's an excellent paper on GC pauses and its impact on Spark and Hadoop. "Trash Day" => https://www.usenix.org/node/189882

[manigandham]

Sure, I understand pauses happen and there is a performance degradation, I'm asking whether it really matters in a processing framework that isn't controlling medical equipment or airline hydraulics. Is something going to break if there's a small pause? Especially in return for the productivity and safety of using managed runtimes?

[sidlls]

It's the aggressive tone larded with use of cherry-picked negative aspects of using other languages and irrelevant details, I suspect.

[klibertp]

> cherry-picked negative aspects of using other languages and irrelevant details

I don't understand? Why are they irrelevant? They're basically Pony's reason for existing... Cheap, efficient and safe concurrency, coupled with very high level of type-safety, is the main selling point on Pony. It is much better on these counts than many other languages. Maybe I shouldn't have mentioned Python and Ruby, I'll edit the post.

> It's the aggressive tone

I see. Compared with the charming politeness of the OP comment, I must have sounded really rude. I apologize.

[ianleeclark]

I don't know if 5-10% difference in write speed and 75% in read speed is "so close to C implementation." These are both operations that will be happening thousands/millions/+ times per day, so it feels incorrect to say they're close.

These read/write differences will compound to make the rest of the data processing pipeline slower.

[wtetzner]

They already commented on that performance:

> Yes, Pony Kafka is currently slower than the C client. But it is also almost completely untuned as of right now. We expect there is a lot of low hanging fruit on that front that will give us significant gains.

>There is also the secondary concern regarding the thread pools internal to Pony and librdkafka. We've seen first hand how CPU cache invalidation can impact performance so we are very aware of the potential negatives if the Pony and librdkafka threads ever end up fighting with each other over the same CPU resources.

[klibertp]

For the first, proof-of-concept, no-optimizations-applied, version of a low-level library written from scratch in a high-level language to be anywhere near production-ready, presumably optimized C implementation is actually very impressive. I'd expect the new implementation to be an order of magnitude (or more) slower than the C one, initially, and only get better with many rounds of optimizations in the following months.

[AHTERIX5000]

Jealous of having to rely on Kafka client with not too much of testing or performance written from scratch on top of experimental language?

[klibertp]

Obviously, I was referring to this part of GP post:

> add Pony to our CV and move on in one year to the next company where we will introduce the next big thing to add to our CVs. Plus 10% more salary!

It just sounds like venting to me, without any rational or fact-based argument for why using Pony is bad in this specific case. Doesn't it?