5 ms·

I think there is definitely merit in these kinds of posts. This developers measure of productivity is "how low level can I go" clearly; they declared zig was c

I think there is definitely merit in these kinds of posts. This developers measure of productivity is "how low level can I go" clearly; they declared zig was clear despite saying this: > The lack of string handling routines in the stdlib was unexpected, to concatenate strings one has to do everything manually - allocate the buffer, put strings there. Or use formatter and an allocator to print both strings side by side and free the buffer afterwards. This combined with "strings" being byte buffers like in C are not a good thing. I had a quick look and the author appears to be german; how do you handle an umlaut in zig? His dismissal of C++ as "not having a build system" seems like considering the language without the ecosystem. Using cmake and llvm solves all of his gripes on C++. Finally, this post measures the productivity of a single developer, On a 1-3 file project. How these projects work with 2-5 developers, or on projects that support more than the anglosphere are very important.

mhh__ 6y ago
> using cake and LLVM Sure they (not sure about LLVM as a build system?) work but they really aren't all that great in my experience.
- maccard 6y ago
  I've had excellent experience with cmake over the last 10 years. It's no cargo, that's for sure, but it gives you a crossplatform cross toolchain extensible reliable build system Llvm was specifically in reference to the "tooling" comment in the blog post. Clang format and clang-tidy(which conveniently has a neat integration with cmake!)
- mhh__ 6y ago
  How did I not notice it corrected cmake to cake...
linkdd 6y ago
CMake, SCons, Autotools, Meson, Premake, to quote only them. They are build systems alright, but they miss the most crucial point: dependency managment. On the other side we have: - cargo for Rust - buck and buckaroo for C++ which seems nowhere near complete Am I missing something?
- maccard 6y ago
  Cmake is pretty good, but you're right it's no dependency manager. And dependency management us definitely tough in c++. There's vcpkg and conan though which are huge improvements over the status quo.
- naavis 6y ago
  This is exactly my painpoint with C++ too. With Rust and such I'm one simple command line call away from installing a dependency. With C++ every dependency is a battle.
  - galangalalgol 6y ago
    There is conan or vcpkg. I do wish crates.io and julia would make it easier to develop on non internet machines. The ease of dependency management has bred staggeringly deep dependency trees for rust and julia. If I could run a cargo command to get a human readable dependency list that I could then go to an internet facing machine and run a cargo command to put into a tgz to drag back over that would be helpful. Is there any progress on making a crates mirror for offline networks?
    - shepmaster 6y ago
      A list of dependencies: https://doc.rust-lang.org/cargo/commands/cargo-tree.html https://doc.rust-lang.org/cargo/commands/cargo-tree.html Download all dependencies locally: https://doc.rust-lang.org/cargo/commands/cargo-vendor.html https://doc.rust-lang.org/cargo/commands/cargo-vendor.html
      - galangalalgol 6y ago
        I think maybe I don't understand vendor. I thought you had to have your project on the internet facing machine to vendor its dependencies. Which I cannot do.
        shepmaster 6y ago
yakubin 6y ago
> His dismissal of C++ as "not having a build system" seems like considering the language without the ecosystem. Using cmake and llvm solves all of his gripes on C++. Last week I debugged an issue in a big C++ codebase, where we were getting memory corruption. Source of the issue? Compiler, linker and build system being separate things and only compiler understanding types (also, lack of modules, which is another symptom of build system being separate from the language). Namely, conditional compilation was involved, someone made a struct which had a field in it based on whether a preprocessor constant was defined or not (passed with -D to the compiler on the command line). Turned out some files were compiled with the define and some not, so some files were compiled based on the assumption that this struct is N bytes long, and some with the assumption that this struct is N+M bytes long. But the linker doesn't have any information available to it to detect this error. And then there is the issue that to write a C++ program these days, it doesn't suffice that you just know C++. Languages you need to know: - C++ - language of your build system, which is always handicapped, yet Turing-complete - Python - if something goes wrong, and you need to debug something: Make with its custom shell-language - shell It's a tower of babel. For all the whining on users of other languages for using libraries, C++ users have a lot of complexity hidden in their build systems. In Zig and the not-yet-released Jai, you only need to know the language you write your program in. The "if" in your language of choice is perfectly suitable for expressing conditional compilation. Structs in your language of choice are perfectly suitable for expressing declarative configuration.
- renox 6y ago
  Yep been there done that two months ago, took me two days (at least) to find the issue as a corruption which happen in -O3 but not in debug build which neither valgrind nor ASAN can find is pretty mysterious..
  - Too 6y ago
    Unless you left out some details, this sounds more like plain UB and buggy c++ code manifesting itself with different symptoms depending on the O level. This has not as much to do with the loosely coupled build system complexity you have to scaffold in a c++ project, more issues in the core language itself.
