After writing web services, GUI apps and terminal apps professionally in Rust, I honestly struggle to see a use case for other languages.

"Write an SQL Repository with this interface"

Sweet - no need for SQLc or an ORM

At this point, I can't imagine a scenario not to use Rust for writing a web API.

How nice would it be if there were ReadAsync and WriteAsync traits in the standard library.

Right now, every executor (and the futures crate) implements their own and there are compat crates to bridge the gaps.

Not sure about vibe-coding it. While they aren't using v8, LLMs made it easier to understand v8 quirks and update v8 as they make weird changes every now and then. It couldn't write the runtime without help though.

For those curious: https://github.com/alshdavid/ion

IMO if you're profitable and have been around longer than a decade, you're no longer shipping features for survival and should have bandwidth allocated to improve the product reliability and performance.

No observability/monitoring, no automated testing, no CI/CD, a 30 second - 5 minute login time, and a 20mb JavaScript bundle is a pretty poor customer and developer experience.

I spoke to the head of sales / product to understand customer retention and the factors on failed sales - it looks like our customer retention is unaffected by a slow or unreliable the product.

At my last job, I was on 220k/y USD TC as a Sr.

This role is 140k/y USD, which is close to the top end of non big tech salaries here.

One colleague whom I have worked with in a previous role and has a similar mindset to me said that he just does the 1 PR a day and spends the rest of his time on OSS for satisfaction.

I took that onboard and have been ramping up my PR count over the last week without making suggestions - but I suspect the reputational damage has been done and I have soured relationships as, contrary to the 1 PR a day metric, my manager quizzed me on what I was doing after submitting my PRs in our 1:1.

Appreciate it and will certainly keep that advice in mind for the next role

I've got 13+ YoE and been working in big tech for about 4 years, joined an established start up (10 years old, profitable) a month ago, and wondering if I am out of touch after the meat-grinder that is competing for delivering "impact", stack ranking and so on.

I don't know if I should stay at this company as I feel like I can't really do good work here and it feels like, if I stay, I'll be less experienced at the end of 5 years than when I started.

-----

Soo

I joined an established start up a month ago, they have a legacy app they are incrementally migrating from Angular 1 to React.

Their "good" app is a super custom React implementation that's extremely difficult to understand, including some kind of component middleware and half baked Redux integration that doesn't work with any devtools.

The client is about 20mb of JavaScript shipped to the browser and the local development workflow is quite poor.

90% JavaScript, 10% TypeScript and the team doesn't really want to move to TypeScript, banning porting existing code to TypeScript.

There were some basic errors I noticed when I started, like not committing the package-lock to the repo so I asked about it and raised a PR adding one - which got declined because it was "risky".

The package-lock raised 60 critical vulns in the npm audit, which I raised and was told addressing them was too risky. I suggested that we should at least add a CSP to the app, given some of the vulns are implicated in injection attacks - again, too risky.

During development, hot reload times are 30s so I raised a PR that added `npm run dev:next` which uses Rspack to build the client only for development, which halved the hot reload time, but that was declined.

I noticed they don't have any automated testing (there's an overseas team the does manual QA before every release) and asked if they'd be open to building out an automated testing suite - to which they said no.

They also don't have any CI, all validation happens in a pre-commit hook, which they are also not interested in adding in.

I noticed they don't have any observability on the client - no error rate, no load times. I asked how they know if anything is wrong and apparently, if it's not caught in QA, "customers call us and we fix it". I suggested adopting something like Sentry to start tracking the client to help quantify the impact of features and preempt errors before they escalate and, again, was told no because it was "risky".

My manager had a 1:1 with me this morning and told me that I should not attempt to make contributions outside of the tickets I am assigned, and I am expected to raise 1 PR per day otherwise I will be let go.

I repeated my above concerns and he said that they hired me to do tickets and that was it.

Comments URL: https://news.ycombinator.com/item?id=47969140

Points: 6

# Comments: 28

But the US still doesn't have the right to repair hardware, haha.

I hope the EU is listening. They won't get far with their sovereign software push if hardware cannot be used. Even on the Android side, you can't write an alternative to Android because all of the hardware has locked bootloaders and hidden drivers. Good luck reverse engineering the hardware/drivers on a Samsung Galaxy - let alone an iPhone or MacBook.

Linux GUIs are _fine enough_ though the jank is still present. The good news is they will get better with more users entering the chat.

The thing to note is that, we don't want to confuse "it's not as good right now" with "It's bad so I will never use it" because that signals a lack of interest.

There is a non-zero chance that Apple could be compelled to support it if enough people express interest (historically, they have with bootcamp).

Competition is good, even if the competition is bad right now. We must encourage it.

- Screen

- Speakers

- The unbelievable trackpad

- Battery life

- GPU performance (Linux gaming on this would be amazing)

My assumption is that if they ever decided they would provide support for Linux, it would be a private Mac-linux fork.

It's hard to imagine they would go the shim + blob route like nvidia as that would still require upstreaming stuff.

Honestly, they should just document their hardware so we can write our own drivers without hurclean reverse engineering efforts.

If they wanted to go out of their way, they could spend a weekend writing Linux drivers - Apple have written Windows drivers in the past, so it's not unprecedented.

I believe the real hurdle is that Linux doesn't do well with modular (closed source) drivers. Unlike Windows, drivers can't practically be added to a kernel, they must be compiled into it.

Apple would not want to make their drivers open source or so they would want to distribute their drivers as binary blobs.

That would necessitate either maintaining an Apple-fork of the Linux kernel with their drivers hidden within it, or contributing shims to upstream Linux + binary blob drivers.

If they wanted to help, the bare minimum would be to publish documentation on their hardware so drivers could be written without reverse engineering from schematics and microscope photos.

If I play devil's advocate, the only reason I could think of is that supporting Linux signals to investors that Apple is offering a key to bypass their API moat, perhaps sacrificing a longer term vision of vendor lock-in.

By contrast, I can imagine investors would get upset if the iPhone had an unlocked bootloader and allowed Android to be installed - but that's because the App Store is a significant revenue stream for Apple. I don't think there is a parallel on MacOS that investors could point to as being upsetting.

If anything, optional support for Linux would lift the market cap for Mac hardware as it would close the only pull that other laptop vendors previously enjoyed.

In reality though, just like is historically true, 99% of people would continue to use MacOS. Only SWEs, enthusiasts, gamers and some number of Windows refugees would pick Linux.

Though I am 100% behind legislating Linux support - EU are you listening?