4 ms·

People keep saying not to use this, and I think that's pretty wrong-headed. Sure, if you're going to do greenfield software development, and you don't absolute

People keep saying not to use this, and I think that's pretty wrong-headed. Sure, if you're going to do greenfield software development, and you don't absolutely need to kind of closeness to the metal (not just performance, but direct access) that C offers, then use something else (Rust, Zig, Go ... if you need to compile to native binaries, Java, C# & their myriad of variants if you don't). But if you have to use C, to extend an existing project, use a specific library, or hook some other system... why not use Cello? For sure, this is not a tight black-box abstraction, so you should strive to understand the semantics of how it works. Once you do though, it'll make your life a whole lot simpler.

girvo 5y ago
If you have to use C to extend an existing system, or hook into one, or leverage C code and so on, I found Nim to be brilliant. Because it is C once compiled. I’m using it right now at work to build our firmware for our custom embedded board. It’s been brilliant: ESP-IDF is all C (mostly, some C++ but it all has C interfaces too) and wrapping, extending, calling and integrating into those has been a breeze.
- monetus 5y ago
  Nim wrapped around a good library can feel liberating. I feel like using it and FFIs is too uncommon.
  - girvo 5y ago
    I always get a bit sad when a nice library I come across in the wild is C++, as FFI to C++ is so much more... fiddly, in all languages, compared to a C library. The latter is a breeze. In fact, today, I needed to be able to call the `esp_pthreads.h` functions (which describe some ESP32-specific extensions to it's pthread layer) and it took me, no joke, 5 minutes to wrap. Pass the header through c2nim, add `{.importc, header: "esp_pthreads.h".}` pragmas to the proc definition, and done. Now I can call them without issue. Its liberating for sure! That said, you can even wrap C++ if need be, though it's less elegant at times.
user-the-name 5y ago
Tozen 5y ago
It's a great concept, but languages like Rust (https://www.rust-lang.org/ https://www.rust-lang.org/), Zig (https://ziglang.org https://ziglang.org), Vlang (https://vlang.io/ https://vlang.io/), etc... are already running with a similar idea to being easy to interact with C and are viable alternatives to it as well. Vlang even created its own OS, Vinix (https://github.com/vlang/vinix https://github.com/vlang/vinix), to show its capabilities in this regard. Seems to me, Cello would be more for those C programmers that didn't want to try the various alternative languages that are now out, and happen to agree with its developer's interpretation of preferred higher level abstractions and what they should look like. The point of these alternative languages is to offer features that C doesn't have or to implement them in easier or clearer ways.
- norswap 5y ago
  This is a good point, and definitely worth considering. I would however weigh the benefits of these languages with the cost of complexifying the toolchain, adding another language into the mix, & future maintainability (I'm pretty sure I can still run `make` on the C codebase in 10 years. I'm not so sure about these others.)

girvo 5y ago

If you have to use C to extend an existing system, or hook into one, or leverage C code and so on, I found Nim to be brilliant. Because it is C once compiled. I’m using it right now at work to build our firmware for our custom embedded board. It’s been brilliant: ESP-IDF is all C (mostly, some C++ but it all has C interfaces too) and wrapping, extending, calling and integrating into those has been a breeze.

monetus 5y ago
Nim wrapped around a good library can feel liberating. I feel like using it and FFIs is too uncommon.
- girvo 5y ago
  I always get a bit sad when a nice library I come across in the wild is C++, as FFI to C++ is so much more... fiddly, in all languages, compared to a C library. The latter is a breeze. In fact, today, I needed to be able to call the `esp_pthreads.h` functions (which describe some ESP32-specific extensions to it's pthread layer) and it took me, no joke, 5 minutes to wrap. Pass the header through c2nim, add `{.importc, header: "esp_pthreads.h".}` pragmas to the proc definition, and done. Now I can call them without issue. Its liberating for sure! That said, you can even wrap C++ if need be, though it's less elegant at times.

user-the-name 5y ago

Tozen 5y ago

It's a great concept, but languages like Rust (https://www.rust-lang.org/ https://www.rust-lang.org/), Zig (https://ziglang.org https://ziglang.org), Vlang (https://vlang.io/ https://vlang.io/), etc... are already running with a similar idea to being easy to interact with C and are viable alternatives to it as well. Vlang even created its own OS, Vinix (https://github.com/vlang/vinix https://github.com/vlang/vinix), to show its capabilities in this regard. Seems to me, Cello would be more for those C programmers that didn't want to try the various alternative languages that are now out, and happen to agree with its developer's interpretation of preferred higher level abstractions and what they should look like. The point of these alternative languages is to offer features that C doesn't have or to implement them in easier or clearer ways.

norswap 5y ago
This is a good point, and definitely worth considering. I would however weigh the benefits of these languages with the cost of complexifying the toolchain, adding another language into the mix, & future maintainability (I'm pretty sure I can still run `make` on the C codebase in 10 years. I'm not so sure about these others.)