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

On a semi-related note, I bought a Pixel phone about a month ago, and I'm shocked by how unpolished it is. I've had so many little annoyances pop up, issues I never had on other android phones. Keyboard hiding/appearing when it's not suppose to, bluetooth dropping, WiFi dropping, network switching taking forever, screen becoming unresponsive... It's mostly all small things, but they really start to add up after a while.

Mine's been mostly fine. Second hand Pixel 10 (previous 2nd hand 8a) and I am extremely happy with an excellent phone. No problems like you've had.

Interesting. My pixel experience has been the opposite; very polished and pleasant. 10A. Wonder why the variance?

Same. I was excited for a Pixel (assuming a much better Android experience) but had same experience as you

Seriously, just switch to Go or something

Rust didn't have nearly the industry adoption it does now back in 2020, but it was gaining traction in various parts of the community. If you learned it back then it was either because you love it, or you thought it had staying power.

I think Zig does, specifically because of its build system and it's C interopt story. Plus Zig has the added advantage that learning it teaches you about how the computer works, how memory gets laid out, etc. So even if it never gets wide adoption the skills are highly transferable.


Literally in the middle of ripping apart a vibe coded mess at work to figure out what's even worth keeping. Not fun :(

use ai to do that

Can't. It's a worse case scenario. It got vibe coded but I don't have access to AI tools to undo it. Basically the company was running a test on some tools, one engineer went ham and the thing ended up getting used, then the company decided to drop the ban hammer on the tools.

What happens if you just keep vibe coding is? Does it whack-a-mole fix one area and break another?

I have a lot of respect for Andrew, and I really enjoy Zig, but God that interview was awful. Andrews answers were fine, but the whole thing felt very sycophantic.


I didn't get the same impression. I'm curious to know what created that feeling for you. Perhaps I'm turning a blind eye to something or other?


There's a lot of little things that just added up, but I think the clearest example was the exchange regarding Andrew's pay from the foundation. I don't have an issue with him being paid for the work, or the amount he's taking, I would be surprised if anyone really did, but the way the interview asked the question came off as "Oh you're only making x? You should be paid so much more", and Andrew even commented in it saying "...it sounds like you're implying I deserve more...". I'm of course paraphrasing, but that's the impression I walked away with.

The questions also had a tendency to be somewhat shallow. There were a lot of places where it felt like the interviewer was queuing Andrew to respond to criticism or explain controversial choices made for the language or tool chain, but the interviewer doesn't really follow up on them are point out what the issues might be.

It might have been expectations I guess. I was hoping for an interesting technical interview and instead it seemed like a fluff piece.


As far as I'm concerned Bun has been extremely irresponsible with this entire rewrite, and it calls into question their entire development philosophy. Any project that cares about stability and reliability should steer clear of Bun for a while.


Congratulations to everyone who uses Bun. You're now working as alpha testers for Anthropic... for free.

Anyone using Bun should consider migrating away immediately. Not because of the LLM angle, but because of how insanely irresponsible this is.


I reviewed the million lines of code added in a week, and I'm horrified. Not running that thing on my machine.


The annoying thing about Rust, or at least the hype around Rust, is that people want to in use it for bloody everything.

We have absolutely no need for it at work. We're writing micro services that run in K8s with no extreme performance requirements. Nobody on the team knows the language (I know it better than the people arguing for it, and I don't know more then the basics). And yet, every couple of weeks, I'm having to talk someone out of switching certain services over to it. It's like a damn disease.


Because the attraction of rust is powerful. The same toolkit allows you to write code for a microcontroller or a full fat arm webserver, the rules are the same and the language is strong.

The best bit about writing rust is the reason why it kinda sucks for corporations. You can "finish" your code


Fair points, but this glosses over some of the not-great parts. Cargo isn't great. No sanctioned formal spec isn't great. Compilation times aren't great. Messing around with wrapping foreign types can be a bit of a bear sometimes.

It's a fine language, just like all the others. I'd rather write a web server in Go and a use C when targeting a micro-controller.

Almost reminds me of a quote I heard about python a long time ago: python is the second-best language for everything, and the "first-best" for nothing.


Sure, and that's probably because you are good with both Go and C. for me, I use rust as the hammer, and everything is a nail. Hobbyist vs Employee I guess


No, it’s for the reason you said. Not everything is a nail.


Thank you for so aptly demonstrating what I deal with at work.


also some of those people probably wanna put "used rust at work" on their resume


I feel like this article was circling a point it never actually got to. All the advice in here (except controlling scope creep) is specific to a TUI with an elm like architecture.

But here's the thing, you almost never know what the architecture is up front. If you do you probably aren't the one writing the actual code anymore. Writing the code, with or without an AI is part of the design process. For most people it isn't until they've tried several times, fucked it up a bunch, and refactored or rewrote even more that you actually know what the architecture needs to be.


This is awesome! I'll have to try reading through the code when I have more time.

It would be awesome to read a blog post about the project. Your approach, lessons learned, unexpected stuff, etc.


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

Search: