allochthon

I have a hobby project on the side involving radio digital signal processing in Rust that I've been pure vibe coding, just out of curiosity to see how far I can get. On more than one occasion the hobby project has gotten bogged down in a bug that is immensely challenging to resolve. And since the project isn't in an area I have experience with, and since I don't have a solid "theory of the program", since it's a gray box because I've been vibe coding it, I've definitely seen CC get stuck and introduce regressions in tricky issues we previously worked through.

The use of Claude Code with my day job has been quite different. In my day job, I understand the code and review it carefully, and CC has been a big help.

I've had some success with a multi-threaded software defined radio (SDR) app in Rust that does signal processing. It's been useful for trying something out that's beyond my experience. Which isn't to say it's been easy. It's been a learning experience to figure out how to work around Claude's limitations.

Me too, but a more optimistic view is that this is just a nascent form of higher-level programming languages.

I like this take. I feel like a significant portion of building out a web app (to give an example) is boilerplate. One benefit of (e.g., younger) developers using AI to mock out web apps might be to figure out how to get past that boilerplate to something more concise and productive, which is not necessarily an easy thing to get right.

In other words, perhaps the new AI tools will facilitate an understanding of what can safely be generalized from 30 years of actual code.

Overall I like the list. Some of the bullet points were stated a little more strongly than I was comfortable with.

People who stress over code style, linting rules, or other minutia are insane weirdos

I feel like programmatically enforced linting is like keeping a shared house clean. Suppose you live in a house with roommates. You wipe off the counters, you clean up after yourself, you put dishes in the dishwasher, so that the house is tidy and pleasant. If there's a lint or style rule that requires judgment and is hard to enforce programmatically, perhaps better left as an occasional PR comment.

Programatically enforced linting also has the benefit of removing degrees of freedom that aren't very important and don't merit getting bogged down about.

As someone who used Windows 95 when it came out, it struck me at the time as an off-brand Macintosh, making it feel kind of cheap (a feeling that never went away). I had also been using X Windows by way of SGI's workstations around that time, and IRIX felt clean, if a little old-school, by contrast.

I think there's plenty of scope for improvements like this. I haven't had the energy to pursue further improvements along these lines, but I suspect they could make it a better app.

My own purpose in using it is to be able to get back to any link that I've read or have potentially wanted to read at a later point in time. You scan see screenshots here: https://github.com/emwalker/digraph.

It's pretty manual at this point. The indexing is done by hand. The idea is kind of crazy, but I think it can be made to work, in the same way that Wikipedia is maintained by hand.

https://digraph.app/

https://github.com/emwalker/digraph

If you can crowdsource the indexing, you get yourself a manually curated search engine with a nice topic graph that can be traversed. A piece of this puzzle that hasn't been tackled yet is a reputation system to keep the signal-to-noise ratio high and deal with spam.

What’s an example use case of where you use that system to find a link?

An example use case is that I come across some interesting long-form article on a topic I'm following, e.g., Shackleton's expedition, that's published on a nice website and that I don't have time to read. I can just drop the link in the right topic and get back to it without too much difficulty. Or that's the hope, anyway. (Doesn't always work out that like that.)

Another thing I'm interested in is what the topic structure ends up looking like as it's more fully fleshed out. So sometimes I'll drop in random links even if they're not that interesting, just to build out the topics.

I built a web app that keeps track of every link I ever find to be interesting. It allows for fine-grained topics (e.g., individual academic papers, or topics more specific than that). It groups the topics in a DAG, so that you can get to a topic via more than one path from the top. And it allows you to look at intersections of transitive closures over topics in order to narrow down a search.

It keeps a history of every change to the graph in Git, so one day you could potentially implement some form of time travel and see what the graph looked like at an earlier point in time without too much difficulty.

I have used the app every day for years. I feel like there's something promising there that is of general interest, but I have not figured out how to communicate the value.

A little depressing to see GitHub join the zeitgeist. Probably mandated from above by Microsoft. The next time I'm on a job search, I'll be de-prioritizing, and possibly even excluding, those tech companies that laid people off in order to signal to investors that they had their finances under control. I was kind of attached to GitHub, though, so this is disappointing.

I'm an experienced Ruby web developer, and I'm starting to learn Rust. You mentioned Java and Nodejs, but I still wanted to chime in on the topic of languages in web development more generally, and the applicability of Rust to web development.

After tackling the refactoring of a complex Rails app that has a rules processing engine implemented on top of ActiveRecord, the true cost of Ruby's lack of static typing has become apparent to me. It's clear now that you can get a web app up and running quickly in a framework like Rails (as one example of a convenient, low-friction framework). But once you need to turn it inside out and make significant changes to the implementation, you're walking on egg shells and relying on previous devs to have built out good test coverage. A web app written in Rust would be easier to refactor in important ways at this point in the life of the app. It is clear there was a cost to using Ruby, but also that it was deferred.

Over the last decade I've had a similar thought and hope. Or at least the idea of working for an employee-owned and directed tech business (maybe on the model of REI?). Curious whether anyone knows of any successes in this area with respect to the tech industry?

I recently watched this intro to the topic, which I found really interesting: https://www.youtube.com/watch?v=bnnacleqg6k

