oooyay

I don't think this kind of attitude is necessary. I do this work for free, there are no bragging rights in maintaining an IRC client. I maintain this client because there are zero options for clients that look and behave the same across operating systems, are modern, and customizable.

You're welcome to open a PR and participate.

I live in Portland and we've recently committed to moving back to Bay Area because of this exact reason. The remote market that made it possible for me to live here is dying. There are also not many, if any, businesses in Portland that I'd work for that pay market rate.

Would Claude have found it without your guidance and knowledge? If yes, Claude found it. If no, you found it while using an LLM.

I suspect a lot of things fall into the latter. It is a common neg to defer everything to the former though.

> Sure, Wails is lighter compared to Electron, but it's still not as lightweight or efficient as a native app.

Yeah, I think that's fair. I don't think about resource utilization in a vacuum: native apps require I develop three different apps and likely have a lot of CGO dependencies. With Wails and the OS WebView the same client you're used to using on MacOS should work the same or similarly on Linux and Windows within reason. They should also all maintain similar resource utilization profiles. That's why I said it's limited in its footprint, I'm not here to compete with native library performance and native library performance isn't trying to compete with my ability to cross-compile.

    Process                         PID     Avg CPU    Footprint (MiB)
    ------------------------------  ------  ---------  ---------------
    Cascade                         45314      0.46%              73.0
    WebKit WebContent               45349      0.50%             392.9
    WebKit GPU                      45347     <0.01%              26.1
    WebKit Networking               45348      0.02%               6.5
    Nick completer plugin           45344     <0.01%               2.8
    Nickname colors plugin          45345     <0.01%               9.7
    ThemeWidget service             41353     <0.01%              10.1
    SafariPlatformSupport helper    41355     <0.01%              13.1
    ------------------------------  ------  ---------  ---------------
    Total                                     1.00%             534.2

I'm currently connected to four networks for 6 days and 18 hours. Compared to other native apps on the same system:

    App           Main PID  Uptime        Avg CPU  Main MiB  Total MiB
    ------------  --------  ------------  -------  --------  ---------
    Cascade          45314   6d 17h 45m     1.52%      73.0      556.8
    Proton Drive     22091  11d 04h 32m     0.15%      48.0       65.1
    Ghostty          78285  27d 22h 03m    <0.01%     173.6      184.2
    Finder            1308  34d 19h 32m     0.05%     104.4      104.4

so, if I rewrote the application into three separate applications I could probably save ~200 MiB of memory footprint. I'll look into my ability to slim down the memory utilization but some chunk of this is probably the message buffer of each channel.

heh, I'm not sure of your particular beef with these two but I'll use this as an opportunity to explain my rationale.

I obviously write a lot of code in Go but as a language it's also a really nice pairing with the IRC protocol. The way you write abstractions and tests just lends itself so well to writing desktop applications. On the other hand, writing UIs in Go (which I've tried in a multitude of ways) is just a really poor fit because asking Go to emulate Elm architecture is very clunky.

From my perspective, UIs are side effect driven code and demand a language that can fit that paradigm not just well, but great. Anything else I would or could have chosen would've required way more CGO dependencies than I have (of which I only have 1 atm) and would have read worse when I tried to hook it into Go.

Conversely, Wails' bridge to Typescript and React is very simple to use, reliable, and keeps up with the performance and consistency demands on an IRC client. Tailwind is also just very good at making compatible CSS; I was inspired by the use of QT in modern car infotainment systems in my selection of a component-based CSS approach.

Lastly, the whole thing is compiled into the binary that you download and makes no external calls on its own. It's all built on top of the OS WebView rather than a third-party browser the way, say, Electron is.

Thank you! Would love your input

I think at this point assessments like this are more qualitative than quantitative. I use Codex far more than I use Claude for coding and my results are generally higher quality. I would not, however, go to someone and tell them that Codex is better than Claude generally. In large part it depends on how you use the model and the harness.

> Perceived performance is actual performance over expectations and the latter just keeps increasing over time.

This is true of all reliability and performance paradigms, incidentally

IRC is good in that it is open, durable, and slow moving. All of those points are intentional features that make it a stable cockroach in a nuclear world.

I briefly entertained building a modern chat experience on top of IRC when I came to this realization.

I think about this a lot and have reached the same conclusion Norman does. I do wonder if maybe our natural progression is towards something more akin to confidential computing and enclaves.

I'm not sure if it was any kind of official rule, but I worked at times in a JTAC capacity for troops in contact. I mention the last bit because it's very high stakes where seconds and minutes count a great deal more than when you do coordinated tactical strikes against strategic objectives like weapons caches. When I did that kind of work we had to have three eyes-on forms of contact. Often that was the calling troops, the observer (like an Air officer), and an air asset like a drone. They all had to independently describe the target, its orientation, and surrounding activity.

However you sourced your target is irrelevant to the activity at hand. When I first heard of this news I knew immediately someone skipped target verification or that it was simply no longer a policy of the DOD.

FTA

    "Finally, we just uncovered that an AI botnet has discovered our pico services and are using it to communicate with other bots. Normally when we discover spam on our platform we simply move our services from the free tier to the paid tier. This has worked really well in the past and keeps our services feeling like a smol community. However, prose is a service we want to keep free because it's a great way to see how our services work. Therefore, we plan to introduce an invite system. Anyone can create an account but they won't be able to do anything with that account until they get an invite from someone within the platform. We plan to move pretty fast on this change since our discover page is completely flooded by bots. Once we move to an invite system we will likely re-open pgs.sh to have a free tier (and potentially our other services as well)."