And I say that as 100% someone who wanted Gukesh to win from the beginning, which is a result I think is great for chess and I think is “objectively correct” in the sense that he has played better chess and has been (apart from Magnus Carlsen and his compatriot Arjun Erigaisi who is also a complete monster) the story of the chess world for the last year.

The best finale's are often when two players at their best duke it out, and one comes out on top. This was simply not Ding's best.

But it also introduces a lot of extra work "just to appease the type system". It rarely improves performance (if ever). Because TS has no runtime inference/validation, working with larger libraries or the browser can be a chore because half of your code are type signatures or casts.

So - not necessarily a naysayer, but I do believe that TS is oversold and with smaller teams/projects it might be slowing you down as opposed to helping.

every single time it is a reasoning flaw implementing a solution that is sub par and bug riddled. Had they just let types guide them, they would have become better developers and not had broken the application.

I am curious though. can you provide a snippet where types would be a disprovement?

An example of what I call "ceremony" would be

  interface BlockIndex {
    [key: string]: UploaderBlock;
  }
  const perServerId = {} as BlockIndex;
  uploaderFiles.map((fe) => fe.blocks.map((b) => b.serverId && (perServerId[b.serverId] = b)));

Something like:

    const perServerId = Object.fromEntries(uploaderFiles.flatMap(fe => fe.blocks).filter(b => Boolean(b.serverId)).map(b => [b.serverId,b]))

my expectation is that there are some packages/DOM typings so you don't need to write them?

regardless, your point stands: typing external dependencies is a pain.

Also Typescript sucks at keeping track of type changes in a single scope. While in Rust I can assign string to foo and then update it with int, I can't in Typescript. This leads to worse types or worse code for the same operation. Combined with typescript's lack of statements as values, conditionally initializing a value is pretty obtuse.

Those are the issues that come to mind right now.

This is literally always your problem with javascript, its only sometimes your problem with typescript. It's a weird argument.

> Also Typescript sucks at keeping track of type changes in a single scope.

Isn't this considered a very bad practice? Also rust does not allow this, it only allows shadowing.

> Combined with typescript's lack of statements as values, conditionally initializing a value is pretty obtuse.

Can you give an example?

For the second one: I know it is shadowing, what I mean is I find commonly that I'd like to have it in Typescript as well. In JavaScript is not necessary since I can just use the same variable.

For the third one: If I have some string variable that needs to be created from either one set of instructions or another, in Rust I do exactly that:

let foo = if x { ... } else { ... }

In ts your options are making it mutable undefined and mutate it inside the if else, using a very weird unreadable ternary, using an IIFE that returns into the constant, or creating extra functions to move the logic out. None of these are even close in readability, locality, or soundness to the rust example.

I find the _combination_ of those things that make it harder to write ts than js.

2: This is a programming practice I never see and would seriously question if its necessary ever, let alone "commonly". I think you may have picked up bad practices from writing in dynamic languages. Please see this for a few example arguments against this practice: https://softwareengineering.stackexchange.com/questions/1873...

3: You are now debating that Rust has better typing than TS, which makes sense because Rust is made from the ground up to have extremely well done static type checking, whereas typescript has to comply with dynamic typing originating from JS. It follows trivially that Rust has the better design because it has more freedom to do what it wants. JS < TS < Rust

it is not really an argument against typescript that Javascript is so bad that you need to spent time tracking your changes.

When do you need to do that? Can you give an example?

Requirements change and the code base needs to adjust with those requirements, that's gonna happen no matter what. I've met a lot of people trying to predict future requirements, deciding to overenginer today for a brighter future. I have very rarely seen anyone guess the future requirements accurately.

That’s not going to negatively affect your initial velocity, if it does, the team isn’t strong enough.

If the project is just a one off website or something genuinely small, sure, who cares? Otherwise it's worth realising that you'll be dealing with the fallout of poor early decisions pretty quickly.

This. Note also that "a poor decision" might as well be "have developers fight the type system instead of delivering UI and pivoting if users don't like it".

Mythical man month in action.

TS often can interrupt an individual's flow, so feels like a negative value. It's only when the whole team is using it on a bigger codebase with lots of changes that the benefits start to manifest.

