ojkelly

Sure not everyone who bought the game or a ship at this stage has enjoyed it, but a lot of us have. Even in its unfinished state there’s a lot of fun to be had.

And, part of the game at this stage is watching it develop.

The amount raised/sold so far is massive, but people keep buying because they’re getting something out of it.

Releasing code to prod is the end of the feedback loop, until then you have possibly working software. The long you wait until release, the less likely it will work as you expect.

You don’t need to release to users, that can happen later.

Every team I’ve been on that could release daily never wanted to go back to anything less.

The tooling is still too hard for mass adoption by teams, but the benefits are real.

Not running arbitrary code is a feature, that yarn brings back to the js ecosystem.

It sounds nice in theory, but it impacts the soundness of the whole system.

Anecdotally, I continue to see friend groups form where near all of them are neurodivergent without knowing it. Because their brains work differently, when they find someone else whose brain works in a similar way it’s less effort to spend time with them.

It shouldn’t be a surprise then when one of them gets diagnosed, the rest eventually look into it and get diagnosed too.

It helps that in the last 3-5 years talking publicly about ADHD has become less stigmatised (one of the reasons I continue to do so). I first suspected having it over a decade before looking more into it. I wouldn’t have hesitated if social conversation then is like it is now.

The internet doesn’t cause ADHD, neurodivergence is likely more prevalent than expected. We (neurodivergent’s) have all been masking and developing strategies to survive the modern world. Then covid happened, and the normal support structures fell away, coping mechanisms failed.

All of a sudden things went from hard to basically impossible, it’s no wonder some of us decided to ask whether or not the experience was normal or if there might be something else at play.

Diagnostically ADHD symptoms need to be present when you were younger (IIRC 10-12), so if they just started at 22 it might be something else. Or it might be you left home, made a major life change, and your previous coping strategies no longer work.

If you’re prescribed amphetamines they shouldn’t be getting you high.

Generally speaking, harm reduction.

With full knowledge of what could happen (because effects are often not uniform), and with the right care and support I would think it can be done ethically.

Look at the trials of using LSD/mushrooms/MDMA to help people work through serious trauma. Done well it looks to be positively life changing, done poorly and it seems to be horrifying.

Stimulants don’t have the same effect on everyone, and this attitude is incredibly dismissive of those who need these medications to function.

They’re a controlled drug for a reason, abusing them can have negative long term effects especially if you don’t need them.

Yes–startups require energy, but stimulants are prescribed to those who need executive functioning support, not energy.

It’s probably not a coincidence the other place I’ve seen this technique was also for archiving a feed of fires.

It that case the data was about 250gb when fully uncompressed, and IIRC under a gig when stored as a git repo.

It’s a really neat idea, though it can make analysis on the data harder to do, in particular quality control (the aforementioned dataset had a lot of duplicates and inconsistency).

Like everything it’s a process of trading off between compute or storage, in this case optimising storage.

I think the comments here are missing the point.

Each of the items on the list are things you or someone else in an organisation does in good faith.

That is why these work.

When you do them in bad faith, you can stretch the timelines for things significantly while the responsibility for such a delay ends up so diffused among the bureaucracy that no one takes the blame.

“It’s just harder to get things done in a big organisation” as they say.

If you keep a lookout for these, particularly when they may be not in good faith you can head them off.

There’s a good chance this is realised within 5 years, built on WebAssembly.

While it’s not on the metal performance like native compilation, it’s close. I wouldn’t be surprised to see CPU instructions for WASM to get to native performance, if it got popular enough as a runtime.

I wonder if Apple's self-service repair program is sufficient for this?

I do like the idea of user-replaceable batteries, but I don't miss the build quality and size of those devices with easily accessible batteries.

There’s nothing of substance here for why it should be ridiculed, other than the authors fear Apple has the ability to bring VR to the mainstream. But hasn’t Oculus/Meta Quest sold something like 20 million units?

> Stop this future of computing > Tim Cook and his fellow Apple executives clearly asked themselves whether they could create a headset as their latest hardware product, but don’t seem to have spent as much time considering whether they should.

Has the author considered why people are currently buying these headsets? And why a company with a long history in mobile computing would get in on it?

> … The risk with Apple entering this market is that it does have a unique ability to legitimize products.

The article is probably not worth your time, it wasn’t worth mine.

The more I think about this, the more convinced I am that I want a browser that functions like an IDE.

Multiple panes with tabs, that can be resized either to custom sizes or automatically (binary space partitioning).

