[dartos]

I don’t think I agree that either typescript nor rust successfully hide the complexity in their type systems.

By the nature of type systems, they are tightly coupled with the code written around them.

Rust has rich features to handle this coupling (traits and derives), but typescript does not.

[andrewflnr]

It's not about hiding the complexity in the type system, that is, the complexity of the type system. At least for Rust, it's about that (yes, complex) type system isolating the even worse complexity of tracking lifetimes and aliasing and such, for all possible control flow paths, in your head.

It's harder to summarize what Typescript is isolating, except that JavaScript function signatures are the flipping wild west and the type system has to model most of that complexity. It tends to produce very leaky abstractions in my experience unless you put in a lot of work.

[mmis1000]

Sometimes the original js function isn't safe at all. So does the typescript definition.

For example, `Object.assign` overrides all property with same name. Sometimes you use it to construct a new object, so it is a safe usage. But what about using it to override the buildin object's property? It is definitely going to explode the whole program. However there isn't really a mechanism for typescript to differ the usage is safe or not. So in order to maintain compatibility, typescript just allow both of them.

And typescript in my opinion don't really isolate very much complexity. But it does document what the 'complexity' is. So you can offload your memory tax to it. Put it away, do something else, and resume later by looking at what definition you write before. In this way. It can make managing a big project much easier if you make proper use of it.

[andrewflnr]

Yeah, TS is kinda rough that way. It's not my favorite. Harder job, rougher results, understandable to be honest.

[tomnipotent]

The argument isn't that complexity is being hidden, but how it's managed and where it shows up in your experience of solving other problems. OP mentions:

> The complexity was always there... it merely shone a light on the existing complexity, and gave us the opportunity — and a tool with which — to start grappling with it

It's not about Rust vs. TypeScript per se but uses garbage collection and borrow checker as examples of two solutions to the same problem. For whatever task you have at hand, what abstractions offer the best value that lets you finish the solution to the satisfaction of constraints?

> they are tightly coupled with the code written around them

Which is where the cost of the abstractions comes in. Part of the struggle is when the software becomes more complicated to manage than the problems solved and abstractions move from benefit to liability. The abstractions of the stack prevent solving problems in a way that isn't bound to our dancing around them.

If I'm working on a high-throughput networked service shuffling bytes using Protobuf, I'm going to be fighting Node to get the most out of CPU and memory. If I'm writing CRUD code in Rust shuffling JSON into an RDBMS I'm going to spending more time writing and thinking about types than I would just shuffling around arbitrarily nested bag-of-bags in Python with compute to spare.

I always thought this was why microservices became popular, because it constrained the problem space of any one project so language abstractions remained net-positives.

[dartos]

> how it's managed and where it shows up in your experience of solving other problems

That’s what I’m talking about. Encoding complexity in your types does not manage where that complexity lives or where you have to deal with it.

It forces you to deal with that complexity everywhere in your codebase.

[tomnipotent]

> It forces you to deal with that complexity everywhere in your codebase.

The alternative is fighting the abstraction. Imagine trying to write the Linux Kernel in JavaScript or Python. Lot less fighting types in your code, more time fighting the abstractions to achieve other things. Considering a big part of the kernel is types it makes sense to encode complexity within them.

Going "low-level" implies that you're abandoning abstractions to use all the tools in the CS and compute toolbox and the baggage that entails.

[knome]

I didn't get the general idea that the author thought they hid the complexity, but rather that they exposed and codified it. They gave the complexity that would previously live in your head somewhere it could be expressed. And once expressed, it can be iterated on.

[dartos]

Encoding complexity in your type system forces you to deal with that complexity throughout your codebase. It doesn’t give complexity a specific place to live.

[knome]

You were going to have to deal with that complexity either way.

Now it's expressed somewhere, and if you craft it right, enforced so it's harder to get things wrong.

https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

[BigJono]

This view has always been bullshit. It doesn't differentiate between the complexity of the types themselves and the complexity of representing them in a static type system.

[sfn42]

It certainly isn't bullshit. I take advantage of type systems every day to help me write code that works on the first try. Obviously I'm not saying all my code works on the first try, but it often does even when it's quite complex.

The main problem is that a lot of developers don't know how to use the type system well, so they write code in a way that doesn't take advantage of the type system. Or they just write bad code in general that makes life difficult despite a type system.

It doesn't solve all problems, but if you use it well it can solve a lot of problems very elegantly.

[yakshaving_jgt]

If you parse a value into a guaranteed non-null value at the system boundary, then you have eliminated the need to check for that nullability throughout the rest of your codebase.

Did you mean to write the literal polar opposite of what you wrote?

[atoav]

Type systems like in Rust may introduce their own complexities, but they also help you tackle the complexity of bigger programs if wielded correctly.

Typesystems can be complex to use, but in the end they constrain the degrees of freedom exposed by any given piece of code. With a type systems only very specific things can happen with any part of your code, most of which the programmer may have had in mind — without a type system the number of ways any piece of code could act within the program is way larger. Reducing the possible states of your program in the case of programming error is a reduction of complexity.

Now I don't say type systems may introduce their own complexity, but in the case of Rust the complexity exposed is what systems programmers should handle. E.g. using different String types to signify to the programmer that your OS will not allow all possible strings as file names is the appropriate amount of complexity. Knowing how your program handles these is again reducing complexity.

Imagine you wrote a module in a language where you don't handle these. Every now and then the module crashes specifically because it came across a malformed filename. Or phrased differently: The program does more than you intended, namely crashing when it encounters certain filenames. Good luck figuring that out and preventing it from happening again. With a type system the choice had to be explicitly made during programming already. Less things you code can do, less complexity.

Many developers confuse complexity of the internal workings of a program with the complexity of the program exposed at the interface. These are separate properties that could become linked, but shouldn't.

[earth_walker]

Abstractions are a way to manage complexity - hiding things is only one way to do that. Deciding how to organize it, when and how to expose it, and when to get out of the way, are all important aspects of designing abstractions.