I rewrote one of those projects in Typescript a while back, and came across a similar "clever" solution (mainly having to do with dates having potentially multiple sources, so being in potentially multiple formats), and it made the code _infinitely_ easier to understand. So much so that when I came back to it recently, one quick glance at the types for that section of code gave me all the information I needed to confidently extend that code without worrying about bizarre runtime errors.

People forget that even in single-person teams, you're actually working with many different "people" over the lifetime of the project, given how different you and your understanding of the context of your code will be over time.

Now imagine you go to a big city where they have a bunch of lines in the parking lot and people only half use them correctly, parking over the lines, diagonal, etc.

The existence of lines doesn't guarantee good behavior. The absence of lines doesn't guarantee bad behavior.

This is the argument I see for javascript-only folks who don't necessary enjoy using "the worlds most bloated javascript linter"

For the record, I am a Typescript enjoyer and I use it in my personal projects as well as professionally, but even I can admit that it's not automatically superior to javascript and it has a number of really frustrating and time-consuming downsides.

It's very easy to type the args and returns of a function and protect callers, but it's much more challenging to work with types between libraries and APIs all together. Lots of `as unknown as Type` or even the dreaded `any` to try and cobble the stack together.

For the record I don't like the syntax either. Combining ES type spreading with TS type annotation makes for difficult reading in my opinion. Why settle for this bastardized language and not just compile something made to be strongly typed into js?

But if you have a dev team that is taking the time to efficiently park in a respectful way, if you paint lines, _you're going to make that parking job a hell of a lot easier to do!_ And THAT's the big win of Typescript.

You're dreading javascript

I don't use it because the compiler is just too slow; waiting 2.5 seconds for even simple files is a massive pain. I want the old "CoffeeScript experience" where you compile stuff on-demand in development and output errors in the webpage or stderr. It works very well, is low complexity, and requires almost no effort. But you can't as it's just too slow.

esbuild doesn't typecheck so it's not an option. And hugely complex background builders are, well, hugely complex, it's not an option.

TypeScript-the-language may be nice, but TypeScript-the-tooling is not particularly great.

And even if this was solved: any build step will add complexity. The ability to "just" fetch /script.js and "just" edit it is quite nice. This is also why I've avoided CSS pre-processors since forever (needed a bit less now that variables are widely supported).

Of course different projects are different and for some projects these downsides are less pronounced. There is no one perfect solution. But there are definitely downsides to using TypeScript.

This is a fallacy similar to the Blub paradox: if your language has a weak[1] type system, then it isn't capable of recognizing many problems as "type error". But stronger type systems can express stronger invariants. So something that isn't a type error in one language will be a type error in another. This changes how the programmer conceives of problems.

Example: missing a case in a switch statement isn't a "type error" in C or Java, but it is a "type error" in languages like Rust or ML, because they have sum types with exhaustiveness checking. Other examples: array bounds checks can be eliminated with dependent types; lifecycle bugs like use-after-free and double-free can be eliminated with substructural types.

[1] "weak" in an informal sense of "not very expressive"

I suspect a lot of people might have had bad experiences with codebases which overuse complex types or trying to type things like Redux which is messy. When I use TS for personal stuff I’ll typically be a bit loose about things like any in places where I don’t care (for now) and I feel it doesn’t add much overhead, but I have been using it for a long time so it’s become second nature.

"problems that are due to typing" is a very difficult thing to unpack because types can mean _so_ many things.

Static types are absolutely useless (and, really, a net negative) if you're not using them well.

Types don't help if you don't spend the time modeling with the type system. You can use the type system to your advantage to prevent invalid states from being represented _at all_.

As an example, consider a music player that keeps track of the current song and the current position in the song.

If you model this naively you might do something like: https://gist.github.com/shepherdjerred/d0f57c99bfd69cf9eada4...

In the example above you _are_ using types. It might not be obvious that some of these issues can be solved with stronger types, that is, you might say that "You rarely see problems that are due to typing".

Here's an example where the type system can give you a lot more safety: https://gist.github.com/shepherdjerred/0976bc9d86f0a19a75757...

