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 :)

Interestingly, previously submitted two months ago as "https://news.ycombinator.com/item?id=48414519" Jolt: Clojure Interpreter on Janet.

So it seems the clojure interpreter has both sapped down to chez, and been replaced by compile tools, and a shim stack for the java compat, as well.

Congrats, I'd say.

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.

I dearly remember setting up NetBSD on various sparc stations and ultra sparcs (a II, and an Ultra 60) and running them alongside a set of various other RISCs and CISCs of late 90s. Based on the paper 'attack of the lemmings' (IIRC) by matthias something (IIRC), I wanted to create a 'how to portably code C' course that would run with just the basic netbsd tools - compiler, editor, test system, make, ... - write once, commit, have the whole weird-ass machine park response to the unit test for a given exercise. Sadly never made it happen fully. Still - NetBSD! fun times, great documentation and such a knowledgeable crowd! Enjoy the voyage!

I suppose: Sometimes things work fine with the implicit default value that you end up with. So this will cause problems when you forget to initialize values to expected sane defaults.

To me, Rust feels as if it had sprung from the same mind. Or in the case of C++, set of minds. Who have a common mindset. I sadly don't critize rust's general design choices constructively. It's more of a public realization, '"C++ mind-set compatible" might just be the quality to describe the specific aroma I dislike in this melange".

I'm fine with robust languages with very strong type systems, I think. Are Haskell, ML, F#, Scala in this set? Robust and very strongly typed enough? I don't dislike their taste, even though I think I've had enough scala, specifically, for this life time. If these aren't in the set you're thinking of, I'd like to know what makes up that set for you.

I'm sharing sentiment.

C++ feels like a language of bean counters.

Rust feels like a language of bean counters.

A lot of C++ folks I know went over to rust.

They were happy with C++ and it was the best thing since sliced bread.

They are now happy with rust and it is the best thing since sliced bread.

To me, languages have a, let's call it 'taste' for the lack of better word off the top of my head. It's that combining quality that pg called 'hacker's languages', such as C, and lisp, for example.

C++ feels like a bureaucratic monster with manual double bookkeeping, byzanthine, baroque, up to outright weird and contradictory in places. Ever since rust was conceived, I gave it multiple shots to learn. When I was not thrown off by what I perceive as java-style annotations, i.e., something orthogonal to the language itself where no one seems to have bothered to come to a consensus to be able to express this from the language itself, its general feel reminds me of something a C++ embracer will feel comfortable in. I.e., in pg's words, not a hacker's language, paired with a crusade of personal enlightenment. What used to be OO and GoF now is memory safety as-implemented-by-rust (note: not by borrow checker, we could've had this with cyclone, for example, more than two decades ago).

I have, in my original comment, marked this as my personal opinion and feeling, as is the above. I'm not arguing. I love FP and the idea of having a systems language with FP concepts working out to memory safety and higher level expression sounds like the holy grail of yester-me. I'm disappointed I couldn't find my professional salvation in rust with how uneasy I feel within the language. It's as if a suit and tie was forced on me, or a hawaii shirt and shorts (depending on your preference, image it's the thing you wouldn't voluntarily wear).

Now, if other folks also mirror my observation of how the folks flock from C++ to rust, you bet they take their mindset and pedestal with them to stand on and preach off of. At least those I know do, only their sermon changed from C++ to rust, the quality of their dogma remained constant.

loving he goes 'int main() { ... }' and never returns an int from it. Even better: without extra error / warning flags the compiler will just eat this and generate some code from it, returning ... yeah. Your guess is probably better than mine.

If the uber-bean counter, herald of the language of bean counters demonstrate unwillingness to count beans, maybe the beans are better counted in another way.

That explains very well why rust (to me) feels like C++ommitte-designed, thanks for that!

Thanks for the feedback. Yeah there's fixed geometry due to time constraints. Glad you could make it work for you eventually!

Wow, I never knew these deficiencies from gooops. This seems to me like a 'scheme with classes' mindset implementation of CLOS. Given the success of C++ and the like, surely there'll be enough people to productively use this. I'd rather have more "proper" CLOS systems in the world though.

The FP-world worked successfully in dusting mainstream to have rust be a thing, now if we could replace C++ (and simula and whatnot) class-based "object" systems with object-based object system with more advanced capabilities such as sketched in CLOS, that'd be nice IMO.

On the cost of ditching that vi muscle memory.

"Maybe I should fork the compiler and do it myself. Urgh. So many projects. If I could live a million lifetimes, I'd devote one to working on compilers."

-- Maybe you are living a million lifetimes in parallel right now and this one is the one devoted to working on compilers? Get to it! :-)

Congratulations! It's so interesting to witness how "techniques of the past" make a grand return in "new" programming languages that "gained" features from 4 to 7 decades ago to support this programming style. "records, pattern matching, `with` expressions, sum and product types" - in my upbringing, this stuff is decidedly "old-school FP". People going through their learning curve 30 years later than I have will see what I had learned as "dead, possibly failed-forever FP ideas" as the "we tried a lot of stuff but this seemed to be the best way to do it after all" of their time.

looks like a great TOC, sadly no preorder to support its creation :(

awesome, thanks! And thank you for the invitation to a conversation, I'll take it up!

Thank you! And I absolutely understand you gotta start somewhere.

Music recommendation is HARD. A lot of people don't think they like didgeridoo (which is where my expertise lies) until they hear a live performance of contemporary didge over a PA and they're in tears of joy (seriously, if you got the chance, give it a try - the stack of vibrations from this single, simple tube is amazing). IME, that wouldn't work for your average ear-buds or "smilie curve"-tuned over-ears. So, say, a friend convinces you to go to some concert with them - that would be a proper, healthy, sustainable music recommendation service. But of course that doesn't scale in any direction.

Best of luck with your project - I'll be checking back :-)