flohofwoe 6y ago
> This combined with "strings" being byte buffers like in C are not a good thing. The problem of C strings is that they are zero-terminated, not that they are byte buffers. Strings in Zig are foremost slice types (pointer/size pairs), but for C compatibility, Zig also has the concept of 'sentinel terminated arrays': https://ziglang.org/documentation/master/#Sentinel-Terminated-Arrays https://ziglang.org/documentation/master/#Sentinel-Terminate... > how do you handle an umlaut in zig Via UTF-8 encoding, as it should be. > cmake... I use cmake for my C and C++ stuff too because it's the defacto standard, but Rust's cargo or Zig's integrated build system are on a whole different level.
- maccard 6y ago
  > utf-8 as it should be Agreed, but now your standard library doesn't have string support, it has byte buffer support. That's no improvement over C, compared to rust.
  - flohofwoe 6y ago
    The downside of a single string type built into the standard library or even into the language is that it needs to be both flexible and performant, and in my experience, those two things exclude each other (e.g. how do you append two high-level strings like "str1 + str2" without hidden allocation?). Apart from that, Zig's string processing functions are not that bad, what's unexpected is that they are in the memory-operations part of the standard library, not in a specific "string module" (after all, the Zig compiler is (being) written in Zig, and the parser needs to do a lot of string-munching, so I guess we'll get more powerful string processing helper functions in the standard library over time). But if I need to do lots of high-level string processing I probably wouldn't chose a systems programming language to begin with, languages like Python are a better match for this.
  - lhorie 6y ago
    Zig does have utf8 APIs, though to be fair, the docs are quite sparse
  - m45t3r 6y ago
losvedir 6y ago
> how do you handle an umlaut in zig? "Handle" how? If you're just shuffling bytes around, you don't need to worry about it. If you need to iterate through by codepoints, there's stdlib Utf8View module, though I understand this aspect of the standard library is set to change before 1.0. The fact that multi-byte codepoints don't have bytes that could be ASCII gets you decently far for common things like splitting a string at a newline, or otherwise matching against a char. edit: actually, were you talking about the code in the post? Looking at it now, I see it's buggy in this regard, if you're wanting a ? to match ü. I think basically what you'd do is in the branch corresponding to the ? you could use the stdlibs's utf8ByteSequenceLength function to skip the text ahead that many bytes, while advancing the pattern by just the one byte.
dgellow 6y ago
Regarding the string type in Zig, in case some people are interested by this you can read those two threads from the Zig github repository to understand a bit better previous discussions (I would recommend reading them, they are both interesting): ------- "Improved handling of strings and unicode", https://github.com/ziglang/zig/issues/234 https://github.com/ziglang/zig/issues/234 Andrew answer: > I'm not convinced that this is a language change rather than a standard library feature. (source https://github.com/ziglang/zig/issues/234#issuecomment-289273347 https://github.com/ziglang/zig/issues/234#issuecomment-28927...) ------- "Proposal: Add String to the type system", https://github.com/ziglang/zig/issues/7734 https://github.com/ziglang/zig/issues/7734 Andre answer: > We won't have a string type in the language. > OP problem can be solved with a better std.fmt.format API which better communicates intent. This is a deficiency of the std lib, not the language (source https://github.com/ziglang/zig/issues/7734#issuecomment-758167124 https://github.com/ziglang/zig/issues/7734#issuecomment-7581...)
logicchains 6y ago
>This combined with "strings" being byte buffers like in C are not a good thing. It depends what the problem you're facing with. If the problem is "people writing C++ code with terrible latency characteristics because they don't understand how it works underneath and the stdlib doesn't even provide a way to efficently concatenate strings (i.e. by using a buffer, not allocating new memory)", Zig's approach is a great thing.

mhh__ 6y ago

> using cake and LLVM Sure they (not sure about LLVM as a build system?) work but they really aren't all that great in my experience.

maccard 6y ago
I've had excellent experience with cmake over the last 10 years. It's no cargo, that's for sure, but it gives you a crossplatform cross toolchain extensible reliable build system Llvm was specifically in reference to the "tooling" comment in the blog post. Clang format and clang-tidy(which conveniently has a neat integration with cmake!)
mhh__ 6y ago
How did I not notice it corrected cmake to cake...

linkdd 6y ago

CMake, SCons, Autotools, Meson, Premake, to quote only them. They are build systems alright, but they miss the most crucial point: dependency managment. On the other side we have: - cargo for Rust - buck and buckaroo for C++ which seems nowhere near complete Am I missing something?

maccard 6y ago
Cmake is pretty good, but you're right it's no dependency manager. And dependency management us definitely tough in c++. There's vcpkg and conan though which are huge improvements over the status quo.
naavis 6y ago
This is exactly my painpoint with C++ too. With Rust and such I'm one simple command line call away from installing a dependency. With C++ every dependency is a battle.
- galangalalgol 6y ago
  There is conan or vcpkg. I do wish crates.io and julia would make it easier to develop on non internet machines. The ease of dependency management has bred staggeringly deep dependency trees for rust and julia. If I could run a cargo command to get a human readable dependency list that I could then go to an internet facing machine and run a cargo command to put into a tgz to drag back over that would be helpful. Is there any progress on making a crates mirror for offline networks?
  - shepmaster 6y ago
    A list of dependencies: https://doc.rust-lang.org/cargo/commands/cargo-tree.html https://doc.rust-lang.org/cargo/commands/cargo-tree.html Download all dependencies locally: https://doc.rust-lang.org/cargo/commands/cargo-vendor.html https://doc.rust-lang.org/cargo/commands/cargo-vendor.html
    - galangalalgol 6y ago
      I think maybe I don't understand vendor. I thought you had to have your project on the internet facing machine to vendor its dependencies. Which I cannot do.
      - shepmaster 6y ago

yakubin 6y ago

> His dismissal of C++ as "not having a build system" seems like considering the language without the ecosystem. Using cmake and llvm solves all of his gripes on C++. Last week I debugged an issue in a big C++ codebase, where we were getting memory corruption. Source of the issue? Compiler, linker and build system being separate things and only compiler understanding types (also, lack of modules, which is another symptom of build system being separate from the language). Namely, conditional compilation was involved, someone made a struct which had a field in it based on whether a preprocessor constant was defined or not (passed with -D to the compiler on the command line). Turned out some files were compiled with the define and some not, so some files were compiled based on the assumption that this struct is N bytes long, and some with the assumption that this struct is N+M bytes long. But the linker doesn't have any information available to it to detect this error. And then there is the issue that to write a C++ program these days, it doesn't suffice that you just know C++. Languages you need to know: - C++ - language of your build system, which is always handicapped, yet Turing-complete - Python - if something goes wrong, and you need to debug something: Make with its custom shell-language - shell It's a tower of babel. For all the whining on users of other languages for using libraries, C++ users have a lot of complexity hidden in their build systems. In Zig and the not-yet-released Jai, you only need to know the language you write your program in. The "if" in your language of choice is perfectly suitable for expressing conditional compilation. Structs in your language of choice are perfectly suitable for expressing declarative configuration.

renox 6y ago
Yep been there done that two months ago, took me two days (at least) to find the issue as a corruption which happen in -O3 but not in debug build which neither valgrind nor ASAN can find is pretty mysterious..
- Too 6y ago
  Unless you left out some details, this sounds more like plain UB and buggy c++ code manifesting itself with different symptoms depending on the O level. This has not as much to do with the loosely coupled build system complexity you have to scaffold in a c++ project, more issues in the core language itself.

flohofwoe 6y ago

> This combined with "strings" being byte buffers like in C are not a good thing. The problem of C strings is that they are zero-terminated, not that they are byte buffers. Strings in Zig are foremost slice types (pointer/size pairs), but for C compatibility, Zig also has the concept of 'sentinel terminated arrays': https://ziglang.org/documentation/master/#Sentinel-Terminated-Arrays https://ziglang.org/documentation/master/#Sentinel-Terminate... > how do you handle an umlaut in zig Via UTF-8 encoding, as it should be. > cmake... I use cmake for my C and C++ stuff too because it's the defacto standard, but Rust's cargo or Zig's integrated build system are on a whole different level.

maccard 6y ago
> utf-8 as it should be Agreed, but now your standard library doesn't have string support, it has byte buffer support. That's no improvement over C, compared to rust.
- flohofwoe 6y ago
  The downside of a single string type built into the standard library or even into the language is that it needs to be both flexible and performant, and in my experience, those two things exclude each other (e.g. how do you append two high-level strings like "str1 + str2" without hidden allocation?). Apart from that, Zig's string processing functions are not that bad, what's unexpected is that they are in the memory-operations part of the standard library, not in a specific "string module" (after all, the Zig compiler is (being) written in Zig, and the parser needs to do a lot of string-munching, so I guess we'll get more powerful string processing helper functions in the standard library over time). But if I need to do lots of high-level string processing I probably wouldn't chose a systems programming language to begin with, languages like Python are a better match for this.
- lhorie 6y ago
  Zig does have utf8 APIs, though to be fair, the docs are quite sparse
- m45t3r 6y ago

losvedir 6y ago

> how do you handle an umlaut in zig? "Handle" how? If you're just shuffling bytes around, you don't need to worry about it. If you need to iterate through by codepoints, there's stdlib Utf8View module, though I understand this aspect of the standard library is set to change before 1.0. The fact that multi-byte codepoints don't have bytes that could be ASCII gets you decently far for common things like splitting a string at a newline, or otherwise matching against a char. edit: actually, were you talking about the code in the post? Looking at it now, I see it's buggy in this regard, if you're wanting a ? to match ü. I think basically what you'd do is in the branch corresponding to the ? you could use the stdlibs's utf8ByteSequenceLength function to skip the text ahead that many bytes, while advancing the pattern by just the one byte.

dgellow 6y ago

Regarding the string type in Zig, in case some people are interested by this you can read those two threads from the Zig github repository to understand a bit better previous discussions (I would recommend reading them, they are both interesting): ------- "Improved handling of strings and unicode", https://github.com/ziglang/zig/issues/234 https://github.com/ziglang/zig/issues/234 Andrew answer: > I'm not convinced that this is a language change rather than a standard library feature. (source https://github.com/ziglang/zig/issues/234#issuecomment-289273347 https://github.com/ziglang/zig/issues/234#issuecomment-28927...) ------- "Proposal: Add String to the type system", https://github.com/ziglang/zig/issues/7734 https://github.com/ziglang/zig/issues/7734 Andre answer: > We won't have a string type in the language. > OP problem can be solved with a better std.fmt.format API which better communicates intent. This is a deficiency of the std lib, not the language (source https://github.com/ziglang/zig/issues/7734#issuecomment-758167124 https://github.com/ziglang/zig/issues/7734#issuecomment-7581...)

logicchains 6y ago

>This combined with "strings" being byte buffers like in C are not a good thing. It depends what the problem you're facing with. If the problem is "people writing C++ code with terrible latency characteristics because they don't understand how it works underneath and the stdlib doesn't even provide a way to efficently concatenate strings (i.e. by using a buffer, not allocating new memory)", Zig's approach is a great thing.