You'll notice that this kind of safety is pretty limited. If you're going to write a music app, you'll probably need API calls, local storage, URL routes, etc.

TypeScript's typechecking ends at the "boundaries" of the type system, e.g. it cannot automatically typecheck your fetch or localStorage calls return the correct types. If you're casting, you're bypassing the type systems and making it worthless. Runtime type checking libraries like Zod [0] can take care of this for you and are able to typecheck at the boundaries of your app so that the type system can work _extremely_ well.

[0]: https://zod.dev/ note: I mentioned Zod because I like it. There are _many_ similar libraries.

Also, when you have types it changes how you code itself. When I change a schema or refactor some function, I don’t need to think at all to make sure I’ve updated all the code that depended on the old schema or API; just fire the TypeScript compiler and it tells me everything that needs to be updated.

I’ve also not seen any issues for a long while where I’ve missed some conditional case, because I use discriminated unions with switch statements more, something that looks weird in normal JS but is very useful with types, since it tells me if I missed a case automatically.

Add that I’m managing a team of engineers, and so I can easily make sure they’re also not missing cases either, by setting the convention and having them see the light.

Putting aside other things like for instance always knowing that we’ve validated inputs for API endpoints since unvalidated inputs are the unknown type and therefore effectively unusable; or always knowing we’ve parsed and serialized dates correctly since we use branded string types to distinguish them from any other string with 0 runtime impact; the list goes on.

So yeah, it might just be the case that you haven’t actually internalized what coding with types even means, so you’re unable to imagine how it can help you.

https://news.ycombinator.com/newsguidelines.html

And nicely written TypeScript looks awesome, but badly written TypeScript can be a huge mess, as it can with any language, but TypeScript purists sometimes forget that the language is just a part of a nicely written and designed system.

Why not just appreciate the diversity of opinion and move on, rather than lecture people?

Some people feel more comfortable with JavaScript, Common Lisp, Lua, etc.

Some people feel more comfortable with TypeScript, Typed Racket, Luau, etc.

And that's okay.

Sometimes I just don't feel like dealing with those very few downsides though, but I can accept it's mostly personal preference.

At my age, sometimes I just don't want to deal with:

1. Yet another configuration file (tsconfig.json in this case). When something breaks, having one more place to look at is not something I want. The more extra files like this are needed for the development environment to even work (as in, something undesirable happens if you remove them), the less confidence I have in the project's long term reliability/stability.

2. That same configuration has misleading naming. The `"strict": true` setting should be called `"recommended": true`, or at least `"preset": "recommended"`, because it's not even strict. I would expect this `strict` flag to enable everything to the most restrictive way possible, and let devs disable checks (if) they don't want them. In its current state it doesn't enable strict checks like `noFallthroughCasesInSwitch`, `noImplicitOverride`, `noImplicitReturns`, `noUncheckedIndexedAccess`, `noUnusedLocals`, `noUnusedParameters` (I might be missing more).

3. Related to previous point: Inconsistencies between projects. So I work on one project with strict settings, tsc properly mentions possibly undefined accesses, etc; and then I move to a different project, and if I forget to context switch ("TypeScript config is different here"), I could be accidentally trusting the compiler to keep undefined accesses (and other stuff) in check, when it's not actually doing so.

4. Last time I checked, I couldn't just have a git repo "foolib" that is 100% TypeScript (100% .ts files, zero .js files), and `npm install` that repo on a separate project, and have it Just Work™. There's always extra steps that need to be done if you want to use .ts files from a separate package (usually compile to .js and install that; or using a bundler (read first point again)).