It’s too much for a general purpose browser, which is how we’ve got the Chrome, Safari, Firefox we have. But I think the appeal of a more information-dense browser is broader than we think, anyone doing research would benefit from it.

But, by omission is reads that Prime Video rebuilt their stack without serverless and got a 90% cost reduction.

This post is going to pick up a lot of traction and I suspect these comments are going to bikeshed monolith vs microservices for the next day.

On reading it, this is for a video quality monitoring system, that needs to consume and process video. Generally a compute and time intensive task. Something not always suited to severless, particularly when it’s not easy to parallelise.

The task at hand doesn’t sound ideally suited to serverless, but the existence of the post shows that’s not readily obvious. So it’s a valuable post to explain a scenario where a few big machines is the best call.

But the sensationalism of the headline, would suggest all serverless is expensive and wasteful. When in reality the same is true for a non-ideal workload on a monolith.

If I’m fully engaged with a device a touch screen is great, especially when that device needs to do more things than you could reasonably make physical controls for.

But when I’m driving and need to adjust something, I don’t want to disconnect with driving to dive into a touch screen.

A physical control, in the same location means muscle memory can take over. And as we learnt decades ago, the controls themselves need to be physically distinct so that you can tell them apart without looking or thinking too hard.

I don’t think touchscreens need to disappear from cars, there’s a wealth of settings/config/etc they could be useful for.

But the core driving aids and temperature/volume control need to be physical.

As someone with ADHD, I’ve found the key thing is to learn what level of stimulation your brain needs for certain tasks.

Too much, over-stimulation, and you’ll find your focus being pulled in multiple directions to a point of confusion, frustration and anxiety. I believe this can also lead to migraines.

In that situation you have to reduce something, maybe it’s ambient noise, maybe you need to pause your music, maybe you need music without lyrics. Maybe the lights are too bright. Maybe you have too much on your plate. Or, maybe your chair is hurting your back, and you need to replace it.

To little, under-stimulation, and you need to find the right type of stimulation to aid your brain. For me, lyricless music, is perfect for deep thought coding. But not enough for washing the dishes or cooking, a conference talk or similar however is great.

You may need meds (talk to a Dr/Psych), or maybe just some tea/coffee.

Exercise can help. You can get an under desk treadmill, and walk even at a gentle pace for a few hours to keep your brain active and alert.

You have to experiment and learn what _your_ brain needs. It’s not quite the same for everyone. What works for me, is often the exact opposite for others.

And remember how much sleep, what you’ve eaten, and how well defined your task is all contribute.

This makes sense.

You don’t start woodworking by cutting a hardwood timber to length by eye with a circular saw.

You get familiar with the basics like a hand saw, tape measure, and some soft wood like balsa.

You’re first vehicle was _probably_ a bicycle or go-kart, not a truck or race car.

As much as I’ve been loving Rust, there’s no doubt it’s a hard but rewarding journey to learn it.

Go on the other hand, is a language I’m still confident I can teach a junior enough to be useful in an afternoon.

The restraint shown by the Go team is admirable in how well they’ve stuck to their vision.

> Calling that "stepping outside" is just dishonest.

I don’t think it’s dishonest. There’s two main phases in react, render and commit.

Render is interruptible. For example when a new event like an interaction comes in, the in progress render might get chucked out and restarted with the new information.

Commit isn’t interruptible. It’s a sync phase. This is where all the effects run, and the purpose is to take the new state from the render phase and synchronise it to the external systems. Aka cause side effects.

The useEffect hook running in the commit phase, does let you step outside of the react framework. It lets you safely interact with external systems. If you tried to do any of that in the render phase, you risk getting cut off halfway, or doing things out of order.

> React is not a "pure view library" that you have to integrate with state management.

A view library without state management would be a templating engine right?

> It makes you handle the extremely impure chain of (route change, component "mounting", data fetching...), all in the rendering code.

It lets you define how to respond to those changes in the render phase, but they aren’t applied until the commit phase.

And that means you can wrap up the complexity in well tested components that provide a simple API.

It’s all cyclical.

Before React two-way-binding of data, known today as Signals, was the way we did things. Angular is probably the best example from the pre-react time of that.

React came along with a philosophy of one-way-binding also known as unidirectional data flow. I’ve stuck with it because I think it enables much better local reasoning, and more predictable outcomes.

Neither are outdated.

I’d wager the most performance critical use cases would benefit from signals, things like tldraw.

But unless you’re doing something which needs to paint every single frame (ignoring animation/transitions), the extra overhead and mental load required by Signals is excessive. It’s overly complex and harder to reason about.