The kind of company I'm on the lookout for has definitely shifted over the years. When I was younger, the thought of working at Google and Amazon was very enticing. Then Amazon adopted some fairly regressive HR and business strategies and lost its luster in my eyes; or maybe my view of their existing practices just shifted as I grew older. Now Google is trending in the same direction. At this point in my career I'm on the lookout for smaller companies that are oases and have somehow managed to avoid the HR and business trends that have been adopted by the tech industry on the model of people like Jack Welch, the consulting firms and private equity.

I had a similar reaction. Acquisitions can be a signal that there's a go-to-market strategy being pursued.

That being said I never understood why would anyone want to use this language for web development

On the backend, at least, Rust would be a significant improvement over Ruby, for example, once a business has gotten past the initial prototyping phase. I've spent years in Ruby development, and the duck typing makes refactoring a production system scary and drama-prone. No matter how carefully you proceed, there will be gaps in test coverage, and you'll regularly see new bugs in production from the refactoring work that would never happen in a typed language. I would gladly work in Rust over Ruby in a web development context. (Although my preferences lean towards Rust, there are no doubt many other typed languages that could do a good job here as well.)

I have the same habit and wrote a web app to catalog the links I come across:

https://digraph.app/

I do expect that even unreliable versions will be very useful tools for practicing lawyers, though.

Agreed. It's like being able to call up a map on Google Maps for an area that you're already familiar with. The map can help you remember things about the area and terrain that you might not have recalled right away. A kind of cognitive aid.

Yeah, that's actually related to what I'm thinking of. The idea is a crowd-sourced and well-executed iteration on the old Yahoo! directory.

https://blog.digraph.app/2020-06-13-democratization-of-searc...

I'm hoping that eventually we'll get around the idea of a crowd-sourced search engine (mostly manually curated) maintained in the manner of Wikipedia, backed by a solid user reputation system to dissuade spammers.

This will import Wikipedia's serious flaws. But I'm hopefully that they can gradually be mitigated.

For this reason, I have tended to rely more and more on recommendations from obviously real people these days, e.g., as found in comments on Reddit, or in the New York Times's Wirecutter. The challenge with this approach is that Reddit seems to be gamed more and more by industry and other PR "bots", which makes it hard to sift wheat from chaff. But if the subreddit is not on a controversial topic, it's still possible to find disinterested recommendations, or so it seems.

I tried helmfile, but helm state weirdness became enough of an issue that I investigated `kubectl apply -k` (which uses `kustomize`), and after I got it working it felt like a significant improvement over helm+helmfile. (But I still use `helm` to generate manifests.)

I recently discovered `kustomize` and the `kubectl apply -k` flag (which uses `kustomize`), which makes keeping full manifests pretty straightforward. There's only one or two things I dislike about `kustomize`, but those are things that can be worked around.

Sometimes the New York Times editors have fun with the titles of lighter articles, in a good way

I am waiting for services to give up on purely algorithmic approaches and start exploring recommendations based on other users whose tastes the user likes. Even better if you could have different clusters of selected users for different occasions.

Typically there's a way to suppress specific warnings in systems like these. In your company's situation, I would look at moving away from a scanning system if it didn't allow overrides like this.

My Gmail account is an early one, and several times a month, emails intended for other people with the same name end up in my inbox. Some of them are from actual people; a lot of them are from services that don't do a proper email verification step. It also seems one strategy of script kiddies is to add lists of emails they obtain to legitimate services that don't do an email verification step. I'll flag these messages as "spam" even if they're from some well-known company.

In the past few months, things appear to have changed, and emails that are obviously spam, complete with the misspelled titles and funky case and punctuation, are now appearing in my Gmail inbox. It looks like the Gmail spam filter is becoming less effective.

I would love for email to be opt-in on a per sender basis. If I haven't opted-in to receive email from someone, perhaps a request is added to a queue that I can check from time to time (with its own spam filter), and until the request has been accepted, no email will arrive from them.

There's definitely a contingent in the HN comments with a bit of an antisocial streak. I wish people approached comments they take issue with with more of a pedagogical approach, starting with interpretive charity and trying to help the commenter see things in another way.

I'd actually use the term "welcoming" in this context.

This was kind of the idea behind a side project I started a few years ago:

https://blog.digraph.app/2020-06-13-democratization-of-searc...

In that post, I don't address the reputation management aspect as much, but it's central to making the whole thing work, and I think crowd-sourcing and a well-conceived reputation management system that can influence results are good next areas for exploration.

There's disincentives for Google to do the right thing, for sure, e.g., ignoring quotation marks. I assume this is so that you never see a blank page (and so ads can be shown, which would be weird to see if there were no other results).

But, as the author mentioned, a lot of the problem is the inauthentic content on the internet that Google must sift through and filter. What makes Reddit still not half-bad (although this quality is under direct attack by brigading and troll farms) is that you have user-generated, user-curated content and a not-too-bad voting system.

In this context, I think a future iteration on search engines will be hand-curated results, under actual human-curated topics (rather than fuzzy machine-learning-inferred ones). Think of a huge directed acyclic graph of topics that goes down twelve levels or more in some cases. If you have enough people involved in this kind of crowd-sourcing, I think it can be made to work.

A challenge that arises in this context is how to prioritize content added to the wiki search engine by good contributors, and deprioritize content added by the content farms. I think this can be managed with a combination of well-conceived reputation management and providing users the ability to specify other users (people who seem trustworthy and whose tastes are solid) whose preferences will then be used to weight search results.