Currently: playing didgeridoo ("I'm Freddie Veggie and I play austrian didgeridoo" - JFGI).
Also: embedded linux / C++ development
Contact: hn -at- ayaken.net
Previously: type safety x unit safety
Previously: semantic mediation in production networks
Previously: embedded linux development for industrial automation
History:
- Tcl -> Scheme -> C -> C++ -> C -> Common Lisp -> C -> Clojure -> Tcl -> C/++ & wanting zig (unimportant deadends like e.g. ruby, icon, python, perl elided)
- DOS 4.11 -> Win 3.11 -> Win95 -> Linux -> NetBSD -> Linux -> FreeBSD -> Linux (those damn hardware drivers)
Submissions
Jolt: Clojure on Chez Scheme
yogthos.net
2 points·by ephaeton··1 comments
Show HN: Race Timing with Integrated Replay
storytiming.racing
25 points·by ephaeton··2 comments
Wayland from the Wire (Pt.2)
zig.news
2 points·by ephaeton··1 comments
SDF Computer Museum – Retrocomputing
sdf.org
4 points·by ephaeton··1 comments
Open Source Blueprints for Civilization. Build Yourself
opensourceecology.org
4 points·by ephaeton··0 comments
Linux kernel getting “maple” trees to replace RBtrees in MM [LWN]
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!
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).
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.
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.
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.
Also: embedded linux / C++ development
Contact: hn -at- ayaken.net
Previously: type safety x unit safety
Previously: semantic mediation in production networks
Previously: embedded linux development for industrial automation
History: - Tcl -> Scheme -> C -> C++ -> C -> Common Lisp -> C -> Clojure -> Tcl -> C/++ & wanting zig (unimportant deadends like e.g. ruby, icon, python, perl elided)
- DOS 4.11 -> Win 3.11 -> Win95 -> Linux -> NetBSD -> Linux -> FreeBSD -> Linux (those damn hardware drivers)