Naming is hard, but please, do not repeat the mistake of many OSS project in the last 20 years calling each project by prefixing the name with the stack/environment involved.

Now a "trending" language can catch the attention, but tomorrow?.. maybe. So the value proposition and starting from it name should be different (if you want adoption).

For my use case, for a rewrite of jq I would expect one thing only: higher performance... show the numbers ;)

I'd also expect higher performance for a rewrite of jq or, for that matter, any other tool that works as expected and being used for a long time.

Last time I profiled jq in my particular use case - querying large GeoJSON files - I discovered it spent practically all of its CPU in assert, and it went a lot faster when built with -DNDEBUG, but since I could not rule out that some of its asserts have side effects I went back to the upstream package.

I think beating the performance of jq would be very easy for anyone who set out with that as a goal. It also has its own internal strtod and dtoa which are easily beaten by ryu or C++'s from/to_chars, so I would start there after dumping the weird asserts.

Calyptia Inc.| Senior Frontend Engineer - Lead| REMOTE | Full Time

Calyptia is an open-source company that focuses on solving Observability challenges for cloud environments. We are the creators and maintainers of Open Source projects Fluentd and Fluent Bit, which are all about observability (logs, metrics & traces).

We are looking for an experienced Frontend developer that has been a tech-lead before with strong skills in architecture design, TypeScript, React, GraphQL, Git and API services,

We look for a proactive candidate with strong communication skills and able to work in a distributed team.

If you are interested, drop me a message to eduardo at calyptia dot com

First of all congratulations to Valgrind and the team behind it! This is an essential tool that help me personally over the years while developing.

What needs to be done to get Valgrind binaries available for MacOS (M1) ?, from a company perspective we are happy to support this work. If you know who's interest and can accomplish this pls drop me an email to eduardo at calyptia dot com.

ah!

[ERROR ] GitHub rate limit exceeded! If you have not done so already,

[ERROR ] you can tell kraft to use a personal access token when contacting

[ERROR ] the GitHub API. First, visit:

Hi @edsiper2, if you are running into any problems I'm happy to help, we can chat directly on the Unikraft Discord server: https://bit.ly/UnikraftDiscord

Calyptia | REMOTE | Full-time | https://calyptia.com

Calyptia is the company primary funding the OSS projects Fluent Bit[0] and Fluentd[1], CNCF graduated projects.

We are looking for talented individuals with outstanding discipline to work on solving challenges associated with data processing and scalability. We are looking for candidates for the following teams:

- Backend & Ops: Golang, Kubernetes, CI/CD

- Frontend: Javascript, Typescript (mandatory), React

- Fluent Bit OSS: C, Linux and familiar with networking, event loop, syscalls, protocols, etc.

Feel free to send me your github profile or resume to eduardo at calyptia dot com.

[0] https://fluentbit.io

[1] https://www.fluentd.org

my 5c about your intro: I see you can handle a bunch of technologies but your primary focus and interest in the last time has been on Rust. You might promote yourself as a Rust Developer instead of mentioning all the other tech, so you can get easily filtered for the right job.

msgpack users:

- Fluentd & Fluent Bit

- Microsoft SignalR https://docs.microsoft.com/en-us/aspnet/core/signalr/message...

the following as a 5 min intro video to one of the techniques :

- https://www.youtube.com/watch?v=FP-dNd1xTcs

if you want to learn more: https://yogananda.org/practice

Lua is just great. In Fluent Bit[0] we expose Lua filter capabilities. So end-users can write their own scripts to manipulate record logs and accommodate keys/values easily with a simple programming logic:

- https://docs.fluentbit.io/manual/pipeline/filters/lua

I am happy to see performance is being improved, as of now we stick to LuaJIT, since our use case is pretty simple we have not found a good reason to move away from it.

[0] https://fluentbit.io