b_e_n_t_o_n

There just isn't much friction between having a few tabs open (maps, booking site, airplane site, google search) and a notepad. The friction of searching for an app, downloading it, and then learning how to use it is just higher.

So many products are like this - it sounds good on paper to consolidate a bunch of tasks in one place but it's not without costs and the benefit is just not very high.

"I can't do this"

"Are you sure you aren't just having trouble?"

Similar concept imo.

This makes me wanna go buy some stickers...

Thank you for this, I'm unlikely to ever touch Erlang but looks like a fascinating read nonetheless.

Not just Steam Input, they maintain SDL and strongly encourage everyone to dynamically link it in order to keep older games going.

Definitely a genetic component as well!

I don't think that's true at all. I had prefect vision up until I graduated college and started spending 10hr a day behind a screen - within two years I ended up getting glasses, although they are a mild prescription and I don't really need them other than driving at night. My friend was in a similar position and they also ended up getting almost the same prescription.

My eye doctor said it was my eyes optimizing for what they do the most. And that makes sense, I have no eye strain using a computer.

Interestingly my vision is better in the summer, and when I take holidays during the summer and spent time away from the computer my eyes essentially fix themselves. It takes a couple months back behind a screen to need my glasses again.

Not AI moderation? I'd assume the more scalable option is having an LLM parse messages when reported.

This is really great, the only problem for me is that there is nobody around me! I can see it working way better for stuff like universities though.

I wonder if there could be a variant for Drop which is world wide - imagine being able to join a chat in a foreign country (hopefully you speak the language!) and chat with the locals. I imagine moderation would be a big pain but I could see it being fun and sort of in the spirit of the old web.

Getting an end user to set up and run docker to run an app is a non starter for most things.

45% slower seems pretty decent considering they use a wasm kernel they developed to mimic the unix kernel so they can run non-modified unix programs inside the browser. It's actually pretty impressive that they did this, and even more impressive that it works and like another commentator said, is not even an order of magnitude slower.

I'm more interested in 1) usages of wasm in the browser that don't involve running unmodified unix programs and 2) wasm outside the browser for compile-once-run-anywhere usecases with sandboxing / security guarantees. Could it be the future for writing native applications?

Languages like Kotlin, C#, Rust, as well as C/C++ etc support wasm quite well. Could we see that be a legitimate target for applications in the future, if the performance gap was closer to 10%-ish? I would personally prefer running wasm binaries with guaranteed (as much as possible ofc) sandboxing compared to raw binaries.

edit: it's from 2019, there have been significant improvements made to wasm since then.

Location: Canada

Remote: Preferred

Willing to relocate: Yes

Technologies: Typescript, Go, Kotlin, React, Next.js, Svelte, Vue, Postgres etc.

Website: https://benten.ca

Résumé/CV: https://www.linkedin.com/in/bentonbc/

Email: on website

I've been working as a software developer for the last four years, majority of which has been full stack. I have a kinesiology degree and I'm primarily looking to integrate my education with my professional experience, so companies in the health/fitness field basically, but I'm open to all interesting positions. Please check out my site at https://benton.ca, it goes into detail on some of the recent works that I have shipped. Cheers :)

I'm going to provide a dissenting opinion here. I think the URL is for location, not state. I believe that using the URL as a state container leads to unexpected and unwanted behaviour.

First, I think it's a fact that the average user does not consider a URL to be a state container. The fact that developers in this thread lament the "new school" React developers who don't use the URL as a state container is proof of this. If it follows that a React developer, no matter how inexperienced, is at least as knowledgeable if not more about URLs than the average person, if they don't even consider the URL to be a valid container for state than neither does the average person.

Putting state in the URL breaks a fundamental expectation of the user that refreshing a page resets its state. If I put a page into an unwanted state, or god forbid there is a bug that places it in an impossible state, I expect a refresh of the page to reset the state back. Putting state in the URL violates this principle.

Secondly, putting state in a URL breaks the expectation of the user for sharing locations. When I receive Youtube links from friends, half of the time the "t" parameter is set to somewhere in the video and I don't know if my friend explicitly wanted to provide a timestamp. The general user has no idea what ?t=294833289 means in a URL. It would be better to store that state somewhere else and have the user explicitly create a link a timestamp parameter if the desired outcome was to link to an explicit point in the video. As it stands now, when I send YouTube links to friends I have to remember to clear the ?=t parameter before sharing. This is not good UX.

There are other reasons why I think its a bad idea but I don't want this comment to be too long.

That doesn't mean not to use search parameters though. Consider a page for a t-shirt, with options for color and size. This is a valid use case for putting the color and size in the URL because it's a location property - the resource for a blue XL shirt is different from a red SM shirt, and that should be reflected in the URL.

That's not to say that state should never be put in the URL - in some cases it makes sense. But that's a judgement call that the developer should make by considering what behaviour the user expects, and how the link will most likely be used. For a trivial example, it's unlikely that a user wants to share their scroll position or if a dropdown is open when sharing a page. But they probably want to share the location they've navigated to on a map, as it's unlikely they're sharing a link to `maps.google.com` with others (although debatably that's not state, but rather a location property).

I mean, it's probably pretty clear when you look at result's initial assignment...

State exists in time, a variable is usually valid at the point it's created but it might not be valid in the future. Thus if part of your program accesses a variable expecting it to be from a certain point in time but it's actually from another point in time (was mutated) that can cause issues.

I think we heavily overestimate our ability to reason morally though - our thinking just becomes an ad hoc justification for our own intuitions.

Why apologize and do it instead of not do it and no apologize?

No it doesn't

And even for gaming, depending on what you play it's perfectly serviceable.

The problem was the framework's bundler was transforming those functions to return promises, a linter would need to understand next.js's specific transforms to catch this.

You can use (ts 5.8 and above) a compiler flag `erasableSyntaxOnly` which enforces only TS features that can be dropped without modifying the underlying JavaScript. Unfortunately one of my favourite TS features, parameter properties, isn't erasable although it doesn't change runtime semantics.

Hah. Back in the day I wrote a plugin to convert Lua files into a module that ran via one of the JS lua vms. Good fun.

I think it's trivially true that (at present moment) AI can deliver an average result, which makes it useful in domains you are below average but not useful for domains in which you are good at.

If I want pasta, and I can chose from 10k options, but none of which are pasta, is it really any different than if I had one option?

I think its good for enhancing taste, fluidity, and creativity, obviously not good for strict engineering but that's not all we do...

Not sober at all

I write my best code a little tipsy

There is a noticeable delay between interaction and response (~200ms), which is way over the usual 16ms budget for smooth interactions. I think you need some pending state on the client, but that sort of breaks the idea of storing all state on the server haha.

You mean I should be storing the state of a popup menu in my database?

This take seems fair, the headline kind of removes the nuance. There are times where generating a lot of low quality code quickly is useful. And there are situations where the required code is simple and common and LLMs can spit out working code that's decent quality, even if it doesn't understand it. In those cases the developer doesn't really need to exert much mental effort to write it, but they save time by not having to write it.

I find AI more useful for all the things that are secondary to writing code - things like accessibility passes over HTML, generating documentation, creating debug UI's, figuring out some library or API so I don't need to read the docs, debugging build issues (unrelated to my code), and in general managing all the BS we've self-inflicted on ourselves so I can focus on just writing code. AI probably saves me 1-2 hours a day, which is hardly a 10x speed up but it's still really significant. And those numbers are in line with a recent study the UK government did on AI assisted software development, although I didn't save the link to it.

We? or you :P