Hacker News Reader

Comment by dguo | Hacker News Reader

Note that Stripe is working on a type checker for Ruby: https://sorbet.org/

I second the sentiment though. I wouldn't choose to use plain JavaScript over TypeScript for any significant project.

You might ask why I wouldn't just use a more fully typed language like Java. My main response is that I love having the flexibility to choose how strict the types should be. Sometimes, typing something out fully is not worth the trouble. Having escape hatches lets me make that choice. While I enjoy using types to turn runtime bugs into compile time errors as much as possible, it's not the right thing to do 100% of the time.

View on HN

> it's not the right thing to do 100% of the time.

What is an example of this in your experience? I am trying to think of one, but after 25 years of programming, I cannot say I have ever encountered a case where it was worth using ‘an escape hatch’ that did not bite us later on. Maybe it is the type of software/clients I work with, but ‘the trouble’ is not really something I have seem before I think.

Foregoing types isn't like other escape hatches. Sometimes you'll get odd, hard-to-understand errors from the typescript compiler. On my team, we just use Babel, so we can write TypeScript (and get the benefits of types) without have 100% statically-correct code. Getting from 99% to 100% statically correct is time spent detracting from other more valuable contributions to the business, that don't have a meaningful impact on code quality. Diminishing returns.

The OP mentioned this in the context of ‘why not a fully statically typed language’, aka a language that, unlike typescript, does not return hard-to-understand errors; given such a language, what is an example that falls in that 99-100% 1%? I do not know of such an example and I am curious.

One example is that TS does not enjoy you going from string enum keys to an actually typed enum, but you can fake it by casting to ‘any’ first and then to the new type.

