claro-lang
rfcs
claro-lang | rfcs | |
---|---|---|
9 | 666 | |
139 | 5,711 | |
- | 0.9% | |
9.5 | 9.8 | |
29 days ago | 2 days ago | |
Java | Markdown | |
- | Apache License 2.0 |
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.
claro-lang
-
The Claro Programming Language
Interesting, although it seems to currently be missing a license. While Bazel and I are for sure not friends, I found this funny https://github.com/JasonSteving99/claro-lang/blob/v0.1.495/W... I guess it's similar to having a maven build under Nix but my relationship to Bazel is why I got a chuckle out of the russian doll setup
-
Charm 0.3.9 --- now with "Hello world!"
Oh wow, it looks like we've stumbled upon the same construct! In my language, Claro, what you call "interfaces" are called "contracts". I've found it to be a very powerful abstraction!
-
Keyword Generics Progress Report: February 2023 | Inside Rust Blog
In fact, you've actually been a huge source of inspiration for building keyword-generics into the programming language I've been working on in private for the past 2 years! The language is called "Claro" and if you're interested, please take a look at the blocking-generics syntax that your initiative has inspired.
-
What are you doing about async programming models? Best? Worst? Strengths? Weaknesses?
I've tried to do something unique in my lang, Claro. To avoid spamming my same comment again, check out my answer to a very similar thread yesterday
-
Claro's Structured Async+Concurrency Provides Static Non-Blocking Validation and Implements Rust's Keyword Generics Initiative
Didn't see the Github link (but having all the info here is certainly appreciated)
-
What modules should implicitly be imported in a language?
Hmm, so I still feel that C3's imports actually are binding to a specific implementation like other imports (Java/C/python/etc). I think a language would need to embed dependency injection concepts deep into its veins to avoid this. You'd need a way for implementation files to specify that they depend on something with a certain name and a certain interface but not to name the specific implementation. Then a separate parallel module system (more like a Guice (dep injection framework) module than the modules in C3) would indicate the specific implementation that happens to be desired this run of the program. This is the inherent modularity that I'm looking to implement in Claro. There's some prototyping of this idea in the example programs at https://github.com/JasonSteving99/claro-lang/blob/main/src/java/com/claro/claro_programs/modules.claro
-
Let's talk function declarations!
In Claro I'm trying the following distinct types of procedures:
rfcs
-
Ask HN: What April Fools jokes have you noticed this year?
RFC: Add large language models to Rust
https://github.com/rust-lang/rfcs/pull/3603
- Rust to add large language models to the standard library
-
Why does Rust choose not to provide `for` comprehensions?
Man, SO and family has really gone downhill. That top answer is absolutely terrible. In fact, if you care, you can literally look at the RFC discussion here to see the actual debate: https://github.com/rust-lang/rfcs/pull/582
Basically, `for x in y` is kind of redundant, already sorta-kinda supported by itertools, and there's also a ton of macros that sorta-kinda do it already. It would just be language bloat at this point.
Literally has nothing to do with memory management.
- Coroutines in C
-
Uv: Python Packaging in Rust
Congrats!
> Similarly, uv does not yet generate a platform-agnostic lockfile. This matches pip-tools, but differs from Poetry and PDM, making uv a better fit for projects built around the pip and pip-tools workflows.
Do you expect to make the higher level workflow independent of requirements.txt / support a platform-agnostic lockfile? Being attached to Rye makes me think "no".
Without being platform agnostic, to me this is dead-on-arrival and unable to meet the "Cargo for Python" aim.
> uv supports alternate resolution strategies. By default, uv follows the standard Python dependency resolution strategy of preferring the latest compatible version of each package. But by passing --resolution=lowest, library authors can test their packages against the lowest-compatible version of their dependencies. (This is similar to Go's Minimal version selection.)
> uv allows for resolutions against arbitrary target Python versions. While pip and pip-tools always resolve against the currently-installed Python version (generating, e.g., a Python 3.12-compatible resolution when running under Python 3.12), uv accepts a --python-version parameter, enabling you to generate, e.g., Python 3.7-compatible resolutions even when running under newer versions.
This is great to see though!
I can understand it being a flag on these lower level, directly invoked dependency resolution operations.
While you aren't onto the higher level operations yet, I think it'd be useful to see if there is any cross-ecosystem learning we can do for my MSRV RFC: https://github.com/rust-lang/rfcs/pull/3537
How are you handling pre-releases in you resolution? Unsure how much of that is specified in PEPs. Its something that Cargo is weak in today but we're slowly improving.
- RFC: Rust Has Provenance
-
The bane of my existence: Supporting both async and sync code in Rust
In the early days of Rust there was a debate about whether to support "green threads" and in doing that require runtime support. It was actually implemented and included for a time but it creates problems when trying to do library or embedded code. At the time Go for example chose to go that route, and it was both nice (goroutines are nice to write and well supported) and expensive (effectively requires GC etc). I don't remember the details but there is a Rust RFC from when they removed green threads:
https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b...
-
Why stdout is faster than stderr?
I did some more digging. By RFC 899, I believe Alex Crichton meant PR 899 in this repo:
https://github.com/rust-lang/rfcs/pull/899
Still, no real discussion of why unbuffered stderr.
- Go: What We Got Right, What We Got Wrong
-
Ask HN: What's the fastest programming language with a large standard library?
Rust has had a stable SIMD vector API[1] for a long time. But, it's architecture specific. The portable API[2] isn't stable yet, but you probably can't use the portable API for some of the more exotic uses of SIMD anyway. Indeed, that's true in .NET's case too[3].
Rust does all this SIMD too. It just isn't in the standard library. But the regex crate does it. Indeed, this is where .NET got its SIMD approach for multiple substring search from in the first place[4]. ;-)
You're right that Rust's standard library is conservatively vectorized though[5]. The main thing blocking this isn't the lack of SIMD availability. It's more about how the standard library is internally structured, and the fact that things like substring search are not actually defined in `std` directly, but rather, in `core`. There are plans to fix this[6].
[1]: https://doc.rust-lang.org/std/arch/index.html
[2]: https://doc.rust-lang.org/std/simd/index.html
[3]: https://github.com/dotnet/runtime/blob/72fae0073b35a404f03c3...
[4]: https://github.com/dotnet/runtime/pull/88394#issuecomment-16...
[5]: https://github.com/BurntSushi/memchr#why-is-the-standard-lib...
[6]: https://github.com/rust-lang/rfcs/pull/3469
What are some alternatives?
xvm - Ecstasy and XVM
rust - Empowering everyone to build reliable and efficient software.
Hungaro - A syntax based programming language
bubblewrap - Low-level unprivileged sandboxing tool used by Flatpak and similar projects
keyword-generics-initiative - Public repository for the Rust keyword generics initiative
crates.io - The Rust package registry
AECforWebAssembly - A port of ArithmeticExpressionCompiler from x86 to WebAssembly, so that the programs written in the language can run in a browser. The compiler has been rewritten from JavaScript into C++.
polonius - Defines the Rust borrow checker.
Rust-for-Linux - Adding support for the Rust language to the Linux kernel.
rust-gc - Simple tracing (mark and sweep) garbage collector for Rust
zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
rust-analyzer - A Rust compiler front-end for IDEs [Moved to: https://github.com/rust-lang/rust-analyzer]