4 ms·

I think this may be exactly what I've been looking for. I've been wanting a "Better C" type of language, but all the existing candidates fall down on some poin

I think this may be exactly what I've been looking for. I've been wanting a "Better C" type of language, but all the existing candidates fall down on some point like - too complicated (Rust/D/C++), no manual memory management (Go), etc. I've even made some half baked attempts at writing my own language. It seems that the design goals of this language are exactly what I'm after. Going to have to give it a try later.

ionforce 8y ago
What part(s) of Rust do you find too complicated, and why?
- oregontechninja 8y ago
  One place they're thinking of might be integration with C. zig's C integration is crazy good from what I can tell toying around with it. It was as easy as @cImport({@cInclude("header.h")}) The language is also evolving rapidly, this may have changed, but if it did, it probably changed for the better.
- pseudonymcoward 8y ago
  In general I prefer languages to be small and simple - like Go and C. This doesn't seem to be a design goal for Rust, which puts me off. Some specifics: Trying to do anything non-trivial with ownership/lifetimes/borrowing always ends up in a tangle, fighting with the compiler. Everything in the stdlib seems to have a giant api with pages and pages of functions. Example: https://doc.rust-lang.org/std/string/struct.String.html https://doc.rust-lang.org/std/string/struct.String.html Scrolling down through those methods is overwhelming. The overhead imposed by the goal of maximising safety is big, and not that important to me (as I'm not writing Very Important Crypto code or whatever, I don't find it hard to write good enough code for my purposes in C).
  - deleted 8y ago
    [deleted]
  - julienfr112 8y ago
    Why not Ctrl-F instead of scrolling ?
  - star-castle 8y ago
    Click the [-] at the top right of that doc page. You won't find it so overwhelming.
- kevinmgranger 8y ago
  I'm not the person who you asked, and I'm an absolute rust lover, but-- Rust is for people with C-level problems who don't like C's ergonomics. Zig appears to be for people with C-level problems who do like C's ergonomics. Some of that is from essential complexity that we've been lying to ourselves about (memory safety, mutability, safe parallelism) and rust makes explicit. C has a simplicity for it, for better _and_ worse.
beagle3 8y ago
Zig might be a good fit for you. Nim also seems to answer all your requirements.
- mbel 8y ago
  Nim doesn't meet all his requirements, it's garbage-collected. Complexity is hard to measure and rather subjective, but Nim in my opinion seems to be more complex than Zig.
  - dom96 8y ago
    > Nim in my opinion seems to be more complex than Zig That may be so, but Zig is still in a very early stage of development. A language may look simple and fresh in the beginning, but the real test comes when 1.0 is right around the corner. Nim is at this stage now, I am one of the Nim core devs and I will even admit that it is by no means simple, there are features that I would like to see removed to reduce the complexities, but how do you do that when a vocal percentage of your user base loves the feature? Do keep this in mind when trying to compare a language like Zig (which is just starting out) to a language like Nim (which has been around for a while). Perhaps Zig will do a better job than Nim in this regard, but only time can tell.
    - nickpsecurity 8y ago
      You can also point out that people can use subsets with minimal features. They can do it for extra safety, consistency, or even low-level control. Safety-critical field has done that with both C++ and Java for some time now. Regarding that, does Nim allow one to turn off GC, mess with pointers, and twiddle bits like in C? As in, is there an optional set of C's features in there that one can use? Or improve with macros, type-safe wrappers, and so on?
      - beagle3 8y ago
        > Safety-critical field has done that with both C++ and Java for some time now. Every company/project uses a subset of C++ for a variety of reasons. The problem is, all those subsets are different, and as a result, if you want to rely on the ecosystem, you eventually have to deal with the entire language. Maybe you avoid exceptions/pointers/new&delete/template-meta-programming/the-coprocessor, but the libraries you need don't. This is visible already in Nim, where the GC is optional, but most libraries (and most of the standard library) does depend on it. It works well without GC, but you lose out on most of the existing libraries and many parts of the ecosystem. > Regarding that, does Nim allow one to turn off GC, mess with pointers, and twiddle bits like in C? It lets you twiddle bits without having to turn off the GC - it has GC-tracked pointers ("ref"s) and non-GC ones ("ptr"s). the GC is per-thread, with time limits but it can also be turned off. > Or improve with macros, type-safe wrappers, and so on? Nim macros are not quite at the Lisp level, but they are extremely powerful. There are various features for type safety that DON'T require wrappers, e.g. you could define "meters" and "yards" as two distinct 64-bit double types, which means you can't add them or assign one to a variable of the other kind, even though they are still essentially a C-style typedef. This is a much more elegant solution than the C++/Python/SmallTalk/Java/C# crowd, where you have to define a class with a lot of methods, which is still clunky, and hope that the compiler will be able to optimize it back down to a plain old double.