Sorry, but that was not the question; the question was about examples on a statically typed language like Java (or Kotlin, C# etc), which is what the OP mentioned.

Statically typed languages do not 'enjoy' going from strings to enums, which is excellent news by the way, but you can convert them Enum.TryParse() to handle them properly. I cannot really see how it is 'more work' to do that; the 'any' solution seems not much easier compared to C# TryParse or even the TS one;

     var color : Color = Color[green as keyof typeof Color];

The case is when you are lazy and choose to introduce technical debt into your codebase by using the escape hatch.

Both C# and Kotlin have a 'Dynamic' type for just that escape hatch. IMHO, That's a better way over TS - since types might not be the right thing 100% of the time, but they are 95% of the time.

I programmed professionally in C# for about eight years and in that time I can count on one hand the number of times I saw the ‘dynamic’ keyword. Nobody seems to think it’s worth the effort or confusion.

Agreed. It’s also not as easily used as “any” in TypeScript. I would probably reject a C# codebase that uses dynamic widely. It’s only good for very local use like some serialization or deserialization.

That's my experience as well, I just wanted to note that the escape hatch exists.

Maybe I should have amended my comments for 99% of the time? Or perhaps that there are other functionalities (e.g. tuple types, reflection) to to make working with types almost as easy as without? I use reflection very frequently...

However, in JavaScript-world, where the external types you interact with - from other libraries, from APIs, from the browser itself - are poorly defined, having that escape hatch becomes a sanity-saver, does it not? That's where the power comes from: the squishy, fuzzy, less structured edges.

The parent-parent comment was "I want an escape hatch in the language" and then the argument for it is "someone else used an escape hatch, and now I need an escape hatch". :D

Well, yes, most of the packages available in the JS ecosystem were written in JS. The easiest way to retroactively write typings is to use `any` all over the place.

> having that escape hatch becomes a sanity-saver, does it not?

No, it does not. There is no difference between static languages and dynamic languages when parsing data at runtime.

Samesy.I almost used dynamic last week for maybe the first time ever, but ended up with a simple generic class instead.

In a past life I did some real wizardry with dynamic in C#, drastically improved performance on a thing that had been using strange combinations of T4 compile-time templates, Reflection.Emit, and some very kooky multi-database lookups with a custom IDynamicMetaObject provider.

It was definitely worth the effort then. I also recognize why it is a very unlikely scenario to repeat.

The other place where I used dynamic most heavily in C# was that it was really great for IronPython interop where you could have a bit of "data science" done in a Python module, build that to a .NET assembly and call into the Python module from C#. (Though the other direction was more common, using IronPython to do data science around a bulk of C# models and code.) With so much more data science since that past life of mine having moved to Python, it's almost a shame that IronPython hasn't really kept up.

Not a pro C# dev but I use it quite a bit - IIRC the correct keyword for that situation would be 'var' which is similar to 'auto' in C++. It just statically infers the type from the assignment, while 'dynamic' actually does runtime casting. I use 'var' all the time, I use 'dynamic' only when working with JSON objects and such.

If you are unaware, you can work with JSON objects in a strongly typed way using JSON attributes on POCOs e.g.

https://www.newtonsoft.com/json/help/html/SerializationAttri...

I would avoid using dynamic (I believe underneath it is basically the same as the Dictionary<T, U> anyway, howeve r I don't really care to look it up).

Also regarding var. It is best IMO to use var when evident i.e. If the var right hand side is obvious what the type is use var, if it isn't use the Type name.

e.g.

When you should use var (it is evident from the right hand side)

    var name = "Joe Bloggs";

vs when it isn't evident:

    var myVariables = _service.SomeMethod();

It allows the code to be better read without the IDE. However obviously it is up to you.

    var myVariables = _service.SomeMethod();

Sure when you write non-obvious code `var` sucks. But:

    var product = service.FetchProduct(productId);

If the type of var is not obvious to you then you have bigger problems to worry about.

https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

> Use implicit typing for local variables when the type of the variable is obvious from the right side of the assignment, or when the precise type is not important.

> Do not use var when the type is not apparent from the right side of the assignment.

> Do not rely on the variable name to specify the type of the variable. It might not be correct.

Your example has me inferring the type from the method name which isn't dissimilar to what they are advising against here.

TBH I should have known I would get a comment like this, where everyone lives in utopia and everything is always obvious to another person, nobody ever had a bad nights sleep or not feeling their best etc etc.

There are plenty of times where it may not be obvious what the Type it is returning even with quite decent coding standards and in any event I think it helps readability and isn't a huge ask. You can get Resharper / Rider to do this as a project setting (Visual Studio can probably do this out of the box now) in your repo and then the IDE will just do it for you.

MS recommends suffixing `Async`, and VS by default names fields with underscore but the C# naming suggests Pascal. So referencing MS docs is hardly justification.

So? because you disagree with some parts of it, all of it is a bad idea? That is a poor argument.

I've justified quite clearly why I think it is a good idea and in my original post I said quite clearly "It is upto you". It is trivial to turn on in the IDE and it improves readability outside of the IDE.

Kotlin is a backend language tho?

I saw other commenter say that the benefit of using TS in the frontend and backend, then DB updates in the backend also update the frontend code: "The beauty of Gary’s setup is changes to his database update the types for the server side Code AND client side code. The value of that comes from using the same language in both platforms"

Can you get this sort of benefit with Kotlin? How?

It’s not used widely (yet?) but Kotlin does also compile for browsers and full stack kotlin react apps are a thing.

https://kotlinlang.org/docs/reference/js-overview.html

I would love to do frontend Kotlin, but is it one of those things that you end up painting yourself in a corner and wishing you used TypeScript all along?

"Don't do frontend development in anything else than JavaScript ... You will probably run in to an abstraction leak that causes problems if you do the frontend in Kotlin." https://www.reddit.com/r/webdev/comments/etzy5u/web_developm...

I ask this seriously. I would love to do full-stack Kotlin. I just don't want to take the plunge and later realize it was a big mistake.

I have only played a little with the Kotlin web stuff, but no I would not recommend doing anything serious with it.

I think JS/TS are king because of the ecosystem and wealth of documentation. My experience with more "niche" front-end languages is that you have to do much more yourself or have lots of messy interactions with plain JS libraries.

But even if Kotlin JS had an enormous ecosystem, I'm not sure I would love it. What I love about Kotlin is that it is a great replacement for Java. Interoperating with java has zero performance overhead and zero mental overhead. Because of this and Kotlin's general closeness to Java, many more places writing JVM code are comfortable with using Kotlin compared with other JVM languages like Scala or Clojure. Kotlin cleans up the Java syntax and adds nice features like type inferencing, non-null by default, coroutines, blocks, extension functions and so on.

But if we're not on the JVM, I'm definitely not sold on Kotlin as the perfect language or anything. Sealed classes are nice, but still not as nice as tagged unions. As far as type systems go, I think the one in TS is more flexible and expressive.

Like Kotlin, what I like about TS is the zero mental overhead integration with JS and the JS ecosystem. But if we're not tied to a browser, I guess I wouldn't ever really want to program in TS.

Node is kind of remarkable in that it is the backend platform that is most similar to a browser, which makes these full-stack setups a little more natural. Not sure I'm sold on their value in general since most teams are going to be big enough that front-end and backend code are written separately. If you want to keep types in sync, I think graphql or protocol buffers are better solutions.

That is usually the outcome of not using platform languages, semantic mismatch with the platform, not able to use the libraries without some kind of FFI or wrapping code, needing extra tooling for debugging.

TypeScript gets away with it, because it follows the C++ Trojan route, without the type annotations it is just JavaScript.

Do you think Blazor is doomed to fail because of this?

I don't think so.

Blazor is the new Silverlight.

I might be very critical of how WebAssembly gets sold, but one thing is certain, unless browser vendors decide to rip it off, with WebGL/WebGPU + WebAssembly, a few of us will be getting our beloved Flash, Silverlight, Java back, even if in different kind of clothing.

It's early days. 1.3.70 was only released a few weeks ago and featured a major overhaul of the kotlin-js related tooling.

I gave it a quick try a few weeks ago and it's actually nice. Before that, it wasn't really usable (dead code elimination was a problem, webpack integration kind of sucked, etc.). With the new tools, it's stupidly easy. It uses webpack and karma underneath but it's all driven from gradle and it works without any webpack or karma specific configuration (you can customize of course). You can depend on both npms and kotlin-js jars. There's a gradle plugin under development that translates typescript declarations for npms to kotlin. So, the development experience is pretty nice. But it will take a while for this to mature and get more users. IMHO the upcoming 1.4 release might kick off some adoption.

IMHO what it needs is proper kotlin frameworks for frontend. Yes, you can use vue and react, etc. But they are kind of optimized for people used to untyped blobs of json. Slapping the word state on this does not quite get you to a level that would be comfortable to a Kotlin developer that also develops for Android. IMHO, it's just a matter of time before people discover 1) you can now do frontend with Kotlin and it doesn't suck 2) we should just scrap the few hundred kb of code that actually gets imported at runtime (i.e. react and related cruft) and build that up from the ground and 4) there's a ton of stuff that was already done for Android that ports over relatively well to the browser world. That's actually a lot less work than it sounds like because the runtimes for frameworks like react and vue are tiny.