5. Why does the "!" operator even exist (or at least, why isn't there a flag to forbid it (for example the strict flag)). In my experience, using it is just developer laziness, where someone just doesn't want to write proper checks because "it's noise".

---

Those 5 points came off the top of my head so I'm almost certainly forgetting stuff.

It's mostly "death by a thousand cuts" kind of stuff, so sometimes I might not mind, but other times I might not be in the mood to deal with this and heavily influences my decision to go with TypeScript (keeping it approachable to as many people as possible) or a different language/ecosystem altogether.

Yes, I could "just" write a package that I can just npm install and it autoconfigures TypeScript and other stuff for me (and I have done so, for my own sanity). But I shouldn't need to do that, and it's too brittle for my taste.

There's a gas heater on the market that works by using rapidly moving vanes to induce shock waves in the gas. The outflow has the nearly the same pressure as the inflow, but the gas has been heated, potentially to a temperature higher than could be achieved by resistive heating elements. EDIT: I mistated this; see below for link.

Consider also that once the shock heated air around the reentry vehicle has expanded back to ambient pressure, it will be hotter than it initially was.

Similar to re-entry heating: the specific kinetic energy of the returning capsule is many times greater than would be required to melt and vaporize any material. So why do things survive re-entry? Because most of the energy is dissipated in the bow shock, significant distance away from from the capsule, where air gets heated to temperatures higher than the surface of the sun when other air slams into it. The purpose of the heatshield is to protect from radiative heating from the bow shock, not convective heating. Ablative heatshields do not work because ablation consumes energy which removes heat (again, there is sufficient energy going around to ablate the entire craft), but because they place a shade (made of ablated carbon particles) between the bow shock and the craft, which shields it from the radiative heating.

In this case the entry regime was such that convective heating far outweighed radiative heating.

I mistated slightly: the gas is accelerated to supersonic speed then slowed in a diffuser, where shock waves heat it.

When the gases decompress they'll be a lot cooler, just like your AC.

https://ntrs.nasa.gov/api/citations/20140012475/downloads/20... (see slide 7)

Thanks for spreading sanity and insight -- I hope someone else digests your message sooner than I did.

Why? If 99% of code bases are bad and it's the baseline condition, why should I try to move things in a better direction?

OP proposed better coding practices and got ignored. OP proposed adding some automated lint checking, etc, and got mocked for it. OP is trying to make things better, and will suffer for it. OP comes to HN and doesn't get any better reception for his ideas either.

I think OP should hold on to his opinions and make sure his resume is up to date.

Code is like entropy: it's natural tendency is to become disordered and not suit the current problem domain.

In order to fight entropy, you need to perform the unnatural act of ordering back and sorting out the code you wrote based on your current understanding of the curremt state of your problem domain.

Also keep in mind that developers continuously gain experience, and gather insight into what works or not, and refine their expertise with time. Your yesterday's code is worse than the code you'd write today. By definition this means that when you look at all the code you wrote, it all needs improving.

> OP proposed better coding practices and got ignored.

He didn't. He proposed wasting time adding comments and dump onto someone else the responsibility of cleaning up his mess. That is not helpful and should be laughed out of the room.

At that point, you lose the feeling that there are magic things out there that you will never understand and that for the most part everything is just regular old code that regular people wrote.

I don't really remember when I felt that external dependencies were magic, but thinking about this, it explains a lot of the behavior I see on some developers who are very negative about the more challenging parts of the job.

Some of them don't really believe the research stuff we do at work are even possible. They're constantly surprised when other devs finish those tasks. Some don't believe that other devs can code in C++ or Rust, or write parsers, database modules, implement IQueryable in C#, or develop novel algorithms for novel applications.

To them, if a package exists it must just work, and that package comes from another breed of developer that can't coexist with them. I see a similar thinking with AI: now with ChatGPT and GPT-4, there's a hubbub about there being "no reason for our AI team to exist anymore".

I'm not a big fan of working with those developers.

I agree. And it ties into something I often see that puts me on edge: programmers not taking responsibility for the code they put into their projects.

What I mean is that when you incorporate any code, from any source (library, framework, copypaste, etc), then you are responsible for that code and its proper behavior as much as for the code you actually wrote. So you're well-advised to understand it.

That's one of the reasons why I won't include code that I don't have the source code to. I need to understand it and be able to fix it.

The "out of sight, out of mind" approach doesn't really work for code you're actually responsible for.

So the go to for every solution is to find a third party library from a “real” witch or wizard, and follow its basic tutorial. Maybe try to customize it a bit at most.

If something breaks, just start randomly moving things around or copying and pasting more code from forums until it works.

I can’t live like that. I need to know why something’s not working, AND why it IS working. I like stepping through my code with a debugger just to make sure things look right, even when they’re working.

I think the craziest part, though, is just how much people with this “software is magic” mindset can actually get just by brute force cobbling things together.

To me the issue is they assuming everyone around them is like this. I'm totally fine with lack of experience or knowledge, but a co-worker constantly underestimating their peers is not alright.

Where it really stings is when I do something of my own initiative (like, for example, create a transparent API over memoizing and caching some expensive calculation, or refactor some of our common client customizations into their own set of classes so it’s easier to extend) and he ignores it or scoffs at it.

Only to then find a third party library that implements something similarly. THEN it’s presented to me as a “brilliant idea” that we can take advantage of.

At that point, when I say “we” already do this, he usually rephrases what his brilliant 3rd party library does, as though he can’t fathom that I would be capable of doing something like that myself, and clearly I’m just not understanding what he’s telling me.

I think it’s a defensive mechanism for his ego against one of his peers or employees being more capable than he is.

But it’s also not like he can’t learn this stuff himself, he just doesn’t ever put in the time or effort.

For, say, security implementations for authorization and access controls, or even low level HTTP request routing? Absolutely. The goal there is to adhere to something standard and battle tested by experts, and the third party libraries tend to be fewer in number, and of higher quality, with longer term support and clearly defined upgrade paths.

But that’s the lower level stuff, where your special custom needs are superseded by the primary goal of just “doing the one right thing”, or “adhere to the commonly agreed upon standard”.

For all the other things that make an app unique - things like CSS frameworks, UI components (beyond basic, accessibility-minded building blocks), chart drawing, report generation and caching - my experience has taught me otherwise, the hard way.

Being stuck using a 3rd party library that doesn’t do what the client or business needs it to do, having to juggle our own internal patches and bug fixes with updates to the library itself, all only to have the library abandoned or deprecated in favor of the author’s next pet project, really sucks and often comes with a high opportunity cost and a high development cost.

I now consider third party implementations of higher level features (and especially anything front-end) to be something that needs to be evaluated as equally costly as an internal implementation by default, and not favored just because somebody else wrote it.

Maybe I’ve just been unlucky in my experience, though. I also suspect ecosystem makes a difference. The PHP and JS ecosystems are full of poor libraries with snake oil sales pitches. I suspect this is different with, say, Rust.

I’ve mostly worked with Python and JVM languages, which probably explains why I’m less passionate about the counter-argument than you are. Ecosystem definitely matters a lot. VanillaJS is the only good JS framework IMO.

That mediocre dev is a straight shooter with middle management written all over them…

It's a matter of preference but IMO/IME it works better when a manager is actually good at it.

A manager that is supposed to be technical but only wants/knows how to do the management part, and can't make more than the basic stuff won't really fly. I've seen a couple of those getting fired during probation period.

On the other hand, the "bad developer" that thinks packages are magical will eventually settle as an expert beginner in a low-expectation environment. Which is fine.

Dotpeek is integrated into Rider and is a world class decompiler. It also integrates into Visual Studio either standalone, or with ReSharper.

You can also integrate external source symbol servers into your IDE of choice as well that will let you debug into libraries seamlessly.

If you highlight a method you call from external code and hit CTRL + F12, Visual Studio will automatically decompile it for you.

In the case of non-compiled languages, of course you don't even need this step since all your libs exist in source form already, so it was pretty simple for me to step through Ruby library code with a simple debugger and no fancy IDE.

I have a habit of sometimes debugging even horribly abstract framework (e.g. Spring) code when I don't understand what it's doing. That's maybe not the most efficient method, but it does usually make me understand why thing X is not working the way I expected it to work.

I think the real skill then is to learn to navigate big codebases in few days time than taking a few weeks and then feel dejected by the time spent and still unsure.

I often feel ambitious for such endeavors but navigating big codebases take time, any tips?

More importantly is to use an IDE with a good fast global search function and get comfortable with it. At least for me, 99% of navigating a large codebase is global search.

You can goto or peek definition in VSCode. And the find tool has the option to find all occurrences throughout your project.

Imagine buying a hammer, that hammer not working, the hammer's design being so complicated that it's impossible to understand or mend, and then having to design and build your own hammer, and then putting up with that situation over and over again and accepting that as the status quo. That would be the correct analogy.

We have do have tools like the hammer - there is one design, everyone more or less agrees on it. There is still high quality and low quality, but it has one job. We have tools like a bulldozer - complex, numerous parts, requires constant maintenance, closed source.

As the parent said - it is not uncommon to have to maintain old equipment, as well as design new tools as new requirements pop up.

Sure, our rust is a little bit different - time wears on software in a different way. Use wears on software differently. (Changing product requirements leading to a new tool is probably common.)

The maintenance may be trickier - but I'm sure changing components on a tool when a certain component is no longer available is not easy, thats where shim layer comes from!

This was and is quite common in any blue-collar field where works don't always have the money or time for a brand new jawn every time something goes wrong.

I love estate/yard/garage/barn sales and going through the tools and reading the tales they tell from their wear patterns, field repairs, revisions, and hacks from their owner.

Case in point, here's a tool which has gotten multiple leases on life through modifications. https://youtube.com/watch?v=oTA513ttrbQ

For example, I have a graphics project where screen tearing suddenly started appearing although my code didn't change, and the tearing wasn't there before. Is the issue in Skia, OpenGL, the graphics driver, the Intel or NVidia GPU, or the OS? Or is it some latent issue in my code that started showing up because of a change in these dependencies? Or is it some other complex interaction between multiple dependencies? I couldn't possibly know, and I actually don't think there is anybody that actually knows. And there is zero chance I could ever figure it out. I mean, it at least appears it was a driver issue as after some updates and a reboot it just went away, but there is zero insight into why or what actually made it go away.

If I modify a plow because some part as originally designed was flaky and constantly broke, you usually know to a pretty good degree why your fix works.

In software, the abstractions are such that it is practically impossible atbtimes to understand.

Sure, welding back on a hardpoint that broke off a plow is concrete and obvious (maybe that's analogous to fixing a broken dependency that got renamed), but there are other fixes that definitely fall under "I don't know why it works but it works". I've had electrical gremlins and fixed them by grounding something that looked like it ought to be grounded, and was grounded when I tested for continuity, but nonetheless was acting floaty. It was probably a loose connection elsewhere in the system, but I didn't know that for sure, nor do I even know that it was the problem in the first place.

Software definitely reaches insane depths of complexity, but again, if you can dig down and understand the abstraction well enough to attempt a fix, and the problem goes away, isn't that good enough? The real difference is mechanical systems typically only have a few layers of abstraction, while software has dozens to thousands of layers of abstraction.

A mine site usually fixes its own tools used to do their job, they usually fixed things they've purchased to use that are broken or become broken, is that not the same?

On a mine site, the job is to mine and process minerals. That includes engineering a mine using products that eventually fail over time and need fixing. As part of that process an automotive electrician may need to fix the electronics on a vehicle that have become faulty or damaged.

Mechanics and engineers need to inspect, rebuild, and fix the tools they are given to do their job. The difference is that yours may not work up front, whereas these tools need maintenance over time.

The difference between most professions and programming is that we have open source. The equivalent of that in the real world is getting blueprints to build our tools and then building them ourselves, with no guarantees.

Very different situation

I've also found that the software industry obsesses over tools more than any other industry

For React devs, this means learning how React actually works under the hood.

The other thing I find is that big libraries are either mostly dependency bloat (as implied above) or dealing with a hard domain problem. If it's the latter, what you're really struggling with is not the library, but the domain it's trying to represent.

But this doesn't change anything of the programmers problem. If I stumble on a bug in a physics libary I am using for a game, I cannot just jump right into there and go fixing things. I mean I can start doing it, but at the cost of not getting anything else done for quite some time.

There are lots of hard domains in programming. Cryptography is hard. Networking is hard. Fast rendering is hard. Efficient DBs are hard. OS are hard. Drivers are hard.

You can maybe fix a trivial error in such libaries, but everything else is usually a (big) project on its own.

Additionally, once you recognize that you can also recognize if you’re dealing with incidental complexity (e.g. poorly thought out/designed code) and inherent complexity (e.g. physics calculations). The former can be fixed, the latter cannot. Knowing the difference saves much pain.