[skrebbel]

I really like initiatives like Crystal and Nim, in that they appeal to users of popular languages like Ruby and Python yet are much faster.

But I fear that the problem they solve isn't big enough. For desktop/mobile apps, they need a UI framework so I suppose they're targeted at web or network/system programming mostly. However, "Faster Ruby" or "Faster Python" is, in practice, solved by faster hardware as well. At the same time, for web apps to truly scale you need more than just a constant factor increase in speed - you need to handle parallelism better. This is what Go and Erlang/Elixir do with green threads, or Rust with its borrow checker.

This is why I've been surprised that a well thought out and polished initiative like Crystal doesn't do anything in this area, and makes me fear that its popularity might not last. Nim was all over HN a few years ago and now not seen that much anymore - Crystal is obviously different from Nim but they tackle many of the same problems in similar enough ways.

I fear/hope that, because of this, languages like Pony[0] will stick around longer - it seems to combine the best ideas from Crystal, Erlang and Rust in an ergonomic way.

[0] https://playground.ponylang.org/

[chubot]

Yes, I believe it is folly to try to build a "general purpose" language these days. It's just too much work to clear the bar for adoption (i.e. what do you offer that C/C++/Java/C#/Python/Ruby/JS don't). A language could be great in many ways, but as you say, you have to be able to solve problems you can't solve otherwise with it.

It seems like most newer languages that see some adoption have a solid niche, like Erlang/Elixir, Julia, or Elm.

A friendly reminder I posted over on reddit :)

http://colinm.org/language_checklist.html

[djsumdog]

That is hilarious

[dom96]

Disclaimer: I'm a core Nim dev.

To be honest I am unsure what Pony provides that Nim doesn't. Perhaps I just haven't looked closely enough at it.

One thing I do know is that from my years of using Nim I never had any trouble with parallelism. There are no green threads, but there is a solid thread pool implementation[1] and a mechanism that ensures memory isn't shared between threads without a lock or a channel (GC safety)[2].

Maybe you could give me a TL;DR of what Pony does better? :)

1 - https://nim-lang.org/docs/threadpool.html

2 - https://nim-lang.org/docs/manual.html#threads-gc-safety

[jitl]

Pony has an Actor as a language-level concept, which significantly reduces the amount of “thinking about mechanism” that a programmer needs to do to build safe, highly-concurrent programs.

Quick read: https://tutorial.ponylang.org/types/actors.html

I think one could implement a similar system in Nim using the primitives that you posted, plus some kind of channel, but:

1. Such a system is not included in the standard library (?)

2. Even if a package containing such a system outside the stdlib were available, it would not receive the same application and usage by the Nim community, as Pony actors will in the Pony community

3. So, Pony is better suited to foster a community for highly concurrent programming

[djsumdog]

Does an actor system need to be part of the language? In the Scala world, there's the akka library to provide actors (but of course you could use a totally different actor system instead). Alternatively in Elixir, actors (Processes) with their send/receive functionality is built into the language and each module can essentially be an actor.

I guess the trade off is that if it's a part of the language, you get it standard and built in as a language construct. But if it's in an external library, you can use different actor systems and benchmark them accordingly.

[abiox]

one benefit is that you can effectively embed the concept directly into the type system, allowing for ergonomic expression of actor model code. i'm not sure to what extent pony does this, though i believe it's capability typing was designed with actors in mind.

[k__]

maybe the green thread thing doesn't bother you because you are a seasoned system dev?

[coldtea]

>However, "Faster Ruby" or "Faster Python" is, in practice, solved by faster hardware as well.

That ship has sailed years ago.

[bpicolo]

I've played around with pony - ergonomic is not the way I would describe it. The heavy use of actors in the core lib is a powerful abstraction for concurrent systems, but it's a pain, structurally, compared to non-actor systems.

[girvo]

To be fair, the Nim community agrees with your assessment. Quite a lot of development is going into the nimx library for that reason!

[yxhuvud]

> For desktop/mobile apps, they need a UI framework

I don't know about the mobile story, but there are Qt bindings for crystal.

As for parallelism, it is not done but it is in the works, so it is not ignored, it just is hard enough that it isn't possible to just wish for it and it appears. The concurrency story is already pretty strong though.

[jksmith]

>>For desktop/mobile apps, they need a UI framework

Then use FreePascal/Lazarus for your client. Don't know about the state of the mobile libs, but Delphi/FP perfected desktop UI development a long time ago. Decouple backend into whatever you want so you have an asset that is UI agnostic.

[Can_Not]

Can you add an entry for pony to https://learnxinyminutes.com/ ?

Make a PR here: https://github.com/adambard/learnxinyminutes-docs

[holydude]

Parallelism and a UI framework are such a big undertakings that it simply takes a lot of time to get them working. Hell we are stuck with Electron because there simply is not a proper alternative. For parallelism Crystal plans to do it the Go way.