ephaeton

instead of? IMO You ARE writing the proper test. If your API doesn't have state, your throwaway UI will have imparted the same test coverage as a repeatedly running unit test where it matters. If your API has state, well ...

IMO, It's the same idea with REPL-driven development in a functional language, why write unit tests if an interface is impossible to behave differently over time without changes?

Typically someone then argues, well, what if you change the implementation. To that person I will point out that the change will be developed in a REPL just like the original version, and thus be tested when it hits. Oh well...

To some, QA means a lot of compute and green outputs, to others, QA means spending quality hammock time before hitting the REPL :)

having less addresses than humans is a feature that gets broken by IPv6. IMO, there ought to be less globally valid IPv4 addresses (say, a kilo less or so, maybe even a mega. We probably could even do with a giga less if you're willing to do continent/major compass routing first).

IPv6 is a bit of a surveillance backbone. First you need an ID space that is big enough to give everybody a (or many) unique tags. The rest follows. If identity clashes are too costly, the identifier ceases being a useful tracking tool. If your network is based on an ID space that can satisfy your tracking needs already, how nice is that?

In the past thirty years, I have not encountered a use-case where I thought, Oh, I wish I had one (or a million, billion, or whatever) IPv6 addresses available here! But then again, I haven't developed software for bad actors.

time to try guix again! Let's see ... hey, let's install inside an arch nspawn on arch. Oh no, builds won't complete. Can't mount a proc directory. Doesn't matter if root or not, with or without systemd-nsresourced, etc, spawn ran as root or not, or ..

Fine, let's give it a shot in a qemu: doesn't work. After eons it just .. fails. Some HTTP timeout.

Ok, ok, let's install the thing on my box. I didn't want to but let's give this a try .. install, try and install the first package ... whoa, that computing my solution is taking forever, my oh my ... oh it does something!

``` In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f ```

Wow, same experience as the last three times. Sink time into making sure I'm up to date with concepts, ideas, implementation details, read the docco, try the simplest things and ... fail.

Obviously this is not the default experience of you all. But it doesn't seem to be for me :'(

same here. This thing is gold for "80% solutions" in that respect. It's easier to sanely integrate with legacy transport protocols than trying to update the legacy code base to implement mutual trust the harder, more direct and more error-prone way, IMO.

To my surprise, in Librewolf this was also enabled. To how much effect, I wouldn't know (I hadn't noticed any shenanigans, then again, I just updated my librewolf and don't know if that brought it in).

Do I read slowly if this is scrolling too fast for me? Oooph. "If this scrolls too fast for you, you're getting old!", hehe

at "build time", the default language's build tool, a zig program, can reach anywhere and everywhere. To build a zig project, you'd use a zig program to create dependencies and invoke the compiler, cache the results, create output binaries, link them, etc.

Distinguishing between `comptime` and `build time` is a distinction from the ivory tower. 'zig build' can happily reach anywhere, and generate anything.

I feel that's such a red herring.

You can @setEvalBranchQuota essentially as big as you want, @embedFile an XML file, comptime parse it and generate types based on that (BTDT). You can slow down compilation as much as you want to already. Unrestricting the expressiveness of comptime has as much to do with compile times, as much as the restricted amount, and perceived entanglement of zig build and build.zig has to do with compile times.

The knife about unrestricted / restricted comptime cuts both ways. Have you considered stopping using comptime and generate strings for cachable consumption of portable zig code for all the currently supported comptime use-cases right now? Why wouldn't you? What is it that you feel is more apt to be done at comptime? Can you accept that others see other use-cases that don't align with andrewrk's (current) vision? If I need to update a slow generation at 'project buildtime' your 'compilation speed' argument tanks as well. It's the problem space that dictates the minimal/optimal solution, not the programming language designer's headspace.

> Personally, I find the idea that a compiler might be able to reach outside itself completely terrifying (Access the network or a database? Are you nuts?).

What is "itself" here, please? Access a static 'external' source? Access a dynamically generated 'external' source? If that file is generated in the build system / build process as derived information, would you put it under version control? If not, are you as nuts as I am?

Some processes require sharp tools, and you can't always be afraid to handle one. If all you have is a blunt tool, well, you know how the saying goes for C++.

> However, what the compiler gets and generates should be completely deterministic.

The zig community treats 'zig build' as "the compile step", ergo what "the compiler" gets ultimately is decided "at compile, er, zig build time". What the compiler gets, i.e., what zig build generates within the same user-facing process, is not deterministic.

Why would it be. Generating an interface is something that you want to be part of a streamline process. Appeasing C interfaces will be moving to a zig build-time multi-step process involving zig's 'translate-c' whose output you then import into your zig file. You think anybody is going to treat that output differently than from what you'd get from doing this invisibly at comptime (which, btw, is what practically happens now)?

zig's C compat is being lowered from 'comptime' equivalent status to 'zig build'-time equivalent status. When you'll need to put 'extern "C"' annotations on any import/export to C, it'll have gone full-circle to C++ C compat, and thus be none the wiser.

andrewrk's wording towards C and its main ecosystem (POSIX) is very hostile, if that is something you'd like to go by.

well, the lisp family of languages surely can do all of that, and more. Check out, for example, clojure's version of zig's dropped 'async'. It's a macro.

zig's comptime has some (objectively: debatable? subjectively: definite) shortcomings that the zig community then overcomes with zig build to generate code-as-strings to be lateron @imported and compiled.

Practically, "zig build"-time-eval. As such there's another 'comptime' stage with more freedom, unlimited run-time (no @setEvalBranchQuota), can do IO (DB schema, network lookups, etc.) but you lose the freedom to generate zig types as values in the current compilation; instead of that you of course have the freedom to reduce->project from target compiled semantic back to input syntax down to string to enter your future compilation context again.

Back in the day, where I had to glue perl and tcl via C at one point in time, passing strings for perl generated through tcl is what this whole thing reminds me of. Sure it works. I'm not happy about it. There's _another_ "macro" stage that you can't even see in your code (it's just @import).

The zig community bewilders me at times with their love for lashing themselves. The sort of discussions which new sort of self-harm they'd love to enforce on everybody is borderline disturbing.

yeah, machines of different endianness, and, ideally, different alignment requirements. Always wanted to get an alpha, as well. Had hpux / hp300 ?, sparc, sparc64, 386, x86_64, maybe another arch. This was in 2005'ish, mind you. Idea was to write code that would portably work on linux and netbsd on at least said architectures, ideally more.