With no disrespect to Vue, Svelte, Solid, etc, they feel outdated in the way Angular does.

Down in Melbourne, Australia it’s regularly 5-10 degrees wrong.

It’s like they got a 7 day forecast, and never updated it.

Something must have happened this year, because it used to be very accurate.

Now, if if you want accurate weather (down under) you need to use the pretty good BOM app. But, it doesn’t have a Home Screen widget, or watch complications.

A lot of things could also potentially compromise a long-lived build server, to the point where it’s better not to be long lived.

If it’s not practical to use a fresh machine/vm/container/function for each build, at least rotate them out more than once a day.

You need full repeatable control over the execution environment for hermetic builds.

I also agree rust needs to either fix mitigate this. One option you have is to disable networking on the build machine.

It has lasted as a project. Are you saying that no library should try to improve their performance, internals or API?

There was many versions of jQuery. I remember the days of hacking Drupal to load multiple versions because it shipped with an older version, but we needed a newer one for other dependencies.

I’ve been around this space for over a decade. Software that’s easy to change, tends to outlive the rest.

React has more staying power than almost any other JS library I’ve seen. And they’ve maintained backwards compatibility on par with Windows.

The other day dang was mentioning how HN struggling under the popularity of the GPT4 thread[0]. But even then, surely HN has seen some code updates. If you look at HN as a product (and not a codebase), the unofficial/official algolia search engine is an addition.

What runs untouched for decades?

[0] https://news.ycombinator.com/item?id=35157344

> Unbelievable that they’ve gone ahead launching this

I hope the irony of criticising a team for launching something early, on HN _of all places_ isn’t lost on you.

> going all in on hooks

They went all in on hooks in 2018 when they rewrote the internals with React Fiber.

Hooks are how react works, class components are more of an abstraction—not less.

> while the fundamental problem with them, which was raised in 2018 is still unsolved

If it was a showstopper it would have been fixed by now.

> Well, bummer. I have a mature product using React Components which are now legacy. It looks like in the future, I'll slowly migrate these over to functional components, as is standard in the documentation.

The writing has been on the wall for 4 years that hooks are the future. You _can still_ use class components. Function component with hooks is the simplest API you can get to React itself—classes are more of an abstraction.

> I'm disappointed by the fanatical adoption of hooks, but I saw it coming and I can't say their legacy documentation didn't warn me.

We all adopted hooks because it makes things easier to reason about. If you’re still having trouble understanding them, I’d urge you to dig deeper into how they and React works.

> I might finally invest some time into what it looks like to create front ends independent of any of the existing frameworks that exist today, which I think is probably controversial, but I want the decisions I make to last longer than the whimsy of engineering teams who don't care that they might change their mind in 10 years.

I can’t think of a better way to develop an appreciation of UI frameworks that to go without.

> I want the decisions I make to last decades, not just a few years. I don't think that's a sentiment appreciated by most, though.

Barely any software runs untouched for decades (documents don’t count). So it’s not that the sentiment isn’t appreciated, I think most of us would agree—it’s that it’s an impractical expectation.

So far I’ve found copilot is like a weather forecast.

The shorter the prediction the higher probability of it being correct.

The longer, and more complex the prediction the less likely it’s all correct. But, with a close review you can spot the errors and correct it.

I’ve found most useful to get ideas on the page fast.

It’s also absolutely insane to be writing a parser, and have it suggest unit tests and code where it clearly has developed an understanding of the language before the parser is complete.

Wasn’t part of the drive to client side analytics an effort to improve data quality, in particular to differentiate bots from humans, and measure actual human analytics without getting caught by caches along the way.

If you use something like Cloudflare you can also get some of that serverside logging back.

And netlify and Vercel both have first class analytics features.

The suggestions in this thread are decent, but I haven’t seen a mention of prioritising what you know.

What’s your goal?

If as you mention you have an app to prototype and you want that prototype as fast and simple as possible, then you can’t use tech and tooling you don’t know.

Any time spent learning the new tech, is time you could have spent on the prototype.

With that lens, you can see the variety of suggestions here are what people know best.

If you goal is to learn a new tool, or to learn a new tool alongside a prototype, you have to trade off speed. It will take a bit longer.

Spend your novelty tokens wisely.

In useEffect your code runs at a specific point, where it’s safe to bridge react to the outside world. It’s not about breaking the rules, as much as you have the ability to cause and react to side effects (eg a fetch promise) and inform react about the result (with a setState).