koka
Rust-for-Linux
Our great sponsors
koka | Rust-for-Linux | |
---|---|---|
31 | 79 | |
3,017 | 3,769 | |
2.5% | 1.9% | |
9.8 | 0.0 | |
8 days ago | 3 days ago | |
Haskell | C | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
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.
koka
-
What features would you want in a new programming language?
It also offers a great Inversion of Control mechanism where everything is customisable, and, unlike Capability Objects, AESs also offer compatibility with type inference (you can pass functions doing IO to map, and it Just Works(TM)) and first-class control over stack frames (because really a continuation function is just some stack frames, which you can manually move to the heap if you want a closure; which means async is an effect!). It also is composable in ways Monads are not.
-
What are you doing about async programming models? Best? Worst? Strengths? Weaknesses?
Koka and other languages implementing Algebraic Effect Systems make everything a user-defined case of coroutines: async is just another effect/Monadic type. Zig does something similar by having first class stack frames, making all function calls possibly asynchronous.
-
Letlang, a programming language targetting Rust - Road to v0.1
Super interesting, there is a proposal to add this to JavaScript and several languages that use this, unison, koka & eff. I had no idea this was even a thing!
-
Let's collect relatively new research programming languages in this thread
https://github.com/koka-lang/koka Algebraic effects and reference counting. https://github.com/mit-plv/koika hardware description DSL for coq
Koka, already cited in this thread, early 2010s. Koka's first claim to fame was a usable effect system (at the type were, basically, effect systems were not usable in practice; in fact few languages have managed to do as well as Koka since). Now its author is working on cool implementation strategies for functional languages as well.
-
[Offer] Tutoring for Computer Science / Programming / Software Engineering topics
I'm a software engineer with 3 years of professional experience. I worked for 2 years at Microsoft on Azure Compute and now work at Google, working on improving Google search. I am the sole maintainer of the popular open-source library microlens with 80k downloads. I've also contributed to the Koka programming language developed at Microsoft Research.
-
Implementing the Perceus reference counting GC
By implementing all of those optimizations in the Koka programming language, they achieved GC overhead much less and execution time faster than the other languages including OCaml, Haskell, and even C++ in several algorithms and data structures that frequently keep common sub-structures of them, such as red-black trees. For more information, see the latest version of the paper.
-
Creator of SerenityOS announces new Jakt programming language effort
5) https://github.com/koka-lang/koka
-
Structurally-Typed Condition Handling
Yes -- I think historically the power of condition handling was not well understood and algebraic effect handlers were a "rediscovery" coming from well-studied category theory (Plotkin, Power, and Pretnar).
If you want to play with "structurally typed condition handling", then the Koka language has "row-typed algebraic effect handlers" that compile to C: <http://koka-lang.org>
Rust-for-Linux
-
The Linux Kernel Prepares for Rust 1.77 Upgrade
At least according to the Github's language breakdown for https://github.com/Rust-for-Linux/linux, C is still 98.3% of the repository, and Rust is in the 0.1% of "others".
Rust is backwards compatible when you stick to stable features, but the kernel uses unstable features that can and do incur breaking changes.
-
Mark Russinovich: “Working towards enabling Windows driver development in Rust”
> How would this work?
Don't know exactly what you're asking.
> And why would it be a better idea?
Poorly written device drivers are a significant attack vector. It's one of the reasons Linux is now exploring using Rust for its own device drivers.[0] You may be asking -- why Rust and not some other language? Rust has many of the performance and interoperability advantages of C and C++, but as noted, makes certain classes of memory safety issues impossible. Rust also has significant mindshare among systems programming communities.
-
The Linux Kernel Module Programming Guide
Ctrl-F "rust"
https://rust-for-linux.com/ links to LWN articles at https://lwn.net/Kernel/Index/#Development_tools-Rust that suggest that only basic modules are yet possible with the rust support in Linux kernels 6.2 and 6.3.
Rust-for-linux links to the Android binder module though:
> Android Binder Driver: This project is an effort to rewrite Android's Binder kernel driver in Rust.
> Motivation: Binder is one of the most security and performance critical components of Android. Android isolates apps from each other and the system by assigning each app a unique user ID (UID). This is called "application sandboxing", and is a fundamental tenet of the Android Platform Security Model.
> The majority of inter-process communication (IPC) on Android goes through Binder. Thus, memory unsafety vulnerabilities are especially critical when they happen in the Binder driver
... "Rust in the Linux kernel" (2021) https://security.googleblog.com/2021/04/rust-in-linux-kernel... :
> [...] We also need designs that allow code in the two languages to interact with each other: we're particularly interested in safe, zero-cost abstractions that allow Rust code to use kernel functionality written in C, and how to implement functionality in idiomatic Rust that can be called seamlessly from the C portions of the kernel.
> Since Rust is a new language for the kernel, we also have the opportunity to enforce best practices in terms of documentation and uniformity. For example, we have specific machine-checked requirements around the usage of unsafe code: for every unsafe function, the developer must document the requirements that need to be satisfied by callers to ensure that its usage is safe; additionally, for every call to unsafe functions (or usage of unsafe constructs like dereferencing a raw pointer), the developer must document the justification for why it is safe to do so.
> We'll now show how such a driver would be implemented in Rust, contrasting it with a C implementation. [...]
This guide with unsafe rust that calls into the C, and then with next gen much safer rust right next to it would be a helpful resource too.
What of the post-docker container support (with userspaces also written in go) should be cloned to rust first?
-
The state of Flatpak security: major Projects are the worst?
Rust-for-Linux issue tracker
- rust devs in a nutshell
-
Rustproofing Linux (Part 1/4 Leaking Addresses)
Also, there already exists both issue: https://github.com/Rust-for-Linux/linux/issues/479
Yes, I definitely agree that it's a problem that pr_info implicitly wraps its arguments in unsafe {}. I wrote my own Pull Request with a trival fix.
-
how to compile a rust "hello world" with kernel 6.1?
Note that this template won't work with Linux 6.1, which has very minimal Rust support. You'll want the RustForLinux tree, or maybe Linux 6.2.
-
Rust in the 6.2 Kernel
> Also we’re bringing NPM style supply chain problems to the kernel now?
Nope. They've thought that through.
(In fact, cargo is only used to build test helpers. https://github.com/Rust-for-Linux/linux/blob/rust/Documentat...)
What are some alternatives?
effekt - A research language with effect handlers and lightweight effect polymorphism
rust - Empowering everyone to build reliable and efficient software.
wasm-effect-handlers - WebAssembly specification, reference interpreter, and test suite with effect handlers extension.
FStar - A Proof-oriented Programming Language
jakt - The Jakt Programming Language
gccrs - GCC Front-End for Rust
dafny - Dafny is a verification-aware programming language
rfcs - RFCs for changes to Rust
rustig - A tool to detect code paths leading to Rust's panic handler
zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
PrawnOS - Libre Mainline Kernel and Debian for arm laptops