SaaSHub helps you find the best software and product alternatives Learn more →
BUSY Alternatives
Similar projects and alternatives to BUSY
-
oils
Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!
-
InfluxDB
InfluxDB high-performance time series database. Collect, organize, and act on massive volumes of high-resolution data to power real-time intelligent systems.
-
-
-
coalton
Coalton is an efficient, statically typed functional programming language that supercharges Common Lisp.
-
Oberon
Oberon parser, code model & browser, compiler and IDE with debugger, and an implementation of the Oberon+ programming language
-
-
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
LeanQt
LeanQt is a stripped-down Qt version easy to build from source and to integrate with an application.
-
-
-
clace
App deployment simplified. GitOps without the hassles. Application server for deploying internal tools for teams.
-
-
-
tidesdb
High-performance durable, transactional embedded storage engine designed for flash and RAM optimization.
-
-
-
-
-
starlarky
VGS edition of Google's safe and hermetically sealed Starlark language - a non-Turing complete subset of Python 3.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
NOTE:
The number of mentions on this list indicates mentions on common posts plus user suggested alternatives.
Hence, a higher number means a better BUSY alternative or higher similarity.
BUSY discussion
BUSY reviews and mentions
Posts with mentions or reviews of BUSY.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2025-03-21.
-
Show HN: A Database Written in C
I don't want to burden you with work, so don't feel obliged in any way. This is simply my opinion (there are also good reasons for newer C versions). In all my projects, I don't have any newer versions than C99 or C++11 (most are even C++98/03). I recently even migrated a compiler backend framework from C++17 to C++11 to use it: https://github.com/rochus-keller/eigen/. I could do the same with your code if I would use it, but first I have to move forward in other projects.
Concerning cmake: I only use it if unavoidable; instead I implemented my own build system (https://github.com/rochus-keller/busy/) some years ago which I now use for most of my projects.
-
Starlark Programming Language
> a large Starlark codebase is a large Python codebase, and large Python codebases are imperative, untyped, and can get messy even without all the things mentioned above. Even though your Starlark is pure and deterministic, it still easily ends up a rats nest of sphagetti
This brings it to the point. I'm still wondering why the achievements of software engineering of the past fifty years, like modularization, structured and object-oriented programming, and static type checking had apparently so little influence on build systems. I implemented https://github.com/rochus-keller/BUSY for this reason, but it seems to require a greater cultural shift than most developers are already willing to make.
-
Xz Backdoor and Autotools Insanity
CMake - as autotools - is a meta build system; it e.g. generates make files, which are essentially scripts. Also CMake itself is essentially a VM with a scripting language. Both CMake and Make are Turing complete (and dynamically typed, as mentioned). And yes, not all build systems are the same; e.g. https://github.com/rochus-keller/BUSY has a statically typed specification language and intentionally avoids a Turing complete language.
-
New build system for C/C++
> Have you coded the lexer/parser from scratch
Yes. Here is the lexer: https://github.com/rochus-keller/BUSY/blob/main/bslex.c
and here is the parser: https://github.com/rochus-keller/BUSY/blob/main/bsparser.c
and here is the specification: http://software.rochus-keller.ch/busy_spec.html
I also developed and checked the EBNF in parallel using my EbnfStudio tool; this tool could also generate a parser, but since I'm using much of the Lua VM infrastructure a manual parser implementation was more straight-forward .
- What should be used to build the CPython of tomorrow?
- A simple shell based build tool for C/C++
-
Knit: Making a Better Make
If you haven't seen it: https://github.com/rochus-keller/BUSY
> BUSY is a lean, statically typed, cross-platform, easily bootstrappable build system for GCC, CLANG and MSVC inspired by Google GN
It uses lua and config files that are mostly directories and filenames.
-
Using Qt 6 under LGPLv3
> Instead of qmake the BUSY build system (see https://github.com/rochus-keller/BUSY) is used
It must be a rite of passage to make(!) one's own build system, damn
- BUSY lean build system with new Qmake backend
- Show HN: Busy build system now has a Qmake back end
-
A note from our sponsor - SaaSHub
www.saashub.com | 25 Apr 2025
Stats
Basic BUSY repo stats
26
86
3.7
almost 2 years ago
rochus-keller/BUSY is an open source project licensed under GNU General Public License v3.0 only which is an OSI approved license.
The primary programming language of BUSY is C.
Sponsored
InfluxDB high-performance time series database
Collect, organize, and act on massive volumes of high-resolution data to power real-time intelligent systems.
influxdata.com