unchar1

The WSL section doesn't really make sense

>But what you must know is that WSL has a lot of problems when compared to a full Linux OS. Some packages will not be up to date and sometimes will not be as functional as a Linux distro.

AFAIK it's just a regular linux distro (in a VM), so I'm not sure why it would have different packages?

That may be due to a combination of Malware detection + most unix programs not really written to take advantage of the features NTFS has to offer

This is a great talk on the topic https://youtu.be/qbKGw8MQ0i8?si=rh6WJ3DV0jDZLddn

It may be useful if you have data that originates from another source or if something outside of our system references your entity. In that case you need to keep some form of an externalRef, so it's usually easier to just use an id that you can control, for referencing both internally and externally.

Wouldn't a static parse method still allocate memory for the object that it returns?

Typescript's type system is known to be turing complete and people have implemented things such as sorting/tree-walking just using types (i.e. during compile time) [1].

I'd imagine something like this should be possible as well, but I'm not sure it would be worth it, considering the effort it would take to implement.

[1]: https://twitter.com/anuraghazru/status/1511776290487279616

If you inform your manager that doing X could break the site and they still push for it, then it is in fact their fault when it breaks.

The point of a decision-maker is to make informed decisions, if you fail to do that, then you fail at leadership.

I first heard that in a talk by Kevlin Henney [1]. I'm not sure if he's the one who came up with it though.

[1]: https://twitter.com/KevlinHenney/status/381021802941906944

I can understand that Go has a GC so it (might) be slower. But wouldn't Rust and Zig have about the same performance?

I think the word you're looking for is "tedious". Go is both simple and tedious to write. I'd actually argue it's tedious _because_ of its simplicity.

Curious if you tried this on an EC2 instance in AWS? The IOPS for EBS volume are notoriously low, and possibly why a lot of self-hosted DB instances feel very slow vs similarly priced AWS services. Personal anecdote, but moving to a a dedicated server from EC2 increased the max throughput by a factor of 80 for us.

Sorry for the late reply,

Yes, I did try this and although I don't particularly need remote editing, the fact that it took me less than 2 minutes to setup a remote editor with auto-complete and other IDE features was pretty amazing.

If you want a resource that's limited and can't be created by central banks, why not use something like Gold/Silver like we used to? While not going trying to debate on whether we should or should not use a limited resource as currency, but if we did Bitcoin seems like a wasteful thing to use.

> They just copy their init.el/vimrc to the server, Emacs/Vim users have been able to do this (coding on remote environments without all the kludges) since forever ;) and personally, I find it superior to vscoce's remote plugin since your editor and tools sit on the same machine.

Unfortunately this doesn't work well if your connection has a high latency though, which I think is what VScode does really well.

> Stateful "functions" is just so asinine I don't even know where to begin

I feel like the React team did a bad job at communicating that the functions are still stateless. The functions themselves never hold state, they just access the state that react holds for each component through hooks.

I think this confusion is further fueled by the fact that most people feel

render () {

    return <Button />

}

calls the `Button` function inside `render`, but what it actually does is that it registers the `Button` function in React, telling it "here's how you can create what I want", it doesn't actually call the function. The actual call is done by React, if and when it wants to.

Hooks extends that idea by letting you say "Here's how I want to update my component".

The component functions you write in React are a "description" telling React how to create that component. With hooks you can now "describe" how to update that component with new changes. I feel like hooks force you to let go of the control you thought you had with class-based components. Whether that's a good thing is up upto you.

I agree that lua is a good fit here, being a smaller and easier language to embed, with a much simpler runtime to boot.

But could you elaborate on why you think JS is an inferior language?

Actually developers built the market. Without that Apps on the App store, the iPhone is worth almost nothing.

The same way that GMail isn't really "free", that 30% tax doesn't come from Apple or the Developer's pocket, it ultimately comes out of your pocket.

>Just to be clear, microservices are not just separate binaries on a network. If you're not following the actual patterns of microservice architecture... you're just complaining about something else

So what you're saying is that the way to avoid this problem in a microservice architecture, is to be disciplined and follow the right patterns. Then couldn't I just follow the same patterns in a modular monolith (eg: avoid shared state, make sure errors are handled properly, etc) and get the bulk of the benefits, without having to introduce network related problems into the mix?

I find the twitter thread to be specially sad, since I see a lot of people genuinely try to explain that compile times/familiar syntax are more important to them, but the author seems adamant that they just don't know what modern tech is and they should learn the "right" approach.