So crystal and nim are the new Flavor Oft he Month ? Got it.
Crystal 0.24.1 released
11–20 of 25 posts
Re: Crystal 0.24.1 released
#12I feel like Crystal has been alpha for 4 years.
That may be, but it's really quite stable for pre-1.0. I have Crystal apps running in production without problems and great success. I'd say, in some scenarios, Crystal is more stable in alpha than some post-alpha language releases I've worked with in the past.
Re: Crystal 0.24.1 released
#13I 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 t…
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.
Re: Crystal 0.24.1 released
#14I 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 t…
> 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.
Re: Crystal 0.24.1 released
#15I 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 t…
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 :)
Re: Crystal 0.24.1 released
#16I 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 t…
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 Erla…
That is hilarious
Re: Crystal 0.24.1 released
#17I 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 t…
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 s…
maybe the green thread thing doesn't bother you because you are a seasoned system dev?
Re: Crystal 0.24.1 released
#18I 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 t…
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 s…
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
Re: Crystal 0.24.1 released
#19I 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 t…
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.
Re: Crystal 0.24.1 released
#20Earlier quoted context omitted.
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 s…
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…
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.