Live data from Hacker News

Pony: An actor-model, capabilities-secure, high-performance programming language

ponylang.io

251–260 of 284 posts

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#251

I 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 see this comment on all language postings and I just don’t get it. I’m much more curious about the motivation behind the language. If the syntax was that of APL, Forth, or Prolog would you just instantly ignore it because it doesn’t look like Java. I think if the language motivation is compelling then you can decide to dive into a tutorial where the syntax will be explained step by step. I don’t see how syntax can…

Code is poetry and even if you don't know the syntax or details of the tools of the language, a choice example up front gives you a sense of the "rhyme" and "meter" of the language.

Sure, some people are going to use that as an immediate gut filter for "doesn't look enough like languages I already know" or various pet peeves, but on the other side for those that love to dig deep into the syntaxes of esoteric/lesser-known languages it becomes like the first sniff when working on tasting notes of a beverage and tells you a lot up front to your "nose" faster than paragraphs of prose about the motivations of the language. "Ah, yes, I'm sensing a strong Python influence on top of earthy notes of Erlang and just a bit of floral Pascal-ness most recently from the vineyards of Typescript, perhaps?"

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#252
post #199

Request to HN mods: that the link be changed from https://www.ponylang.io/discover/ to https://www.ponylang.io/ On the second link, as another commenter mentions, the "Try it in your browser" is one click away, near the top. On the first link, it's two clicks away, but the first of those clicks is a perhaps surprising backwards-lick to get back to the homepage... Unfortunately, many of the diehard language enthusiast…

> Instead of being able to immediately see the syntax so they can rush back here to make insightful and educated comments on how that syntax compares to $their_fave_lang, they are forced to spend up to 4 or even 5 minutes reading documents clearly describing the design of the language, and being obliged to click on their mouses up to 10 times even in some cases. Welcome to interface design! Your way of thinking could…

> 1. Read a 10 page description of what the car is

> 2. Click on a link buried on page 12 that lets you buy the thing

But the link to the playground is on page 1, the home page, and not page 12? So your whole argument is moot, since it seems the Pony people obeyed at least this part of your interface design dogma.

Or, in other words, "you could not be more wrong if you tried :)".

The issue here was that page 2 was linked in the title, so everyone was getting to page 2, and not clicking back to page 1, where the playground was, and instead clicking forward and getting lost.

And all that aside, as another commenter said, even if the playground was hidden behind the most fiendish of mazes -- perhaps not every programming language is interested in attracting the kind of people who think every corner of the universe must mirror Amazon's approach to "sales".

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#253
post #25

There is a nice Podcast about choosing the right programming language for a project and in this, the final choice is relevant to this post :) https://corecursive.com/055-unproven-with-sean-allen/

"The love child of Erlang and Rust"

Wow, what a phrase! Thanks for the link, very interesting stuff!

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#254

Earlier quoted context omitted.

Using fully qualified imports is a Python tradition. Python doesn't have a notion of public/private symbols (no, "__" prefix does absolutely nothing). It also doesn't have a good type system, so it can't have function overloading. This is why you're required to qualify almost all imports in Python, to avoid name clashes. Nim doesn't have this problem and also "fixes" a lot of other shortcomings[1] of Python.[2] [1] -…

It's not only a Python thing. Many modern languages require this as well. Go, Gleam, Rust, etc. When you're reading Nim code and you see a symbol you don't know, how can you tell where it comes from? In Rust, it's either qualified or you have to explicitly import it. What do you do in Nim?

This is solved by tooling. LSP will get you to symbol definition in a single key press. That's a lot faster then looking it up manually.

In my experience, it's even faster to git clone, open a project in neovim and navigate with LSP than browsing code with some online interface.

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#256

Earlier quoted context omitted.

Nim's import rules are part of its generalization of OOP's obj.foo() syntax. That is, in Nim, you don't have to put "foo" in a specific class, just set the first parameter of "foo" to the type of "obj", and this only works if you don't have to qualify "foo" (similarly to OOP languages...)

I don't see how Nim's import is necessary for that to happen. You can allow the user to specify items to import without the qualifier (like Python's `from lib import foo`), and the universal function call syntax would work, too.

That is allowed, with the exact same syntax as Python. But then you still lose the qualification so I don't see any benefits, it's just more boilerplate to constantly adjust, git conflicts to fight with, etc.

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#257

Earlier quoted context omitted.

Using fully qualified imports is a Python tradition. Python doesn't have a notion of public/private symbols (no, "__" prefix does absolutely nothing). It also doesn't have a good type system, so it can't have function overloading. This is why you're required to qualify almost all imports in Python, to avoid name clashes. Nim doesn't have this problem and also "fixes" a lot of other shortcomings[1] of Python.[2] [1] -…

It's not only a Python thing. Many modern languages require this as well. Go, Gleam, Rust, etc. When you're reading Nim code and you see a symbol you don't know, how can you tell where it comes from? In Rust, it's either qualified or you have to explicitly import it. What do you do in Nim?

> Many modern languages require this as well. Go, Gleam, Rust

All the languages you listed do not support function overloading. Qualified imports and namespaces exist to avoid name clashes first, dependency tracking is just a bonus (and a chore).

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#258
post #245

> Deadlock-Free: This one is easy because Pony has no locks at all! So they definitely don’t deadlock, because they don’t exist! This really annoys me every time I read Pony description. What does deadlock free even mean here? Deadlock-free is typically the property of an algorithm, not a language. Does pony guarantees forward progress in all cases? Does it means that if I tried to implement a python interpreter in P…

Of course it cannot guarantee forward progress in all cases, because that would be NP. Pony guarantees deadlock freedom by eliminating locks and other mechanisms that can lead to deadlocks. Instead, Pony uses a message-passing concurrency model and static analysis to prevent data races and deadlocks at compile time. This means developers don't need to worry about manually preventing deadlocks because the compiler han…

> Because Pony doesn't use locks, there's no possibility of threads getting stuck waiting for each other to release locks, which is a common cause of deadlocks.

It may be a common cause of deadlocks, but it isn't the only way to have deadlocks.

A book I read on erlang had an entire chapter on how to avoid deadlocks with actors that had several examples of how you can get a deadlock with just message passing.

In fact, it is possible to implement a lock/mutex (also a semaphore) with actors and message passing.

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#259

Earlier 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…

You can absolutely have a pony program deadlock.

A simple example is if you get into a situation where two actors are both waiting for the other to send it a message.

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#260
post #212

Earlier quoted context omitted.

Speaking of fallacies, it's complete nonsense (not the only example of it from that source) to say that the comment in question was a True Scotsman Fallacy (or any other kind of fallacy). Saying that a certain kind of Scotsman puts sugar on his porridge is very different from saying that no true Scotsman puts sugar on his porridge.

Right, saying that only programmers who don't solve genuine problems and instead merely follow trends and treat it as fashion (and are thus no true scotsman) care about syntax, implying their opinion doesn't count, is definitely not a no true scotsman fallacy. It totally doesn't suggest that true scotsman heed the notion that syntax doesn't matter, and that so by definition, anyone else is just some goober following…

Only a certain kind of Hacker News would make this reply
Post reply on HN