8 ms·
Note that Stripe is working on a type checker for Ruby: https://sorbet.org/ https://sorbet.org/ I second the sentiment though. I wouldn't choose to use plain J
by dguo 7y ago
Note that Stripe is working on a type checker for Ruby: https://sorbet.org/ 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.
- gregkerzhner 7y agoHaving partial type safety is like having a no peeing section in the pool.
- dguo 7y agoTo 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.
- lmm 7y agoLifeguards 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.
- jjeaff 7y agoThat'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.
- tristanstcyr 7y agoIf you properly do validation at runtime this can be true, but it's a manual process that's not verified by Typescript.
- simplify 7y agoWould you say the same about incomplete testing?
- gregkerzhner 7y agono - 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.
- cdata 7y agoA 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.
- lmm 7y agoDoes 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.
- tristanstcyr 7y agoIt does not.
- xsmasher 7y agoIt 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.
- yyyk 7y agoBoth 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.
- Analemma_ 7y agoI 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.
- Ididntdothis 7y agoAgreed. 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.
- yyyk 7y agoThat'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...
- Fellshard 7y agoHowever, 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.
- dpc_pw 7y agoThe 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
- uyuioi 7y agoOr you could just use Crystal Lang and get types and 20x performance instead.
- bananabreakfast 7y agoDoes Crystal run rails?
- ncphillips 7y agoThat 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
- rblatz 7y agoYou 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.
- tluyben2 7y ago> 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.
- JMTQp8lwXL 7y agoForegoing 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.
- tluyben2 7y agoThe 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.
- Aeolun 7y agoOne 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.
- tluyben2 7y agoSorry, 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];