The dude believed in a bunch of random quackery and essentially killed himself because of it. Was diagnosed with some kind of rare cancerous tumor and ignored it for months, trying out veganism and fad diets for some reason instead of just listening to his doctors.

I'm pretty Jobs would be doing the exact same stupid shit Musk is, just without the weird twitter meltdowns I guess.

What do you mean? Typescript by default assumes non-null, and if you specify that something can be null it'll force you to check that it isn't before attempting to access it.

Sure. However the any type lets the nulls in. And the any type is very convenient, perhaps even necessary to use in some situations. So then you are back to plain old js check blocks and ternaries littered everywhere. If you miss one, well, I don't need to remind anyone of the ubiquitous js console error which every js developer has burned into the back of her/his brain.

I use the no-explicit-any Typescript ESLint check and tsconfig no-implicit-any, never turn them off unless absolutely necessary, making this is a non-issue. Not that I’m not interested in Reason for other reasons though!

That's fine if you can control this configuration I suppose. But the escape hatch is there, so in my opinion TS doesn't go far enough.

Note that "by default" here means "when strict mode is on, which is explicitly turned on when you run tsc --init". If you don't specify a config value for strict mode, it will be off. (At least last time I checked.)

Tested this out a few months ago, got real excited when I saw they had a beta thing for it but was let down that you couldn't collapse and expand tab groups down to just their titles. The functionality should even be there-ish already, since pinned tabs collapse down to just the site's favicon.

This is pretty much it, tbh. Every time one of these types of threads pop up you get a bunch of people commenting about how broken the web is and how it sucks because front end devs aren't real devs or something, and it's immediately clear to me that none of them have done any serious work on a modern website.

The problem is a business/orgnanizational problem - it's not like developers are incapable of mimicking their own websites with pure html+css+js (especially with all the improvements to JS and the browser apis over the years), it's that doing that and then maintaining and growing it with a team of people is basically impossible at any useful scale.

Frameworks provide a common language for teams to build their site with. The fact that they also currently introduce a lot of extra complexity that require developers to handle previously "free" things (ex. performance, bundle splitting) isn't some fundamental flaw with the idea of frameworks, it's just a result of people still trying to figure out exactly how the hell you can provide a nice, interactive site with all the bells and whistles that'll make like 5 different groups of stake holders happy.

React components aren't a 1:1 mapping to the DOM, so you could in theory have 50 HoCs wrapping a single component and it still only output one div or whatever.

Also, HoCs have somewhat fallen out of favour over time, with hooks and the child as a function/render prop style becoming more popular. I think the only HoC I consistently use these days is `connect` from `react-redux`.

Two big reasons: Values passed via connect can be validated by proptypes, and by using connect you can mount your component without redux. That may make sense for building shared components that may be used with redux in one part of your app, but without redux in another part. There are a lot of smaller reasons to prefer connect, but those are the big ones to me. FWIW I use both approaches depending on needs.

does it do anything to change/fix Emacs shitting itself on large buffers?

last time i gave it a try opening a large file would completely kill performance, and iirc in particular really long lines (ex. 1000+ chars) would make the thing chug even if the actual file wasn't super big or anything.

Large buffers are fine - long lines are not.

If you don't have long lines but you are experiencing slowdowns on large buffers, your mode is doing something. As an example, large XML files bring my Emacs to a crawl, but if I switch to a text mode it's fine.

For long lines, I believe the latest Emacs has a fix: https://www.reddit.com/r/emacs/comments/ccoksw/solong_mitiga...

I've had good luck on big (multi-GB) SQL dumps, which often have very long lines, with

https://github.com/m00natic/vlfi

I think I remember Emacs 27 will include some improvements in that regard, even without native code compilation.

> in particular really long lines (ex. 1000+ chars) would make the thing chug

My uninformed guess is, this is bottlenecked by an inefficient algorithm that accesses the memory too much, i.e. it's nonlinear with respect to the number of characters. I doubt that tweaking the overall speed would fix it.

My experience is it's generally either

- inefficient font-lock regexes, which are rarely benchmarked / optimized since most files don't have long lines and because font-lock behavior is quite complicated to begin with;

- inefficient thing-at-point implementations / use, e.g. an O(n*n) thing-at-point called at various points by an O(n) function;

- modes using font-lock regexps where they really just need "fixed" styled text, but other Emacs architecture makes it difficult, e.g. compilation-mode and derivatives.

Emacs dev here. The primary cause is something else.

Emacs's inefficiency in handling files with long lines is due to two factors: (a) The primitive unit of work for the display engine (the code that determines how to combine text, font metrics, syntax highlighting, inline image display, etc.) is a line (a newline-delimited span of characters). (b) The redisplay routine is called very frequently—not just when the screen is repainted, but pretty much any time the screen location of a buffer element need to be calculated, and so, e.g., during navigation. So Emacs is constantly, under the hood, going back to the previous newline and re-calculating how the buffer contents from that point forward should be rendered.

I’m not an Emacs dev so I’ll concede your expertise here - but if it is fundamental to the core navigation and redisplay, why does “stepping down” modes help so much? Fundamental and text mode certainly aren’t great with long lines, but are usually orders of magnitude better (eg a few seconds per command instead of 10s of seconds).

(I have not tried so-long-mode and am mostly on Emacs 26 with some 25.)

What you're observing is caused by what I'm describing. The features of these other modes are expensive because they do things that implicitly invoke redisplay.

Consider an ostensibly simple operation like determining the column in which a particular character appears. The answer to that isn't the number of characters since the last occurrence of `\n`, because whatever modes are active can inject arbitrary spacing, or display particular strings as something shorter or longer (a trivial example is the mode that causes `lambda` to be displayed as `λ`), or cause some characters to be displayed in a non-roman font where a single glyph is more than one column wide, and so on. To determine the character's column accurately you need to take into account everything that could affect how you'd paint the screen at that position, i.e., run the whole redisplay loop for some portion of a buffer. The richer the set of active modes, the more expensive it is to do that and the more often it is done.

Thanks for your work on Emacs :)

I routinely edit C# files in the 5k to 15k LOC range, and emacs works well for me. Occasionally the "smooth scrolling" feature stutters on large files but otherwise it's perfectly usable.

Are you opening it in fundamental mode? Without actually doing profiling, I'd guess it's syntax highlighting that's the real issue there. I've opened 100+ MB files without an issue, but that was on a box with an absolute ton of RAM.

Nah. IME it really is just line length.

A little too practical - my man literally put out like an 8 minute long squarespace ad a few weeks ago. And he's been doing the Raid: Shadow Legends ad shit now as well.

I'm all for getting paid, but man, at least put out ads relevant to your content.

What about switch expressions in Java is better than Kotlin's when? I haven't personally used switch expressions in Java yet, but I've read the JEP and I don't see anything special or interesting.

>It's unreal that in React I have to deal with occasional infinite loops now because of hooks. Sure, React catches the loop cycle so things don't totally freeze but I don't recall ever having to deal with this before them ... missing dependency accidents requiring linters to prevent

Infinite loops and missing dependencies are/were issues with `componentDidUpdate`/`componentWillUpdate` and `componentDidMount` as well, though. On the plus side, you now have a linter which can both point out these errors and automatically fix them for you. I agree that the whole thing is a bit leaky and dumb though, but there's no way to fix that without introducing some sort of compilation/optimization step and afaik the React guys aren't really considering that at the moment.

>Weird, unexpected reference issues

Not sure I've run into this before. Do you have any examples?

>strange programming patterns, a team member having to write a terrifying novel

The first bit seems like personal preference or something, not sure what you're referring to as strange. The `useEffect` novel exists because a ton of people had built up their (incorrect) mental model of how React works with lifecycle methods and were making mistakes or running into unexpected behaviour because they assumed `useEffect` was the exact same thing as `componentDidMount`.

Reference issues:

1) Needing an advanced understanding of closures. Not always, but sometimes. That "sometimes" is often unintuitive, requiring weird solutions like useRef. Good luck beginners.

2) Things like updating reducer state by using a spread object, which creates a new object which can then send a system haywire. Seems fine, and is mostly fine in most cases, but hey, oftentimes not fine, and why that's so is not always clear. So then there's memoization, and useCallback and all of these safety checks -- each with their own dependencies array that need to be checked. It's really too much tbh. There are lots of solutions out there that use proxies to check this stuff; React should have baked that into the core and completely removed that responsibility from the user unless they wanted to opt-in micromanage performance of their code.

> Things like updating reducer state by using a spread object, which creates a new object which can then send a system haywire

This is what you should be doing and not doing this seems more likely to cause problems. Do you have an example?

I'm of the opinion that Spring is 100% unnecessary and pretty much in all cases just straight up a bad choice. There's a ton of great companies that are built on it and depend on it, but man is using it unpleasant to say the least.

Admittedly I haven't looked at Spring w/ Kotlin at all, but I can't imagine it would solve fundamental annoyances I have with it (Why can't I capture logs globally while actually handling my exceptions locally?).

IMO the best library for Kotlin web stuff is http4k. Really nice documentation, first class integration for marshalling JSON with Moshi instead of Gson/Jackson, and very good, up-to-date consistent documentation.

I would love to use http4k, but last time I checked it lacked support for coroutines, which Ktor makes heavy use of.