ionforce 8y ago

What part(s) of Rust do you find too complicated, and why?

oregontechninja 8y ago
One place they're thinking of might be integration with C. zig's C integration is crazy good from what I can tell toying around with it. It was as easy as @cImport({@cInclude("header.h")}) The language is also evolving rapidly, this may have changed, but if it did, it probably changed for the better.
pseudonymcoward 8y ago
In general I prefer languages to be small and simple - like Go and C. This doesn't seem to be a design goal for Rust, which puts me off. Some specifics: Trying to do anything non-trivial with ownership/lifetimes/borrowing always ends up in a tangle, fighting with the compiler. Everything in the stdlib seems to have a giant api with pages and pages of functions. Example: https://doc.rust-lang.org/std/string/struct.String.html https://doc.rust-lang.org/std/string/struct.String.html Scrolling down through those methods is overwhelming. The overhead imposed by the goal of maximising safety is big, and not that important to me (as I'm not writing Very Important Crypto code or whatever, I don't find it hard to write good enough code for my purposes in C).
- deleted 8y ago
  [deleted]
- julienfr112 8y ago
  Why not Ctrl-F instead of scrolling ?
- star-castle 8y ago
  Click the [-] at the top right of that doc page. You won't find it so overwhelming.
kevinmgranger 8y ago
I'm not the person who you asked, and I'm an absolute rust lover, but-- Rust is for people with C-level problems who don't like C's ergonomics. Zig appears to be for people with C-level problems who do like C's ergonomics. Some of that is from essential complexity that we've been lying to ourselves about (memory safety, mutability, safe parallelism) and rust makes explicit. C has a simplicity for it, for better _and_ worse.

beagle3 8y ago

Zig might be a good fit for you. Nim also seems to answer all your requirements.

mbel 8y ago
Nim doesn't meet all his requirements, it's garbage-collected. Complexity is hard to measure and rather subjective, but Nim in my opinion seems to be more complex than Zig.
- dom96 8y ago
  > Nim in my opinion seems to be more complex than Zig That may be so, but Zig is still in a very early stage of development. A language may look simple and fresh in the beginning, but the real test comes when 1.0 is right around the corner. Nim is at this stage now, I am one of the Nim core devs and I will even admit that it is by no means simple, there are features that I would like to see removed to reduce the complexities, but how do you do that when a vocal percentage of your user base loves the feature? Do keep this in mind when trying to compare a language like Zig (which is just starting out) to a language like Nim (which has been around for a while). Perhaps Zig will do a better job than Nim in this regard, but only time can tell.
  - nickpsecurity 8y ago
    You can also point out that people can use subsets with minimal features. They can do it for extra safety, consistency, or even low-level control. Safety-critical field has done that with both C++ and Java for some time now. Regarding that, does Nim allow one to turn off GC, mess with pointers, and twiddle bits like in C? As in, is there an optional set of C's features in there that one can use? Or improve with macros, type-safe wrappers, and so on?
    - beagle3 8y ago
      > Safety-critical field has done that with both C++ and Java for some time now. Every company/project uses a subset of C++ for a variety of reasons. The problem is, all those subsets are different, and as a result, if you want to rely on the ecosystem, you eventually have to deal with the entire language. Maybe you avoid exceptions/pointers/new&delete/template-meta-programming/the-coprocessor, but the libraries you need don't. This is visible already in Nim, where the GC is optional, but most libraries (and most of the standard library) does depend on it. It works well without GC, but you lose out on most of the existing libraries and many parts of the ecosystem. > Regarding that, does Nim allow one to turn off GC, mess with pointers, and twiddle bits like in C? It lets you twiddle bits without having to turn off the GC - it has GC-tracked pointers ("ref"s) and non-GC ones ("ptr"s). the GC is per-thread, with time limits but it can also be turned off. > Or improve with macros, type-safe wrappers, and so on? Nim macros are not quite at the Lisp level, but they are extremely powerful. There are various features for type safety that DON'T require wrappers, e.g. you could define "meters" and "yards" as two distinct 64-bit double types, which means you can't add them or assign one to a variable of the other kind, even though they are still essentially a C-style typedef. This is a much more elegant solution than the C++/Python/SmallTalk/Java/C# crowd, where you have to define a class with a lot of methods, which is still clunky, and hope that the compiler will be able to optimize it back down to a plain old double.