Hacker Newsnew | past | comments | ask | show | jobs | submit | codethief's commentslogin

What toothbrush do you have? I've been looking for a USB-C charger for mine (standard Oral-B toothbrush) but the only ones I've found were from no-name Chinese brands and didn't work at all.

This one. No separate charger, just plug the USB-C cable in to the toothbrush.

https://www.amazon.co.uk/gp/aw/d/B0F8BD3922



> Meanwhile, some projects are doing the opposite, like going from Rust to Zig, here's an example from a podcast I recently listened to: https://www.youtube.com/watch?v=XSXGf3oN2yU

Thanks for the link! Unfortunately, contrary to what the title suggests, that video seems to be more about AI than about the migration? (Sigh…) I did, however, find the following document where they explain why they migrated to Zig. It makes for a nice read: https://gist.github.com/rtfeldman/77fb430ee57b42f5f2ca973a39...


That's all good and well but the UX sucks. I usually have dozens of commands like

  git commit -m "PROJECT-XXXX Foo the bar to baz the qux"
in my shell history, which means 1) I can easily create follow-up commits under the same ticket number (no having to type the ticket number again), 2) I don't have to keep remembering the ticket number once I created the first commit on the given ticket. I'm sure I could set up an elaborate set of shell scripts and git aliases to auto-insert a ticket number as structured data at the bottom of each of my commits. But good luck convincing the rest of your team to do that.

Also, having the ticket number in the subject line means every git-related tool I use will always display it (even if the rest of the message gets cut off).


> Of course when we switched to GH issues, we largely abandoned JIRA and years later the instance got turned off and deleted. Now all those JIRA tags are entirely useless.

I agree that this is a problem but at the same time associating commits with a ticket number is useful, especially if I have dozens of commits on a single ticket and am doing trunk-based development (so not all commits are on the same short-lived branch). Maybe the lesson here is that, once completed, tickets should be exported and stored in the Git repository.


Do we know what the situation looks like with other popular indices such as MSCI World, MSCI ACWI, MSCI ACWI IMI, FTSE All-World, …? Do they have any requirement of 12 months of trading or of profitability or similar?

> to settle bar bets

As I learned just yesterday, this is exactly how the Guinness World Records books came about. :)

https://en.wikipedia.org/wiki/Guinness_World_Records


Right but how would you even display a vertical menu back then? `float: left` was rather bad, so you went back to using tables[0]. Good luck making these responsive.

[0]: and to using dozens of images sliced to fit your table cells, for that cool hover effect as well as round corners. :-)


Why would documents have menus? Menus are for applications.

And there was nothing wrong with tables for layout, especially back then when the alternatives were very brittle.


> Why would documents have menus? Menus are for applications.

s/menu/navigation

> And there was nothing wrong with tables for layout, especially back then when the alternatives were very brittle.

I never said there was anything wrong with tables. OP said there was nothing preventing the design from being responsive, to which I responded yes, there was, at least in a lot of cases.

(Responsiveness was also mostly irrelevant back then because smartphones were not a thing yet.)


I had the pleasure to talk to Loris about this topic just last week and I've liked his take very much.

His point is not coming from a place of LLM demonization. He very much acknowledges their usefulness, especially in a business context, e.g. for implementing yet another standard CRUD application and for shipping all the other "average" (in quality) business features quickly.

His point is a different one entirely: Say Andrew Kelley is attending the Zig Day. Why would you ask an LLM about a Zig programming problem you're struggling with instead of learning from the man himself? There's simply no LLM as knowledgeable about Zig as Andrew and the other people working on it or with it on the daily.

In other words: Zig Days are an opportunity for people to learn from each other and to spend time together (= the "Community" in "VP of Community"), and LLM are diminishing this opportunity.

Besides, Zig itself is mainly a language for people who care not just that a problem is solved but also about how it's being solved. ("Create software you can love.") While LLMs don't prevent anyone from doing so, they make it much more appealing to just vibe-code everything and not look too closely at the implementation.


Being negative against the utility of AI is sometimes besides the point or a strawman (don’t know about this instance). Only an idiot would argue that cars don’t have utility in cities and countrysides that are already paved over. Or that they are slower. Or that the train can get you from Bob’s to Burger Establishment with less walking. But they may want other things like more walkable cities and less mass extinction in a hundred years time.

No one needs to proclaim the utility of The Car before criticizing car culture.

This piece already says that all the clanker maximalism may be correct. shrugs Then it says that this get-together is for people who like programming. Even if the whirlwind of progress comes and takes their profession. Because then it could still be a hobby.

And this is too negative-against-AI for some people in this thread? Programming as a hobby? Okay, fine. Maybe we will have sold off all our RAM in a years time and the Government will have outlawed unassisted programming as too dangerous. The piece is too optimistic.


> What's needed is a global "Hide AI Dreck".

As a German, I couldn't think of a more appropriate usage of the word "Dreck".


It's a bit of a shame, given the brilliance of the the word "dreck", that we've somehow ended up with "slop."


Interesting talk, thanks for sharing!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: