chapel
ponyc
chapel | ponyc | |
---|---|---|
26 | 61 | |
1,741 | 5,602 | |
1.0% | 0.2% | |
10.0 | 9.2 | |
4 days ago | 5 days ago | |
Chapel | C | |
GNU General Public License v3.0 or later | BSD 2-clause "Simplified" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
chapel
-
Introduction to GPU Programming in Chapel
Thanks, @subharmonicon!
While Chapel can run on many different systems, the main goal is making HPC programming much easier. Therefore, we are currently focusing on hardware that you can find in HPC systems (NVIDIA, AMD and Intel). Metal doesn't fall into that category, unfortunately. So far, the name came up infrequently in our discussions IIRC (especially targetting SPIRV), but we haven't heard from any [potential] user who may be interested in it. I would encourage you or anybody else interested in it to create an issue asking for the feature: https://github.com/chapel-lang/chapel/issues/new. Seeing public interest in that direction can change our prioritization.
One thing that I wanted to add that's not in the blogpost is the "cpu-as-device" mode. With that mode, you can use any machine, even one without a GPU, to write applications using Chapel's GPU features. That mode is for those who want to do initial development/debugging on their personal laptops before putting their application on an HPC system. In other words, while you can't use Metal directly, you can still write GPU-enabled applications in your Mac using Chapel, if the end goal is to run it on an HPC system. More details on cpu-as-device: https://chapel-lang.org/docs/main/technotes/gpu.html#cpu-as-...
-
Mojo is now available on Mac
Agreed. Here is a serious contender[0] minus all the hype and the $100M in VC money. You would expect a minimum of interest given how Mojo is received by the community, but not really in practice.
[0]: https://chapel-lang.org/
- Chapel 1.32.0 Released
-
Rust vs. Julia in Scientific Computing
Cray is pushing their own language as well, Chapel.
https://chapel-lang.org/
As for Julia on Cray,
"Julia — The Newest Petaflop Family Language We Have Started to Love"
https://www.avenga.com/magazine/julia-programming-language
> Julia is one of the few languages that are in the so-called PetaFlop family; the other languages are C, C++ and Fortrant. It achieved 1.54 petaflops with 1.3 million threads on the Cray XC40 supercomputer.
-
What languages are we missing on devenv.sh?
https://chapel-lang.org if possible, Nix was also recently mentioned in Chapel Workshop https://chapel-lang.org/CHIUW2023.html https://github.com/twesterhout/nix-chapel
- Chapel: Programming Language for Parallel Computing
-
Getting Past “Ampersand-Driven Development” in Rust
See Val for a possible step into that direction.
https://www.val-lang.dev/
Or how the Chapel language for HPC is going at it,
https://chapel-lang.org/
-
Ask HN: How do I get the most benefit out of my programming language?
I suggest posting to a PLT focused resource, such as http://lambda-the-ultimate.org/
That said, a bit confused about the languages you reference in this context (Python, C#, JS) - didn't see any mention here or at your github repo of languages (some relatively ancient) in this space designed.
Sandia: Programming Languages for HPC [high performance computing] - is there life after MPI?
https://www.sandia.gov/app/uploads/sites/179/2022/04/SOS10-T...
Chapel:
https://chapel-lang.org/
https://en.wikipedia.org/wiki/Category:Array_programming_lan...
-
Twelve Days of Chapel: Advent of Code 2022
We needed the implicit conversion to `uint` in order for the overload resolution rules to make reasonable choices when faced with binary overloads for all of the numeric types. The document I linked talks through the examples. The case we were facing is something that we shared with `C#` -- in `C#` terms, if I make overloads for `f` for all numeric types (see https://github.com/chapel-lang/chapel/blob/main/test/types/coerce/allNumericsBinary.cs if you want to know exactly what I am talking about), then `f( myInt, myUlong )` runs `f(float, float)` which makes no sense. Especially if you care about numerical accuracy or program performance.
-
-🎄- 2022 Day 8 Solutions -🎄-
Code | Blog Walkthrough
ponyc
- Old Version
-
The problem with general purpose programming languages
For example, the actor's model is not used by a lot of languages, Pony (https://www.ponylang.io/) and Elixir are the only ones that I know, but they address the concurrency problem quite well, while it's a pain to deal with in other languages at large scale.
-
Found a language in development called Vale which claims to be the safest AOT compiled language in the World (Claims to beSafer than Rust)
And that last point is critical. If the language flatly can't represent some concepts it uses, they have to be implemented somewhere else. I had a similar discussion with a proponent for Pony once- the language itself is 100% safe, and fully dependent on C for its runtime and data structures. One of Rust's core strengths is being able to express unsafe concepts, meaning the unsafe code can expose a safe interface that accurately describes its requirements rather than an opaque C ABI. Vale doesn't seem to do that.
-
The Rust I wanted had no future
"Exterior iteration. Iteration used to be by stack / non-escaping coroutines, which we also called "interior" iteration, as opposed to "exterior" iteration by pointer-like things that live in variables you advance. Such coroutines are now finally supported by LLVM (they weren't at the time) and are actually a fairly old and reliable mechanism for a linking-friendly, not-having-to-inline-tons-of-library-code abstraction for iteration. They're in, like, BLISS and Modula-2 and such. Really normal thing to have, early Rust had them, and they got ripped out for a bunch of reasons that, again, mostly just form "an argument I lost" rather than anything I disagree with today. I wish Rust still had them. Maybe someday it will!"
I remember that one. The change was shortly after I started fooling with Rust and was major. Major as in it broke all the code that I'd written to that point.
"Async/await. I wanted a standard green-thread runtime with growable stacks -- essentially just "coroutines that escape, when you need them too"."
I remember that one, too; it was one of the things that drew me to the language---I was imagining something more like Pony (https://www.ponylang.io/).
"The Rust I Wanted probably had no future, or at least not one anywhere near as good as The Rust We Got."
Almost certainly true. But The Rust We Got is A Better C++, which was never appealing to me because I never liked C++ anyway.
-
How long until Rust becomes mandatory, and use of any other language opens the developer up to Reckless Endangerment charges
Pony or bust.
-
Universal parameter passing semantics
If you have a value in mutable storage, and want to treat it as an immutable parameter without copying it first, you will need to provide some way to guarantee that it won't be mutated while being treated as immutable! There doesn't seem to be a definitive best way to do that (although the likes of Pony make a try at it).
-
Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
The love child of Erlang and Rust exists already: Pony.
https://www.ponylang.io
It really is the best of both languages... unfortunately, the main supporter of Pony seems to have stopped using it in favour of Rust though :D.
But if that's really what you want, Pony is your language. It definitely deserves more love.
- Programming language rule
-
Why Turborepo is migrating from Go to Rust – Vercel
You can actually try to have a magic language which "does not ignore decades of PL research" but you are likely to get either something broken or a project that is likely not going to release in our lifetime.
-
Show HN: Ractor – a Rust-based actor framework with clusters and supervisors
Never a bad time to plug Pony lang[1] - a safety-oriented actor-model language. In addition to the numerous safety guarantees, you also get a beautiful syntax and automatic memory management. Really a great language that often gets overshadowed by Rust's hype-turfing.
[1]: https://www.ponylang.io/
What are some alternatives?
zls - A Zig language server supporting Zig developers with features like autocomplete and goto definition
gleam - ⭐️ A friendly language for building type-safe, scalable systems!
ATS-Postiats - ATS2: Unleashing the Potentials of Types and Templates
Halide - a language for fast, portable data-parallel computation
zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
prolog-to-minizinc - A Prolog-to-MiniZinc translator
hacktoberfest-swag-list - Multiple companies go above and beyond for Hacktoberfest, and this repo tries to list them all.
Phoenix - wxPython's Project Phoenix. A new implementation of wxPython, better, stronger, faster than he was before.
gsoc-organizations - A site for viewing and analyzing the info of the organizations participating in Google Summer of Code.
tab-rs - The intuitive, config-driven terminal multiplexer designed for software & systems engineers
jmurmel - A standalone or embeddable JVM based interpreter/ compiler for Murmel, a single-namespace Lisp dialect inspired by Common Lisp
Nim - Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).