retro-httpaf-bench
zig
retro-httpaf-bench | zig | |
---|---|---|
6 | 818 | |
21 | 31,086 | |
- | 4.1% | |
0.0 | 10.0 | |
3 months ago | 7 days ago | |
Jupyter Notebook | Zig | |
- | MIT 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.
retro-httpaf-bench
- Parser Combinators in Haskell
-
Ask HN: Alternatives to Rust Programming Language
I do. The benchmark results itself is here: https://aws1.discourse-cdn.com/standard11/uploads/ocaml/opti.... This comes from the OCaml multicore monthly news, the october 2021 edition: https://discuss.ocaml.org/t/multicore-ocaml-october-2021/882.... The benchmark's repo is here: https://github.com/ocaml-multicore/retro-httpaf-bench. However that image is not the whole story, and there's a bit more info here: https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5.... In that video, the author says that the result vary depending on the load (sometimes Rust Hyper can end up above OCaml httpaf eio), that OCaml currently uses an io-uring backend while Rust doesn't, and that the results are for single core as previous OCaml implementations are single-core themselves.
I do feel that this benchmark is incomplete. I'd like it to see the results while using all of the cores of a machine, and I'd like to see different type of loads. I do think that the results are impressive: performance between Go and Rust is great. I do hope that it stays this way with multicore.
-
Adapting the OCaml Ecosystem for Multicore OCaml
We don't compare against Go pervasively. Benchmarking across languages is hard generally, but here is a result on a specific benchmark comparing several versions of OCaml benchmarks against Go and Rust on a Http server benchmark: https://github.com/ocaml-multicore/retro-httpaf-bench/pull/1....
If there are suggestions to make the Go and Rust versions, please feel free to tell us how in the issue tracker.
-
I don't see a future for Go. It's big within the kubernetes world right now but it will slowly be replaced by Rust.
multicore already faster than Go
-
Functional Programming in OCaml
Multicore is coming along, you can read the latest news here: https://discuss.ocaml.org/t/multicore-ocaml-june-2021/8134
In terms of performance, there is this paper https://kcsrk.info/papers/system_effects_feb_18.pdf where on a single core async OCaml and effect OCaml are close to Go's net/http, and there is also this project https://github.com/ocaml-multicore/retro-httpaf-bench but I haven't see any results from it.
zig
-
Show HN: I made a better Perplexity for developers
It's "Zig" not "Zag". https://ziglang.org/ Zig is under heavy development, but there's a single page https://ziglang.org/documentation/0.12.0/ that is a reasonably comprehensive source of truth about the current state of the language.
- The search for easier safe systems programming
-
Memory-mapped IO registers in Zig. (2021)
There is an issue proposing this approach: https://github.com/ziglang/zig/issues/4284
- Zig Programming Language
- Zig Language 0.12 Release
-
Zig 0.12.0 Release Notes
https://github.com/ziglang/zig/issues/224
e.g.:
> > When debugging/prototyping, it's useful to comment out a line without having to refactor, e.g.
-
How to Write a PHP Extension with Zig?
When writing code in a scripting language, sometimes you need that extra bit of performance (or maybe an async feature from Zig).
-
Bun - The One Tool for All Your JavaScript/Typescript Project's Needs?
NodeJS is by no means a slow runtime, it wouldn’t be so popular if it was. But compared to Bun, it’s slow. Bun was built from the ground up with speed in mind, using both JavascriptCore and Zig. The Bun team spent an enormous amount of time and energy trying to make Bun fast, including lots of profiling, benchmarking, and optimizations.
-
Bun 1.1
ntdll.dll!RtlUserThreadStart()
There are valid reasons to use APIs from NTDLL. Where I disagree with zig#1840 is the idea that it is always better to use NTDLL versions of API. Every other software ecosystem uses the standard Win32 APIs and diverging from that without a good reason seems like a good way to have unexpected behavior. One concrete example is most users and programmers expect Windows to redirect some file system paths when running on WOW64. But this is implemented in Kernel32, not ntdll.
https://github.com/ziglang/zig/issues/11894
- Zig, Rust, and Other Languages
What are some alternatives?
assert-combinators - Functional assertion combinators.
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).
codeworld - Educational computer programming environment using Haskell
Odin - Odin Programming Language
parser - String parser combinators
v - Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. Supports automatic C => V translation. https://vlang.io
ocaml-h2 - An HTTP/2 implementation written in pure OCaml
rust - Empowering everyone to build reliable and efficient software.
angstrom - Parser combinators built for speed and memory efficiency
go - The Go programming language
dune - A composable build system for OCaml.
ssr-proxy-js - A Server-Side Rendering Proxy focused on customization and flexibility!