2026-07-06 02:23:41 <xentrac     > on Friday I had an enjoyable talk with an old friend about why Google wants to abandon C++, and a big part of it is how dysfunctional the ISO is, and in particular the ISO C++ committee
2026-07-06 02:24:33 <cleobuline  > https://labynet.fr/videos/trace.mp4
2026-07-06 02:24:52 <xentrac     > neauoire is Devine, the primary author of Uxn
2026-07-06 02:25:13 <xentrac     > which probably everybody knew already, but just in case
2026-07-06 03:07:37 <Stalevar    > iv4nshm4k0v, I didn't do anything with files and directories yet
2026-07-06 09:07:07 <veltas      > xentrac: I agree they're extremely dysfunctional, yet C++ is still a really good choice for a lot of real problems, mostly if you already have a C++ codebase I don't think it's worth converting to Rust
2026-07-06 09:10:30 <veltas      > Comparing them to other committees I think unfortunately it's quite normal, in fact they're probably one of the better committees
2026-07-06 09:10:34 <veltas      > That's saying a lot
2026-07-06 09:47:30 <iv4nshm4k0v > Not that I ever did any large-scale programming projects myself, so don't have much experience to base my understanding upon, but C++ always seemed a ratther odd language to me.  It /feels/ like implementing the parts of the code that impact performance the most in a low-level language - C, Fortran, etc. - and then implementing the rest in, say, Tcl or Lisp - would've been a better tradeoff overall.
2026-07-06 09:47:30 <iv4nshm4k0v > Sort of how GNU Emacs is written.
2026-07-06 09:50:17 <veltas      > Stuff like namespaces, raii, templates, the standard library containers, operator overloading are all quite useful
2026-07-06 09:50:51 <veltas      > My biggest problem with C++ is that it's far too easy to make life hard for yourself, and I find it hard to resist the temptation
2026-07-06 09:51:53 <veltas      > The fact that you can take almost any C project and just start building it as C++ with minimal changes is probably C++'s biggest feature, for anyone that realises they want more than C offers
2026-07-06 09:53:00 <veltas      > C++ is extremely boring and painfully pragmatic, and has a lot of history and baggage but does real work.  It's not attractive at all, but those things mean it's probably not worth rewriting C++ code in another language.
2026-07-06 09:53:10 <iv4nshm4k0v > Kinda like how Windows became popular by allowing a lot of preexisisting DOS software to be used with few, if any, changes.
2026-07-06 09:53:22 <veltas      > Yeah
2026-07-06 09:53:46 <veltas      > It's almost never worth rewriting stuff in another lang, period.  It's expensive and risky and delivers zero features, it's a classic mistake.
2026-07-06 09:54:07 <veltas      > A mistake Google can afford to make I guess
2026-07-06 09:55:07 <dave0       > windows backwards compatibility
2026-07-06 09:55:21 <iv4nshm4k0v > I /think/ I understand the reasons for C++ popularity, but personally, I'd rather be doing things the GNU Emacs way.  Especially given that now there're lots of high-level languages with bindings to C.
2026-07-06 09:56:46 <veltas      > I'd like to be able to do this kind of stuff in Forth, I'm just not there yet
2026-07-06 09:56:50 <veltas      > If I'll ever be
2026-07-06 09:56:50 <dave0       > in general i dont like backwards compatbility but i think windows really did make the right decision to support as much old stuff as possible
2026-07-06 09:57:41 <veltas      > I really hate unnecessary changes, like how much libraries change in major revisions without really adding any major features
2026-07-06 09:57:41 <iv4nshm4k0v > I've tried to learn how Firefox extensions work - back when it was still C++ (I think), and, well, I find that GNU Emacs extensions are *much* easier to write.
2026-07-06 09:57:44 <dave0       > some of the articles by raymond chen go into it
2026-07-06 09:58:49 <veltas      > I love the OldNewThing, I think I've been reading that for a serious number of years now and regularly go back through the archives
2026-07-06 09:58:58 <veltas      > Old win32 articles are my favourite
2026-07-06 09:59:33 <veltas      > iv4nshm4k0v: May be more of a comment on firefox than C++
2026-07-06 10:00:27 <veltas      > In fact Netscape is one of the famous cases of a disaster rewrite
2026-07-06 10:01:27 <veltas      > And likewise firefox has a few failed rewrites in their history, and mozilla was a big driver of Rust early on
2026-07-06 10:01:43 <veltas      > So mozilla and netscape has a rich lore of not learning this lesson
2026-07-06 10:01:58 <veltas      > And now others are contracting the disease
2026-07-06 10:02:56 <veltas      > Don't get me wrong though, I am a programmer, I understand the desire.  I reinvent the wheel constantly and rewrite.
2026-07-06 10:03:45 <veltas      > There is value in realising that the language is just a tool, and all languages are flawed and leak abstractions and lack useful features.  There will never be a perfect language or codebase
2026-07-06 10:04:33 <iv4nshm4k0v > Part of my point is that GNU Emacs is developed differently to Firefox, /and/ I cannot help but think that it's partly because they use C as their "core" language: they cannot do complex coding without namespaces and templates and whatnot, so they /have/ to do it in their "extension" language instead.
2026-07-06 10:04:33 <iv4nshm4k0v > The result is that GNU Emacs effectively /is/ a bunch of extensions, and that helps a lot when writing new ones.  Or did help a lot back when I've used it - from c. 2001 to c. 2020.
2026-07-06 10:06:33 <veltas      > Would it be fair to say that C provides the 'kernel' of emacs, in Forth terms?
2026-07-06 10:06:48 <veltas      > How much of emacs is written in C vs lisp?
2026-07-06 10:10:18 <iv4nshm4k0v > Never actually measured it, but, basically, the display engine and whatever is needed to be in C for performance reasons.  I've started with Emacs 20 and one of my first extensions to it was an IRC client, for instance - so parsing / serializing IRC messages, dealing with sockets - that typically gets done in Emacs Lisp.
2026-07-06 10:10:49 <iv4nshm4k0v > SMTP, IMAP, NNTP clients were already there, IIRC.
2026-07-06 10:12:36 <iv4nshm4k0v > Just checked, emacs-21.4/*.el is 65e4 LoC, which is about twice emacs-21.4/*.[ch] - 36e4 LoC.
2026-07-06 10:14:51 <veltas      > You wrote an IRC client for emacs?
2026-07-06 10:15:55 <iv4nshm4k0v > A very crude one, but one I've used myself, if briefly.  The last version of GNU Emacs I've used came with two IRC clients - the simpler rcirc, and the way more featureful and complex ERC.
2026-07-06 10:17:03 <veltas      > Nice
2026-07-06 10:17:05 <iv4nshm4k0v > (I haven't had much interest in IRC until about 2019, mostly sticking to NNTP instead.)
2026-07-06 10:17:41 <veltas      > Do you still use NNTP?
2026-07-06 10:17:51 <iv4nshm4k0v > Every once in a while.
2026-07-06 10:19:36 <veltas      > I've not bothered with it much, but have read a lot of archives
2026-07-06 10:20:05 <veltas      > Quality just gets worse, too many crazies
2026-07-06 10:20:34 <veltas      > And people with never-ending drama
2026-07-06 10:21:24 <veltas      > I guess IRC is similar but it feels easier to duck out of IRC when you're bored with the conversation
2026-07-06 10:23:06 <deadmarshal > https://barenakedgames.com/forth/index.html
2026-07-06 10:24:20 <iv4nshm4k0v > Netnews is a relatively simple technology, easy to implement, and I find it more convenient than mailing lists thanks to its "shared mailbox" nature.  Killfiles are a must, though: unlike IRC, unmoderated newsgroups do not have "operators," so as long as the participant keeps to the rules of /their/ server, anything is a fair game.
2026-07-06 10:27:48 <veltas      > I find it quite sad how netnews and IRC have just been endlessly reimplemented and now the most popular forms of this are proprietary walled gardens run by a small handful
2026-07-06 10:28:22 <veltas      > I guess it's especially sad how unpopular netnews/IRC are among hackers and open source / free software
2026-07-06 10:37:20 <iv4nshm4k0v > Netnews have their issues - some of them stem from its distributed nature.  E. g., a person making a post might want to have some estimate of its popularity - number of views, likes; and a person reading a newsgroup might want to take a look at the popular posts there first.  Not something that netnews can do, all things considered.
2026-07-06 10:37:20 <iv4nshm4k0v > Otherwise, yes, it's sadly not uncommon for free software developers to rely on some proprietary walled garden resource.  Though the one that bothers me the most is not, say, Slack or Telegram - it's Github.
2026-07-06 10:40:45 <veltas      > Surely netnews could do that but would depend on the network logging / distributing that info?
2026-07-06 10:41:44 <veltas      > Why github?  You can download the git repo from github and if you emailed me a patch I would give it the same weight as a PR on the site?
2026-07-06 10:42:13 <iv4nshm4k0v > Can I download issues from Github?
2026-07-06 10:42:44 <veltas      > Yes with a web browser (right?)
2026-07-06 10:43:06 <veltas      > I do sometimes ponder whether it's better to have a TODO file in the repo
2026-07-06 10:43:37 <veltas      > Likewise if someone emailed me about an issue I'd add it there, while I'm still using github issues
2026-07-06 10:43:41 <iv4nshm4k0v > With one of the Big Three browsers, you mean?  I can download Debian BTS - whole or in part - with rsync(1), and I can open a Debian Bug simply by writing an email.
2026-07-06 10:44:27 <veltas      > I do agree the web is too fat and github definitely is not a lightweight site, but I don't understand why it bothers you more than slack/telegram
2026-07-06 10:45:35 <veltas      > Maybe I should mirror issues elsewhere, or better yet mirror github issues from elsewhere
2026-07-06 10:45:50 <veltas      > Like a TODO file on my site
2026-07-06 10:45:55 <iv4nshm4k0v > Because I find pointers to Github far more common than pointers to proprietary IMs.  Might be related to my interests in software at large: lots of what I'm interested in has IRC channels and (or) mailing lists.
2026-07-06 10:46:13 <veltas      > As I said if you email a bug to me I would actually add it, although that's just me, I'm sure most wouldn't
2026-07-06 10:47:13 <veltas      > I will have to think about what you've said iv4nshm4k0v, maybe I can add more open routes to my software
2026-07-06 10:47:45 <veltas      > The main thing I'm working on in spare time right now isn't really git-based anyway, I'm mostly using snapshots for backup and github for an offsite backup
2026-07-06 10:47:53 <veltas      > I guess I can release it on my website
2026-07-06 10:47:55 <iv4nshm4k0v > That's good to know, but I've got an impression some Github projects don't even have a contact email.  Or a public, non-proprietary resource to ask around whether what I observe is even a bug.
2026-07-06 10:48:10 <veltas      > It's all block based so doesn't play with git anyway
2026-07-06 10:48:20 <veltas      > I'm enjoying block editing
2026-07-06 10:48:46 <veltas      > Have mostly written my Z80 assembler that I will use to cross compile my ZX Spectrum Forth hopefully
2026-07-06 10:48:57 <veltas      > One of these dreaded rewrites I've warned against
2026-07-06 10:50:44 <iv4nshm4k0v > As to netnews, tracking popularity would depend on the /entire network/ adopting a standard for the exchange of that information - something unlikely to happen (some would object on privacy reasons, some would find adding code to their servers too much pain for too little gain) - and then we also need to track and mitigate possible abuse.  (A rogue server may say that a given post had 1e10 views.)
2026-07-06 10:53:59 <veltas      > I'm happy with how simple my assembler seems to be, and it's not incredibly far from the original syntax
2026-07-06 10:54:06 <veltas      > I think it would make some sense
2026-07-06 10:54:19 <iv4nshm4k0v > ... And then presumably we would want to make that information available to netnews users, which means adding such a feature to all the dozens of newsreaders out there, too.  How many IRC clients support IRCv3 features, anyway?
2026-07-06 10:54:39 <veltas      > The worst thing though is the hack I've used to allow C (i.e. the 8-bit register C, and also 'carry' condition) to use the same value
2026-07-06 10:55:27 <iv4nshm4k0v > JFTR, I have little trouble with Github as a Git hosting proper - not something I would put /my/ code on (any HTTP server can host a Git repository for "$ git clone " - and I've already joined http://sdf.org/?join ), but any project that requires me to become a Github user myself would get a firm "no" from me.
2026-07-06 10:55:48 <veltas      > Which is the arguments are XOR'd with the opcode, so some of my opcodes are 'wrong' to produce correct value when it's XOR'd
2026-07-06 10:57:12 <veltas      > I think that's fair, git is designed to work well with just email and a way to send the repo as a file, so why would someone require signing up to a separate website
2026-07-06 10:59:32 <iv4nshm4k0v > There's the Git workflow, and then there's the Github workflow.  Some people have adopted the latter and see little value in allowing for their contributors to "go against the flow."
2026-07-06 11:00:15 <veltas      > I've struggled to refactor my DOES> opcode-defining words, I'll probably request refactoring advice when it's finished
2026-07-06 11:00:31 <veltas      > Varing DOES> words often fail to refactor nicely though
2026-07-06 11:00:35 <veltas      > varying*
2026-07-06 12:48:43 <cleobuline  > https://labynet.fr/videos/dentrites.mp4
2026-07-06 14:30:51 <cleobuline  > for ppl having a macos https://github.com/cleobuline/maccam-6/releases
2026-07-06 14:44:54 <veltas      > On about 7 blocks for the Z80 assembler
2026-07-06 14:45:32 <veltas      > Don't know if that's good or not, doesn't seem extremely verbose
2026-07-06 14:45:44 <veltas      > 7 screens I mean
2026-07-06 14:53:05 <veltas      > Found https://gitlab.com/leah_u/ZI28
2026-07-06 14:53:17 <veltas      > Looks good, assembler is similar kind of verbosity to that repo
2026-07-06 14:53:34 <veltas      > Well apart from words at bottom, there's is much more verbose there
2026-07-06 14:53:41 <veltas      > But it's not a competition
2026-07-06 14:53:52 <veltas      > Interesting project, Z80 computer
2026-07-06 14:54:51 <veltas      > theirs*
2026-07-06 14:55:22 <veltas      > Why do I recognise their name, have they been in here?
2026-07-06 14:59:01 <cleobuline  > simulation of sound waves with my machine https://labynet.fr/videos/ondes-sonores.mp4
2026-07-06 19:02:30 <xentrac     > veltas: this friend is working on another alternative to Rust called Carbon
2026-07-06 19:03:35 <xentrac     > Google routinely rewrites stuff in new versions of C++
2026-07-06 19:04:56 <xentrac     > so they also sort of agree that rewriting things in Rust would be a mistake
2026-07-06 19:08:13 <xentrac     > though with LLMs I'm not sure that's true anymore; they're dramatically better at translating between languages than they are at writing new code
2026-07-06 19:14:15 <veltas      > Rust is not a straightforward translation of C++ at all though
2026-07-06 19:14:29 <xentrac     > no
2026-07-06 19:14:36 <xentrac     > Carbon is supposed to be
2026-07-06 19:15:53 <veltas      > What is advantage over safe C++ memory extensions l, ubsan et al
2026-07-06 19:15:58 <veltas      > static analysis
2026-07-06 19:16:28 <veltas      > s/ l/
2026-07-06 19:18:26 <lofty       > To me it looks more like Carbon is designed to straightforwardly interoperate with C++ than be a straightforwardly translation thereof
2026-07-06 19:25:35 <veltas      > I know a lang with straightforward C++ interop
2026-07-06 19:26:03 <veltas      > ;-)
2026-07-06 19:44:06 <veltas      > Why are projects instantly uninteresting when they are made with AI?  As soon as I see that I don't care.
2026-07-06 21:12:14 <crc         > I'm going to put together something in konilo for catjam-2026, though I don't know what yet
2026-07-06 21:37:39 <xentrac     > veltas: it's much more straightforwardly translatable from C++ than Rust is
2026-07-06 21:39:46 <xentrac     > Rust doesn't have, for example, inheritance or mutable aliasing
2026-07-06 21:44:40 <veltas      > No but I mean xentrac what's the advantage of Carbon over C++
2026-07-06 21:44:49 <veltas      > I like the name
2026-07-06 21:44:51 <lofty       > xentrac: you can use UnsafeCell for the latter; it's pretty core to the language.
2026-07-06 21:47:42 <xentrac     > the purported advantage is mostly memory safety, I think
2026-07-06 21:48:49 <xentrac     > I'm watching a talk on it on Google Meet right now
2026-07-06 21:55:02 <xentrac     > maybe also thread safety?
2026-07-06 21:57:54 <lofty       > It doesn't obviously look borrow-checked, and Google have previously demonstrated it's possible to have memory safety without thread safety (Go), so, I guess we'll see?
2026-07-06 22:03:08 <veltas      > it looks like it's got similar lifetime/borrow stuff to rust
2026-07-06 22:03:10 <veltas      > at a glance
2026-07-06 22:04:51 <veltas      > But then how easy can it be to convert C++ to it, given C++ often isn't laid it in a thread-safe ownership model (usually it will just be serial memory-safe by default with smart pointers, RAII, avoiding unnecessary raw pointers, checking bounds, using iterators etc)
2026-07-06 22:05:07 <veltas      > Proof's in the pudding
2026-07-06 22:10:58 <xentrac     > their "places" approach is in some ways similar to Rust's lifetime checking, but it's sort of space-oriented rather than time-oriented
2026-07-06 22:11:59 <xentrac     > so it's more similar to C++ in a sense
2026-07-06 22:33:53 <xentrac     > these are the slides from the talk: https://chandlerc.blog/slides/2026-memory-safety-deep-2/#/
2026-07-06 22:43:12 <veltas      > Surely it's cheaper and easier to add this to C++ with new syntax and compiler options
2026-07-06 22:43:43 <veltas      > Maybe not but it seems like that would be the more iterative route
2026-07-06 22:44:10 <lofty       > Unfortunately the committee isn't interested in that
2026-07-06 22:48:56 <xentrac     > I really doubt that that would be cheaper and easier
2026-07-06 22:50:45 <veltas      > I'm just thinking about the sheer amount of C/C++ code out there, that tips it for me
2026-07-06 22:52:25 <veltas      > And all the tools that make it safer, and things like Fil-C
2026-07-06 22:52:38 <veltas      > The proposals for safe C++ seem reasonable
2026-07-06 22:52:58 <veltas      > I wouldn't be surprised if it happens through compiler devs rather than via the committee
2026-07-06 22:53:06 <lofty       > do you mean as in Sean Baxter's Safe C++ (aka Circle), or "safety profiles"?
2026-07-06 22:53:58 <veltas      > Like Sean Baxter's proposal yeah
2026-07-06 22:54:29 <lofty       > yes, see, that's reasonable, so the committee has rejected it
2026-07-06 22:55:05 <veltas      > I just said it doesn't need to happen via committee
2026-07-06 22:55:36 <lofty       > the standard is kind of the whole Thing about C++ though
2026-07-06 22:56:36 <veltas      > If a compiler dev does something similar and demonstrates it then it can get better traction than a proposal
2026-07-06 22:56:50 <lofty       > well, Sean wrote Circle
2026-07-06 22:56:54 <veltas      > And just because a proposal's rejected doesn't mean it can't be refined and come back in a form people are more willing to accept
2026-07-06 22:59:09 <veltas      > Circle is the kind of thing I think that should have more energy behind it
2026-07-06 23:47:18 <xentrac     >  I think the whole Thing about C++ is mostly backwards compatibility: it will compile your code from 2 or 5 or 10 years ago, probably 20, probably not 30
2026-07-06 23:47:25 <xentrac     > unless it's C code from 30 years ago
2026-07-06 23:48:45 <xentrac     > but also you get a combination of good absolute efficiency and expressivity that's hard to beat along both axes
2026-07-06 23:49:03 <veltas      > My experience with 30 year old C code is most of it doesn't work
2026-07-06 23:49:49 <veltas      > The main culprit is non-standard compiler treatment of volatile following C++'s semantics, ANSI C adopted a much more limited version
2026-07-06 23:51:39 <xentrac     > most C code doesn't use volatile at all tho
2026-07-06 23:51:44 <veltas      > Like you used to be able to do `(volatile int)x`
2026-07-06 23:51:54 <veltas      > Most of the 30 year old C code I've tried does
2026-07-06 23:52:24 <veltas      > Mostly been firmware but ran into the same issue trying to build old versions of GCC even
2026-07-06 23:53:05 <xentrac     > like, if productos is a std::unordered_map<string, proveedores>, you can say:
2026-07-06 23:53:07 <xentrac     >   auto p = productos.find(producto);
2026-07-06 23:53:07 <xentrac     >   if (p == productos.end()) throw NoSeEncuentra(producto);
2026-07-06 23:53:41 <xentrac     > and get a hash table lookup that's about as efficient as if you were to write it in C
2026-07-06 23:54:14 <xentrac     > yeah, as the size of your code base approaches infinity the probability that it will contain `volatile` approaches 1.0
2026-07-06 23:54:27 <xentrac     > (if it's in C)
2026-07-06 23:54:35 <veltas      > Absolutely (as long as you don't use std::unordered_map and write your own hash, because my C hash tables are way faster than those)
2026-07-06 23:55:09 <xentrac     > hmm, I guess I haven't actually benchmarked std::unordered_map against my C hash tables
2026-07-06 23:55:18 <xentrac     > but it's possible mine are slower than yours anyway
2026-07-06 23:55:57 <veltas      > But C++ allows you to express whatever you'd do in C in a much cleaner way
2026-07-06 23:56:15 <veltas      > Ignore the fact that the standard library containers aren't super performant
2026-07-06 23:56:24 <veltas      > You're not stuck with them
2026-07-06 23:56:47 <xentrac     > well, the main thing I think is that the STL lets you decompose your code in a more orthogonal way than C does without imposing (much of) a performance penalty for it
2026-07-06 23:56:57 <veltas      > Yes the big feature of C++ is that it's sort of backwards compatible
2026-07-06 23:57:23 <xentrac     > or I guess the generic programming approach exemplified by the STL
2026-07-06 23:57:41 <veltas      > Yes
2026-07-06 23:58:33 <xentrac     > the code isn't very readable, though, and it's pretty error-prone
2026-07-06 23:59:41 <veltas      > Really depends