3 ms·
I want to thank whoever wrote the "Why Not To Use Pony" bullet points. They're quite honest and helpful. Most of these sorts of pages are 110% "rah rah our lang
by CobrastanJorji 4y ago
I want to thank whoever wrote the "Why Not To Use Pony" bullet points. They're quite honest and helpful. Most of these sorts of pages are 110% "rah rah our language is the best for every possible situation, which makes it hard to figure out how to evaluate them. For me personally, this has seemed worst with database products. No matter what the database's actual pros and cons are, their project pages will swear that they are the best at every possible scenario that might involve data.
- deleted 4y ago[deleted]
- emmelaich 4y agoWhere is that list?
- theIV 4y agohttps://www.ponylang.io/discover/#why-not-pony https://www.ponylang.io/discover/#why-not-pony
- rtpg 4y agoI think it's a bit of a cop out. 3 variations on "we're not big yet!" Examples of things that might be true (I do not know how true this is! Inferring off of what is seen, and I am not judging Pony on any level) - "prototyping UI work in Pony will not work, as there are no great known patterns for writing small UIs that play well with the consequences of our design decisions prioritizing correctness" - "our actor based model works well for the vast majority of highly concurrent programs, but can make realtime systems hard to get right" (I have had this experience in Rust trying tokio vs just opting for manual threading) - "restrictive syntax means that solution spaces involing DSLs will leave you wanting." I think everything is good and great, but it's valuable to lay out the priorities and what are less of a priority. Of course tooling kinda sucks for newer languages. Of course! Tell me about things that will likely always be a bit miserable.
- lolinder 4y agoThe problem is that your proposed "bad at" list could be infinite. Pony is probably a bad choice for embedded, scientific, mobile, graphics, browser, etc. What they've done instead is they've explained why you might want to use pony and then explained why you may not even if the "why" sounded like a perfect fit. You came up with a list of bad fits just fine based on what they told you it was good at, without them having to spell out every no-go. Their list of reasons why not is intended to disuade people who would otherwise be their target audience.
- eyelidlessness 4y agoI don’t get your complaint, it seems you’ve provided very good examples of them doing exactly what you say you want them to do. As an example from someone who finds the language compelling in some ways, outright ruling out DSLs is a major factor that would rule it out of consideration for me. Better that they saved me the trouble of wondering!
- rtpg 4y agoSorry, I wasn't clear. What I listed was not in fact what they wrote, but what _I_ would write given this exercise. What they wrote was (summarizing) that there is not a lot of tooling available, there still isn't API stability, and not many libraries available.
- eyelidlessness 4y agoMy apologies, I should’ve checked, but maybe you could offer some of these caveats as a contribution. Your language was even convincing enough I thought it was theirs.
- ofrzeta 4y ago> they're quite honest I've come to appreciate the "when X is not the right choice" that some projects list. Even if it's the right choice it often provides additonal information because it deliberately takes a different perspective. Related to "being honest" are the many bullet points some projects lists as features only to have you discover very much later that it's more like a roadmap without saying so. Just be honest when you describe your project because exaggerations will only lead to frustration among potential users.