Reimplementing react seems to be a rite of passage these days for a lot of people and doing that in Kotlin doesn't sound like it should be that big of a deal. You might be tempted to just use the DOM directly and people do that as well. State management when you have proper data classes, co-routines, channels, etc. becomes a whole different game than throwing balls of untyped json around via global variables.

IMHO this is actually true for typescript as well. The next logical step for typescript would be to cut loose from its js legacy and start having it's own frameworks.

React in Kotlin sounds stupidly simple. I’d very much like this, but we can’t really change our whole app from Typescript now anyway.

Or you could just use Crystal Lang and get types and 20x performance instead.

Does Crystal run rails?

That is a cool project but you’d still have to keep it in sync with your frontend code. The beauty of Gary’s setup is changes to his database update the types for the server side Code AND client side code. The value of that comes from using the same language in both platforms

You aren't bound to use the same language on both platforms to get this functionality. I had this running 3-4 years ago using C#, EntityFramework, and a d.ts generator that I forgot the name of.

A change to the DB schema just required me to refresh our edmx from the DB schema and then build.

Having partial type safety is like having a no peeing section in the pool.

To your point, I do think it depends on the team and their ability to make good judgment calls.

But type safety is a spectrum anyway. One could say that not having dependent types is like having a swimming pool without a lifeguard.

Should every swimming pool in the world have a lifeguard? Probably not.

Lifeguards are expensive. Basic typing is damn near free. More languages should adopt dependent typing, but for the moment there are languages that lack it and offer enough advantages to make up for that. I don't think you can say the same thing for languages without a true type system (one in which unsoundness is the exception rather than the rule) - there are too many good alternatives for it to be worth compromising on that.

That's not true. There are plenty of cases where certain pieces of software is cordoned off and/or non-critical that would not affect the rest of your stack if they fail.

If you properly do validation at runtime this can be true, but it's a manual process that's not verified by Typescript.

Would you say the same about incomplete testing?

no - proper unit testing mocks dependencies, so untested dependencies shouldn't affect tests. However, if there are typing issues in your dependencies, even the code that strongly typed can crash as a result if it uses those dependencies.

A more accurate remix of this analogy (for the TypeScript case) is that it is like building a wall around the part of the pool that you actually swim in, and allowing that folks can pee all they want as long as it is outside of the boundary you built.

Does Typescript actually add runtime checks, even for e.g. container types? I'd be very surprised if it did, because that would mean a lot of overhead.

It does not.

It makes it really easy to add type safety to parts of a legacy project as you go along; for new projects you can enforce type safety with a linter or stricter compiler settings.

Reply on news.ycombinator.com