Comment by ckaygusu | Hacker News Reader

Comment by ckaygusu | Hacker News Reader

Parent Full thread

Doing Typescript for a living.

2 out of 3 of the items you wrote down has to deal with old baggage, so whatever form of language you are dealing with those, you aren't going to have a good time. You can either bite the bullet and write the type definitions yourself, or just disable the type system altogether, which, if you can isolate it to a certain area in the code, you are fine.

If you are writing code that some other person is going to read and/or you are interested in having it behave reliably in the long run, I think a static type system is a must. Coupled with good unit tests, if the type checker does not complain, you can be very confident the code you wrote is working and will work for a vast majority of the cases.

Typescript is especially great because, unlike some other statically typed languages, you can choose not do use it in some cases (e.g., setting up mocks for tests, writing a small script to see how stuff works, etc), which is liberating.

I went from Python to Typescript. Python is still my go-to language for random tasks, though unless I have a good reason to do otherwise, I don't want to deal with a production codebase that does not do static type analysis anymore. I don't know others, but I just get more done in less amount of time in this way.

Strongly agree. Typescript is fantastic and extremely expressive.

I recently had to take over development of a fairly large legacy application and the first thing I did was convert the core of it to Typescript, that process uncovered a lot of bugs around handling of input/output especially lack of null/undefined checking. Typescript replaces a lot of the effort that used to spent on JSDoc type annotations and unit tests (of course tests are still required but it reduces the scope of possible input from any possible type to a smaller subset).

One thing that works really well with Typescript codebases is to push the untyped code (such as legacy libraries) and input validation to the edges of the application, and ensure the core is fully type safe.

“If you are writing code that some other person is going to read and/or you are interested in having it behave reliably in the long run, I think a static type system is a must.”

Can’t this be accomplished with JavaScript? Assuming your interested in clean code and best practices.

“Coupled with good unit tests”

Can’t you also write unit tests in JavaScript?

“if the type checker does not complain, you can be very confident the code you wrote is working and will work for a vast majority of the cases.”

This is a false sense of security. “Compiling” without errors just tells me I did not do something dumb like assign a string to an int. Is this really the main issue devs have? From what I have seen no… Devs usually need to chase down and understand the code regardless of type checking.

Thanks for your perspective!

> This is a false sense of security. “Compiling” without errors just tells me I did not do something dumb like assign a string to an int. Is this really the main issue devs have? From what I have seen no… Devs usually need to chase down and understand the code regardless of type checking.

I disagree. Working towards a successful "compile" isn't much different than TDD. The number of runtime errors I run into is significantly lower with TS than it ever was without which gives a very real sense of security.

You do need to understand the code but without types it can be very difficult to track down all the places that need to be fixed when you need to change your data model. Types are more important for refactoring than writing IMO

> Can’t this be accomplished with JavaScript? Assuming your interested in clean code and best practices.

There's nothing that prevents you from swimming against a stream, but we know swimming with the stream is faster. Same thing here. It's not impossible in javascript, but typescript makes code maintenance much more easier.

> Can’t you also write unit tests in JavaScript?

"Being more than sum of its parts" and all that.

> This is a false sense of security. “Compiling” without errors just tells me I did not do something dumb like assign a string to an int. Is this really the main issue devs have? From what I have seen no… Devs usually need to chase down and understand the code regardless of type checking.

Typescript does not solve all the software engineering problems. It makes common problems and annoyances much more easy to handle.

I don't have that much experience migrating codebases from JS to TS, but I do have experience converting codebases from C to C++. The corollary is that C++ is typesafe while C isn't. So you can call a function taking a point to an int with a pointer to a double, and the compiler won't complain (too much).

Word on the street says that C programmers are usually expert engineers that know what they're doing. Yet, I had to deal with those conversion errors all the time. That C code isn't a random CRUD application on a simple website. That can be software embedded in controllers in sensitive equipment, or equipment that will be harder to update. So it's even more important to get it right. And yet...

In C if you pass a pointer to double to a function expecting a pointer to int, that is a constraint violation (see 6.5.16.1 in the standard), and the compiler is required to emit a diagnostic.

For a good talk that discusses the boundaries of unit tests and the type system and how they overlap (or don't) I can highly recommend this video:

https://www.destroyallsoftware.com/talks/ideology

Reply on news.ycombinator.com