ephaeton

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

Thanks for your input!

I've pondered on and off about distrokid (or the like), and thankfully one of my peers has done just that. Mind you, he is more established and "successful" (as in, gets more paying gigs, more audience, ...). So I've talked to him about it. During the past half year, he's "earned" 4€ from Spotify (in other words, one song made the cut of 1k listens over a year), and 180€ from Bandcamp.

I see Distrokid as helpful marketing investment for discovery, so I was still inclined to burn some money (one teaching session will likely cover my loss, so whatever), but then he went on how he put a video of a performance of a published song of his (published via Distrokid) on YT - et voila - he's got challenged by Distrokid for it. Uh, yeah. I understand you gotta relinquish rights to let DK do their thing, but that's the sort of headache I wouldn't ever want. Maybe he was doing something wrong, of course, but I'll likely fall into the same trap. More reading required ...

I'll keep in touch with him about it, maybe the discovery on spotify led to the BC throughput, but we'll have to dig deeper. There's a lot of us small artists in different stages of our development (say, performance, entertainment, composition wise), I'd love to exchange experiences on what works and what doesn't for the ailing musician. There's platforms which contains a lot of us, but everybody seems to be struggling and there seems to be a strong sense of competition among many of my peers, so it's hard to get unfiltered (subjective) truths there. And the internet is filled with horror stories as well as "from dishwasher to millionaire" survivorship biased fairy tales. Oooph.

As a small artist living in quite a tiny niche - didgeridoo music - I have to say that the requirement for having your music on spotify is a no-go. Artists like myself don't benefit from spotify, I don't think, it's a net loss and you join the ranks of people with questionable actions (cf., e.g., spotify-AI-generated content). BC and/or YT would be viable alternatives for those who actually need discovery IMO.

E.g., here's some unexpected percussive organic trance for you that my collaborators and I put on BC: https://dojorich.bandcamp.com/album/tubecolab (I'm Freddie Veggie, btw). Music of that scope doesn't "perform" on spotify, so I won't invest in having it there.

NetBSD.

The docco, the culture, the clarity and simplicity of design from first principles. The coherency of code across kernel, user-space, accompagnying material. The vibe.

You may know NetBSD (if, at all) as the BSD that wants to be "portable" and may dismiss it against FreeBSD's focus-claim of "performance" and OpenBSD's focus-claim of "security". Interestingly, trying to remain wildly portable requires a cleanliness inside that is very soothing.

maybe they'll do the write up next time before it goes live...