Replacing lld rather than add macho support send like a mistake.
s/send/seems/
Maintain It with Zig
191–200 of 286 posts
Re: Maintain It with Zig
#192Earlier quoted context omitted.
Nim is garbage collected, thus is a higher level language but doesn't fit the high performance low overhead of "systems programming" requirement. While Zig is manual memory managed like C and nearer to the core, but harder to program.
With ARC, Nim's memory management would be closer to Rust than to Go.
Automatic Reference Counting? I’m not sure. Swift spends a lot of its execution time doing reference counting.
Re: Maintain It with Zig
#193Earlier quoted context omitted.
You care because you need to have a c compiler installed, as well as the libc stuff… It is a giant pain to do so in some circumstances. One less dependency is a good thing. I quoted from cc’s readme above.
100% of platforms that Zig & Rust run on already have a C compiler installed, though. A c compiler being present is the baseline assumption. If Zig existed in places C doesn't and I wanted to write C for that platform then having Zig CC would be an advantage. But such a situation doesn't currently exist and seems unlikely to ever exist? Especially in the context of a library/module porting to Zig or Rust piecemeal, t…
Yes, most of my systems have "zig cc" as a C compiler installed nowadays. Why? It's so much easier to install. Especially on systems like windows, and i get other benefits. One example: "I can send you a project, and you can just compile it." Dependencies? "Zig toolchain, any OS"
I haven't had this experience with any other language. When a package manager lands, you won't even have to install any SDKs by hand anymore.
Re: Maintain It with Zig
#194Earlier quoted context omitted.
Totally. I personally would not agree with > Languages with more powerful abstraction abilities bring joy to the writer but make things tedious for the reader. I find map/filter to be easier to read than a C-style for loop. Things that are conceptually denser make discussion between experts easier, even if it makes things harder for non-experts. This is why jargon exists, for example.
Ah yes - that makes sense. I should have been more precise - I meant abstractions that allow you to add opaqueness (like macros and operator overloading). Again culture plays a role here too - some communities normalize such abstractions more than others. In short I believe languages that one can pick up in a couple of days and then read code where reasoning of the code is highly local would stand a higher chance of…
As always it depends. If you're thinking about preprocessor macros and operator overloading from C++, sure, those can be annoying, it's more to do with C++'s implementation and usage of them than the features themselves. You might want to try Common Lisp sometime; so much of the base language is made up of macros without which programs would be neither pleasant to read or write, and the language itself provides facilities to ask "ok but what function(s) are actually going to get called with this data" so that even not-so-local things like e.g. transparent logging of a call's input/output become visible if you need to know. But CL is not a language one can pick up in a couple of days -- albeit CL shops report success in getting new hires to be productive after a week or two of reading a book and the company code, which is a common onboarding time at many companies with any language.
Programmers notoriously conflate "simple" and "easy" (classic talk: https://www.infoq.com/presentations/Simple-Made-Easy/) and so I believe languages that are easy for a lot of programmers will also be perceived as simple, whether or not that's accurate.
Re: Maintain It with Zig
#195Earlier quoted context omitted.
The reason that we have programming languages at all is that English and all other natural languages are too ambiguous to be used for this purpose. GPT-3000 will have no problem understanding some interpretation of your English (or Spanish or Mandarin) "program", but will it be the right one? How long will it take to get GPT-3000 to understand what you mean when you can only talk to it in English (or Spanish or Manda…
Eventually maybe only the same amount of time it takes the average programmer to understand your meaning.
So like months and years? On every project I’ve worked on, the programmers conception of the requirements evolves until the minute they stop working on it. And they only understand the part they worked on, not the whole thing
Re: Maintain It with Zig
#196Earlier quoted context omitted.
Eventually maybe only the same amount of time it takes the average programmer to understand your meaning.
So like months and years? On every project I’ve worked on, the programmers conception of the requirements evolves until the minute they stop working on it. And they only understand the part they worked on, not the whole thing
The discussion is not about understanding "requirements".
A piece of software is a set of instructions that tell a computer how to do something. We use languages like C, Python, Haskell and Lisp to describe what to do in ways that avoid as much ambiguity as possible.
The question is: if you used a natural (human) language, how much confusion would (a) the putative GPT-3000 (b) another programmer (c) a compiler/interpreter incur when trying to understand your instructions?
Re: Maintain It with Zig
#197Earlier quoted context omitted.
The reason that we have programming languages at all is that English and all other natural languages are too ambiguous to be used for this purpose. GPT-3000 will have no problem understanding some interpretation of your English (or Spanish or Mandarin) "program", but will it be the right one? How long will it take to get GPT-3000 to understand what you mean when you can only talk to it in English (or Spanish or Manda…
Eventually maybe only the same amount of time it takes the average programmer to understand your meaning.
That might be true. But the comparison is not with another programmer. Rather, it's with the essentially instantaneous understanding that a compiler/interpreter has when you feed in a programming language.
Re: Maintain It with Zig
#198What I don’t understand is why Clang doesn’t do this? What’s stopping them from shipping libc’s for cross compilation? Given that they are a C and C++ compiler, surely this is in their domain.
In principle, clang could do it, you're right. I think there are two main reasons why it hasn't.
First, Zig has a pretty unique and impressive build&caching system. It makes something like this a lot less painful than it would be otherwise. It makes it practical to just download a 40MB tarball and get full cross-compiling from it.
Second, clang itself isn't in the business of building a distribution of itself + third-party libraries. Usually developers using clang get such libraries from their "vendor" (package manager if on a Linux distro, Apple if on MacOS, etc.). And those vendors naturally focus on their own platforms. So Zig ended up the first to really do the work to build a cross-platform C/C++ toolchain.
Re: Maintain It with Zig
#199Earlier quoted context omitted.
Out of curiosity, what are you working on that requires a proper string type (rather than encoded UTF-8 bytes)?
I wouldn't use the word "require", and perhaps you didn't mean it that strongly. Don't get me wrong: I could get by without and achieve what I needed to, but to be honest it didn't feel great. I was doing some pretty gnarly high-level filesystem work (transforming an unstructured tree of files/folders into a more structured tree following certain naming and categorization conventions -- a lot of parsing/building/conc…
Keep in mind that filesystem paths aren't strings. On Linux, they are raw bytes without any fixed encoding (but usually UTF-8 on UTF-8-based locales), and on Windows, they are sequences of 16-bit codepoints which are expected to be UTF-16 but not validated.
Rust's OsStr is my favorite approach so far. It stores Linux's raw bytes as-is, and stores Windows's possibly-valid UTF-16 as WTF-8. This makes path management "just work", with the ability to operate normally on invalid UTF-8 or UTF-16 paths, and zero-copy conversion from UTF-8/ASCII strings to OsStr (though converting OsStr into UTF-16 requires parsing). (Qt's QString-based file dialogs on Linux fail to convert invalid UTF-8 paths like those in https://github.com/petrosagg/wtfiles into QString, causing Qt-based apps to open/save the wrong paths.)
However there are difficulties in printing an OsStr. For example, a file dialog that shows filenames as raw bytes can't show non-Latin/Unicode characters in a human-readable form, and a file dialog that shows filenames as Unicode strings can't handle invalid Unicode filenames. GTK3 file dialogs show filenames as Unicode strings, and when encountering files with invalid Unicode names, instead displays "file�name.txt (invalid encoding)".
Worse yet, how should a file dialog allow users to rename files? If it's based around byte arrays, the user can't enter Unicode characters directly, and if it's based around Unicode (or a locale-specific text encoding), it can't display existing files with invalid Unicode/etc. in the name (probably not an issue if it allows the user to rename to a valid name), nor allow users to enter invalid Unicode (which is not an issue IMO).
Re: Maintain It with Zig
#200Earlier quoted context omitted.
> Let's hope this is not vaporware. I sincerely approve of the skepticism. I can assure you there is already a very large fire under my ass to get this shipped. To provide some more context, here is a snippet from the latest release notes[0]: > Having a package manager built into the Zig compiler is a long-anticipated feature. Zig 0.8.0 does not have this feature. > If the package manager works well, people will use…
Will the compiler have something like go's ability to vendor code locally? I've worked on some science projects and this has been a hard requirement on some systems for tape archive storage.
Zig's build system has a first-class notion of packages that satisfies exactly this requirement. The Ziglearn documentation[0] has more details.
To make things a little more interesting though, Zig's shape in this regard should be roughly congruent to C's, so you should be able to do anything with Zig that you can with C. This includes linking against shared objects for C libraries like, e.g., SDL2[1] or building mixed-language Zig+C projects[2].
0: https://ziglearn.org/chapter-3/#packages 1: https://dev.to/fabioarnold/setup-zig-for-gamedev-2bmf 2: https://tiehu.is/blog/zig1