The main section feels pretty anti Trump, actually. Not by choice but reality has an anti Trump bias ;)

They are also quite good at labeling their opinion sections clearly, which I think a lot of other papers aren't doing. Their news section is basically Reuter's.

In my experience, WSJ just reports what happened and who said what in a very dry way.

My impression is that their news section provides a very anti Republican party view. Note that this is my impression, not the paper's stance. They don't really take any, apart from the opinion section, which I ignore. The opinion section has a massive pro republican bent.

> Lying by omission

I'll admit, I might have a blind spot here because I'm only reading 2 newspapers. That being said, I'm not sure of any stories reported by the other news outlets which were ignored/downplayed by WSJ.

> apologies and retractions

Happen when they happen. I remember a few per month. But since they're so dry, there's very little scope for major corrections. If they say, "this guy said that", there's very little to correct there. Occasionally, they mis-paraphrase someone and have to correct their report. Most sound like honest mistakes to me.

EDIT:

> You aren't getting any sort of counterpoint you are getting whatever supports his world view.

Fair enough, but you mostly don't get any points to counter in the first place. Only plain dry facts. I go to the Economist for opinions and counter opinions. (*side note, the Economist should publish more counter opinions IMO)

For dev builds, I see JIT compilation as a better deal than debug builds because it's capable of eventually reaching peak performance. For performance sensitive stuff like games, it really matters to keep a nice feedback loop without making the game unusable by turning off all optimizations.

AOT static binaries are valuable for deployments.

No idea how expensive it would be to develop for an existing language like Rust though.

Between the Economist and WSJ, I get a good overview of opinions and facts.

This is brilliant! Such simple change but a massive qol improvement.

> Test runner

Node has one built-in these days. Haven't tried it yet but would be nice to get rid of the vitest dependency. Mostly because it makes my dependabot noisy for no apparent benefit.

Yes! It's called Evil mode. It emulates vim keybindings.

In terms of "normal" keyboard shortcuts, it could but no one who uses Emacs is asking for it. Mind that ergonomics is also very subjective. You might not find lisp very ergonomic, but Emacs users do. They find other languages unergonomic.

Other ways Emacs has borrowed ideas from other editors.

It now has first party tree sitter integration for better syntax highlighting. I believe this was borrowed from the neovim world.

It has plugins for LSP...borrowed straight from the VSCode world.

If it matters, I've never used Emacs in my life, so I'm not a part of their weird cult. But i can see that they do things the way they do for a reason. They're not a bunch of morons.

It's not necessarily the fact that C doesn't have enough information, it's just that the JIT can reason about Ruby code better than it can about C code. To the JIT, C code is just some function which does things and the only thing it can do with it is to call it.

On the other hand, a Ruby function's bytecode is available to the jit, so if it sees fit, it can copy paste the function body into the call site and eliminiate the function call overhead. Further, after the inlining, it can apply a lot of further optimizations across what was previously a function boundary.

In theory, you could have a way to "compile" the C intrinsics into the JIT's IR directly and that would also give you similar results.

Well Zod is a library that's typically used on the boundary.

I don't know why you're assuming stuff about a library that you've never used. No one would continually check their shape once it's validated at the api boundary.

Yeah this is a very key point to reflect on. Is this stricter type actually catching a bug that's easy to make? Or is it just giving you more satisfaction of more precise typing? It takes time and practice to make that distinction.

Similar things can also be said about automated tests. I've written too many of them that end up being written for a mistake that never gets made.

I'm not arguing for giving up type systems in general, but I'd rather read something like `class VersionString` that asserts the requirements in the constructor. If it really matters, you can check this at run time but before releasing using a test.

Like what exactly are you trying to get from autocomplete in a version string literal?

I was with OP's point but then you lost me. You'll always have to deal with that coworker's shitty code, GIL or not.

Could they make a worse mess with multi threading? Sure. Is their single threaded code as bad anyway because at the end of the day, you can't even begin understand it? Absolutely.

But yeah I think python people don't know what they're asking for. They think GIL less python is gonna give everyone free puppies.

Fucking hell bud :D

This is a fair observation.

I think a part of the problem is that the things that make GIL less python hard are also the things that make faster baseline performance hard. I.e. an over reliance of the ecosystem on the shape of the CPython data structures.

What makes python different is that a large percentage of python code isn't python, but C code targeting the CPython api. This isn't true for a lot of other interpreted languages.

I used to have that opinion, but now, going through a months long project modernizing our codebase's build tooling, I'm not so sure. Vite isn't so amazing either if you stray away from the happy path (html entry points). I guess no build tool is amazing. At the end of the day, the only thing I can say is all build tools suck. Write less build code if you can get away with it.

Eventually I had to settle on rspack (the spiritual successor to webpack) because vite wouldn't do what I wanted it to do. You could say it was the wrong tool for the job, but it took me a while to figure that out, given how scary it is to not use the frontend build tool. I still wish we could've used it because then we'd be using an industry standard tool.

Getting back to criticizing Vite (sorry have to vent haha) in my experience, vite's API is also built on weird foundations. It exposes rollup and postcss options in it's config, which sometimes do similar things as it's own config options. It generates tons of small chunks with no obvious way to control it without giving up on nice things.

Eventually I did get stuff to work, but in the process I became an expert in a bunch of tools that I never wanted to be an expert in. I just wanted to write my business logic :') It makes me long for Java tooling.

To top it all off, I don't think could've done a better job than the people responsible for this complexity.

> What did we learn from all this?

> I don't know.

> Well I don't know either.

> I guess to not do it again...fuck if I know what we did in the first place

I guess eventually all tools will converge to a de-facto mixed module/commonjs module resolution standard which roughly matches what tsx (the ts-node replacement, not the file extension) does.

``` const h = React.createElement

h('div', { id: 'foo' }, [ h(MyComponent, props) ])

```

Of course the props to divs are a bit different and event listeners/styles can be written inline, but none of this is JSX specific.

https://github.com/google/zx