7 ms·
“The days of using untyped languages on non-trivial projects are over.”
- jghn 3y agoI always wonder why inference a la Hindley-Milner isn't what people push as the best of both worlds.
- alwaysbeconsing 3y agoInference for static types requires more from the compiler in two key ways that impact the developer experience. First, it's just plain more work to do when compiling, so compile times are longer than they might otherwise be. Second, error handling and messaging needs to be written very carefully to avoid dense and unhelpful output when inference fails. It's positive in many ways, but it's not a free lunch.
- jghn 3y agoIt's not a free lunch. But it's better than in projects where I'm forced to supply a type annotation everywhere in a dynamic language.
- nathias 3y agoI hate TypeScript so much it's unreal. A MS trojan horse to try and own the full stack, I hope you'll all be happy when we won't be able to use any of our tools without complying to corporate linguistic standards and watching the mandatory 20m of commercials per code scope.
- wellanyway 3y agoNaivety of people in software development is something else. Billion dollar corporation hired 10 token nonbinary people and people just forgot, if they ever knew the history.
- numinos1 3y agoThat will undoubtedly happen. But hopefully by then we'll have moved on to more fertile ground.
- tmpz22 3y agoIt’s disappointing that a lot of arguments for typing fail to explore why untyped languages became popular to begin with and how those benefits can be maintained throughout the migration process through partial typing To complete typing. When typing is applied gradually throughout a codebase it can sometimes manifest as the worst of both world and a complete argument should at least acknowledge that as well as the impact of bad typing on codebases.
- Pet_Ant 3y agoWhat are the downsides of gradual typing on a codebase? I've never worked with it, but watched some talks on it and it really sounds promising. I understand the downsides for compiler complexity and for performance, but not on the codebase itself.
- sublinear 3y agoIt's not that the general idea of "gradual typing" is bad, but that strong types become a leaky abstraction in practice. If you have to constantly fight against the weakly typed nature of the underlying language, that defeats the point. Here's a writeup on it. https://www.onux.com/jspp/tutorials/type-system#Appendix-B https://www.onux.com/jspp/tutorials/type-system#Appendix-B > The problem is not as simple as taking the ECMAScript grammar and augmenting it with type annotations. There's a reason that Microsoft (TypeScript, Safe TypeScript), Google (AtScript, SoundScript), and Facebook (Flow) have all collectively attempted this problem and came up short. It continues for a while...
- tmpz22 3y ago> What are the downsides of gradual typing on a codebase? Typing complex business domains and interactions is hard. Most developers don’t have a lot of experience with it or the time to do it properly as they produce features. It doesn’t help that many developers start their career with untyped languages and transition into typed languages without learning it properly. Typescript is a great example because a lot of frontend developers may have only ever worked in JavaScript and have absolutely no foundation to build on but trial and error on your companies production codebase.
- jvanderbot 3y agoThe days of sweeping declarations regarding obviously periodic trends have never arrived. I've been around long enough that "safe" gave way to "productivity" and back to "safe". There's kind of a nascent ethos of being "better" in each new generation that just results in these pendulum effects. The overall effect seems to be enormously positive. I can now bounce between several completely valid build environments, ecosystems, and languages for a given project depending on what is required. But make no mistake. Our kids will probably look at us like we're crazy as they embrace the 2040 equivalent of JavaScript and Python again.
- JohnFen 3y agoYep. Everything comes in cycles, old becomes new again, etc. This is particularly true in the software industry. We're very fad-driven.
- skitter 3y agoIs this the case here too though? My impression was that dynamic languages grew popular because of deficiencies in static type systems, making it hard to express things while requiring a lot of boilerplate and not providing enough runtime safety (e.g. NullPointerException), and a faster feedback cycle, as you need a compile step and need the entire program to be free of type errors. For the first point, type systems have been improving in these regards, and for the second you get instant feedback in statically typed languages without needing to even run anything. Some languages like Roc even let you run code while there are type errors in other code paths.
- JohnFen 3y ago> Is this the case here too though? I have no working crystal ball, so I don't know. But I don't see any obvious reason to think it isn't. If history is any guide, then this is just the latest cycle, and the new hotness will become dynamic again. Your list of improvements is correct, but I'll just point out that with every cycle, a similar list of improvements is cited as the reason why whatever the fashion of the day is will become The One True Way. So far, such expectations have never been fulfilled.
- sublinear 3y agoTypescript propaganda. Instead of worrying about types, why not worry about the actual code quality? Half of all typescript I've seen uses "any", not to mention the fact that it obsfuscates what's actually running in the browser and forces an unnecessary build step for things that aren't "web apps".
- hot_gril 3y agoWell MS does own Github now, so I'd expect Github to say this.
- Tozen 3y agoWe can expect no less than for MS to use GitHub for self serving purposes.
- deleted 3y ago[deleted]
- Cyberdog 3y ago> Instead of worrying about types, why not worry about the actual code quality? I'd argue that a sign of good code quality is using types even in languages and contexts where you don't have to. PHP is technically still a duck-typed language, but the community has embraced its relatively new strict typing features with open arms and the PHP ecosystem is all the much better for it.
- IshKebab 3y agoThe whole point of static types (well one big reason at least) is to improve the actual code quality. I don't understand how you think it obfuscates what is actually running in the browser. Nearly all non-trivial web projects have a build step even if they aren't "web apps". But I agree it would be nice to at least have the option to avoid it. There is a JavaScript proposal going through that should fix that.
- tacotacotaco 3y ago> The whole point of static types (well one big reason at least) is to improve the actual code quality. I have worked on multiple typescript projects that had terrible code quality. Types do not make you write SOLID code. I find functional programming and well-used functional patterns do result in higher quality code. Typescript’s type system makes writing functional code more difficult. The documentation even recommends against it[1]. IMO typescript is easy to prescribe as a panacea, “just use typescript”, whereas understanding how to write SOLID code takes time. [1] https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes-func.html#point-free-programming https://www.typescriptlang.org/docs/handbook/typescript-in-5...
- fnord77 3y agoGradual typing is not the best of both worlds. On a large project, a lot of discipline is needed to make sure typing gets used everywhere. Even worse, when you have a prototype that morphs into a large enterprise application, someone needs to go back and fill in all the types. This can be a struggle if everyone is gone. basically this just kicks technical debt down the road.
- 38 3y agothis would be nice, but no, not going to happen. JavaScript, Python, PHP, Ruby etc fill a niche. Personally I love strongly typed languages, but I get why people don't want to deal with it. I am old school and do not use an IDE, so for me strong typing is a must.
- kayodelycaon 3y agoHonest questions: What do you consider an IDE? Do you use syntax highlighting? I only ask because I use Sublime Text but the most I use is the file browser sidebar and syntax highlighting. I don't use any linters. I started with Ruby on Rails and Textmate and I've never needed anything fancy, even for 500k line Rails apps.
- 38 3y ago> Honest questions: What do you consider an IDE? Do you use syntax highlighting? I use GVIM, no plugins. syntax highlighting is fine and file browser too, but once you start getting into autocomplete and plugins that too much I think. the IDE should not be a replacement for a poorly designed language, and that's what they have become I think.
- deleted 3y ago[deleted]
- JohnFen 3y ago> I am old school and do not use an IDE, so for me strong typing is a must. I, too, prefer to avoid using an IDE. I appreciate strong typing, but I certainly don't feel that loosely or untyped languages are made more difficult to use by not using an IDE.
- 38 3y agoI use GVIM without plugins. So if I want to code some Python or JavaScript, I am looking at this: function hello(a, b) { return a + b; } what the hell are "a" and "b"? numbers? strings? something else? no thank you.
- mattmcknight 3y agoMeanwhile untyped languages keep expanding the boundaries of what is considered a trivial project.
- deterministic 3y agoNot my experience. Do you have any examples?
- mattmcknight 3y agoRuby on Rails? I've built apps that have been running for years in a couple of weeks. If you have a very logical structure, the types take care of themselves.
- mepian 3y agoLet me get this straight: Microsoft is taking credit for the feature Common Lisp had since the early 1980s? https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node103.html https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node103.html I suspect that even Common Lisp wasn't the first industrial language to implement gradual typing, but I can't remember any earlier ones.
- chunkyguy 3y agoCan we just agree that there can never be one solution that fits all problem spaces. I use both C++ and ruby for different jobs and I like/hate both equally.
- JohnFen 3y agoThis is a soapbox I've been on for decades. There's a reason why I have bothered to become competent in a large number of languages: each has their own strengths and weaknesses, and so there is no single language that is best for every sort of program and environment.
- globalreset 3y agoPeople use Rust for everything and love it. :D
- mkl95 3y agoThere are tons of non-trivial Python and Ruby projects out there, to name a few examples.
- deleted 3y ago[deleted]
- MrResearcher 3y agoI came to typescript after many years of C++. I found typescript to be a much better language than C++ overall, and I'm far much more productive with typescript. I'm glad that a lot of people can manage without the types, and I've seen many successful big projects plowing along just nicely. I personally wouldn't be able to maintain a large project without types. It seems that a lot of people figured out for themselves how to do it. If you are one of them, how do you refactor the codebase? Are you relying solely on unit tests to avoid breaking all involved pieces? In Typescript I usually just go ahead and change the structure or method parameters in type-incompatible way. In many cases it's sufficient to fix all places to maintain the project in an unbroken state. I'm looking forward to the launch of Zig, that should be a good choice for WASM. Only if I could get a pytorch-like interface in Zig now...
- anon7331 3y agoPerhaps the name "Typescript" is misleading. They should have called it JavaScript++
- jrochkind1 3y agoRuby sorbet has generally been having slow adoption. Does anyone know how much github is using it internally on their (we know substantial) ruby codebase?
- Animats 3y agoProgramming seems to be settling down in this area. Parameters to functions and fields in data structures are usually explicitly typed, while local variable types are inferred when possible. C++, Go, and Rust have all converged on this. C++ used to suffer from "for" loops with insanely long type declarations for iterator variables. "auto" fixed that. Inter-function type inference, while technically possible, is just too confusing for people reading the code. So that went away. Mostly, type inference is now forward only. Inverse type inference through long chains is, again, possible but too confusing. Explicit typing of structure fields and function parameters allows automatic generation of reasonably useful documentation. That gives programmers anchor points at which they can see types. So this has become a solved problem for compiled languages.
- deleted 3y ago[deleted]
- synergy20 3y agojust make javascript support static typing, e.g. let x:number=100 etc, similar to what python does, without a totally new tsc compiler, an eslint for typescript, and all those c# stuff along with it. can we just improve js instead of using ts?
- fenomas 3y agoHuh. I've been doing JSDoc typing, described halfway into TFA, for 2-3 years now but I didn't know it had a name or was considered a thing. Generally I've been really happy with it - no transpilation step to think about, and I get almost all the type hints and errors/warning I'd get from writing TS. And for very little verbosity - I probably only have 2-3 JSDoc comments (that declare types) in each typical .js file. The main drawback I've fought with is that when you're doing something complicated - e.g. extending or decorating a module imported from elsewhere - it can be hairy to convince the editor to infer what's happening. The other one is I've never found a good way to author an event emitter, such that you get inference and type checks on code subscribing to the events. But there could be solutions to both points that I've been missing.
- mitchitized 3y agoDisappointed to find a puff-piece on typescript. Dishonest headline. Javascript frustrates me just as much as the grumpy old man in the article. That said, I once sat down and asked myself, "self, why was it okay to live through the php years yet you despise javascript for being the same way?" And then it dawned on me, my involvement in php projects forced me to have a low-level understanding of the language that I never acquired with javascript. The consequence for me is that javascript is still full of voodoo and dark magic, all very frustrating and bowel irritating. But that's not the fault of the language, that's the fault of the knucklehead trying to use it without really digging into the internals and understanding how it should be used. That would be me. Not learning how javascript internals work and complaining about javascript is no different than when Mongo first came out, and folks shoved third normal form schemas in there and complained loudly that Mongo was a lousy RDBMS. It's not an RDBMS, mate. If anything this article instead implies that typescript means you don't have to bother learning javascript internals. Do not recommend.
- stathibus 3y agoMuch simpler explanation - php and js are both terrible languages.
- archarios 3y agoJS core (that's worth knowing) is pretty simple. My mental model is basically there are primitive types, arrays [], objects {}, and Promises. After that, you basically just have to understand the event loop and you're good to go. Then there's other special things like async/await, spread operator, etc. Among programming languages, it doesn't have THAT many things to learn at its core.
- midjji 3y agoArguably C is losely typed rather than strictly typed. int for example is some integer type, dont worry about which one, and people keep reinventing this too. Sometimes you want stricter, sometimes more loose, but most languages have a sweetspot where they provide a decent syntax and anything outside it is crap. The language which solves this will allow people to select the level of type abstraction on a per task basis, while retaining full performance. It will be nice when we get this, but no language is even close.
- cwillu 3y agoThe correct title is “TypeScript and the dawn of gradual types” HN Guidelines: “If the title includes the name of the site, please take it out, because the site name will be displayed after the link. If the title contains a gratuitous number or number + adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids." Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.”
- benji-york 3y ago<rant flavor="man-yelling-at-clouds">None of the mentioned languages are untyped.</rant>
- beders 3y agoI'd interpret this as: the days of using bad tools that don't understand your code is over. What is not over is the complexity people inflict on themselves trying to model a non-trivial, changing data model with concrete types.
- rickreynoldssf 3y agoI've been developing all kinds of applications with JavaScript. Some have handled multi-millions of users per day, thousands per second. I started with Netscape 3.0. In all that time there's only been a handful of times that I wish JavaScript was typed and maybe two handfuls of times when the lack of types caused a problem for me or my team.
- danwee 3y agoAgree with the sentiment (statically-typed languages are cool), but TS is not ideal. Is the best we have if you want something JS-like, but try to explain the following monstrosity to a junior colleague who's starting with TS in the context of web applications (using one of the most popular frameworks out there, NestJS): // a DTO that handles the creation of some kind of resource ... @IsArray() @ArrayMinSize(1) @IsString({ each: true }) @ApiProperty({ example: ['software', 'maths'], }) tags: string[] That's real code. Since the TS types gets erased when the code is transpiled to JS, one has to annotate the whole thing just to be sure the clients are not sending us invalid data. And the validation via annotations couldn't be more cumbersome. 90% of the code in the DTO file is annotations. Reminds me Java from 10 years ago.
- nabogh 3y agoIs that typescript's fault though? Seems like a nestjs thing
- deleted 3y ago[deleted]
- hot_gril 3y agoIf you want safety, write tests. Any time spent futzing with types is less time writing tests.
- deleted 3y ago[deleted]
- nathants 3y agostrong typing is great and there are more good choices now than ever. however it does nothing to address main issue plaguing software since the dawn of time: apathetic and/or adversarial engineers. the problem has always been people and the ways of organizing and incentivizing them to build large complex works. pl choice hasn’t ever mattered much, still doesn’t, and likely never will.
- sanitycheck 3y ago"Gradual typing" works as a sales pitch, but having had a go at that it, it's at best a way of getting the editor to give better autocompletion. It's only with strict mode on that I feel Typescript is really worth it. The article also touches on Typescript-in-JSDoc, but that can get really ugly with complex types and there are a few things I just couldn't figure out how to do when I gave it a proper shot last year.
- mikewarot 3y agoThe biggest problem with most typed languages is string handling, especially null terminated strings. Returning a string from a function is a nightmare in almost every typed language, except Delphi/Free Pascal, which does auto-reference counting, and manages it all, you never have to allocate/free memory for them, and they can hold gigabytes. Typed languages offer some efficiencies, and can, if properly used, help prevent entire classes of footguns, but they do require a bit of planning. I've always wished I could do the same "gradual type" thing with Pascal, Basic, etc. As the program is run, the types are checked, and slowly baked in automatically.
- bheadmaster 3y ago> Returning a string from a function is a nightmare in almost every typed language, except Delphi/Free Pascal, which does auto-reference counting, and manages it all, you never have to allocate/free memory for them, and they can hold gigabytes. Why mention memory allocation at all? There are plenty of typed languages that have automatic garbage collection and handle strings just fine. Go (Golang) comes to mind as a superb example of a typed language in which string handling is a breeze.
- viraptor 3y agoI'm so confused. What do you think happens differently in C#/python/Ruby/rust/whatever when you add one string to another? Or when you read into a buffer without a predefined size? Or assign one string reference to two variables?
- missingdays 3y agoThe biggest problem with a couple of typed languages is string handling. The rest are doing just fine in this regard
- ilaksh 3y agoStatic typing can have advantages but that doesn't mean it's completely invalid to use a dynamic or untyped language. It's understandable if some people prefer not to be involved in those projects though. But it's completely feasible to use dynamic languages for non-trivial applications. I think it's fair to say that Hacker News is not a trivial application and it's written in a Lisp dialect called Arc. The biggest advantage of dynamic languages is probably that they are usually more concise. Which can lend itself to a more elegant expression of intent. Another advantage might be more flexibility reducing the tendency to add boilerplate or a lot of schema-specific code. And I am aware that many people consider a lack of schemas to be the worst thing ever. But at least they are flexible. And yes I am aware that static types can eliminate errors at compile time. Those types of advantages don't completely invalidate the use of untyped languages.
- wellanyway 3y agoOh my god javascript people are at it again.
- kwertyoowiyop 3y agoRegarding software development in the 50s through the 90s: > velocity wasn’t a top concern, safety was Not true. Velocity was as much of a top concern back then as it is today.
- G3rn0ti 3y agoBiggest reason for the success of TypeScript is it aids IDEs in statically analyzing your code and providing enhanced autocompletion results like e.g. methods and properties. In dynamically typed languages this a much more difficult task and can only be approximated by applying some heuristics without actually executing your code. This is definitely an advantage! No dispute here. But whether static types make programs safer and their architecture cleaner is something in need to be proven empirically. And as others already wrote: There is a reason why dynamic scripting languages became popular.
- EPWN3D 3y agoI guess no one told Python?
- HocusLocus 3y ago"I would like to reassure... any nervous listeners... the experimental days of broadcasting, as such, are over." https://www.youtube.com/watch?v=bDp2HnL8O6Q&t=217s https://www.youtube.com/watch?v=bDp2HnL8O6Q&t=217s
- khalidx 3y agoOne useful thing I’ve found with typed languages is that I end up implementing the entire specification for a program in the type system even before writing a single line of actual working code. Makes it easy to fix and refactor things early on and improve things from a developer experience and interface perspective. I push implementing a function as far out as possible, when the entire structure of the program becomes clear. This hack easily makes me 10x more productive. Plus I don’t share the same annoyances with types and TypeScript for example that other devs face. Once it’s set up (just adding a tsconfig file and a package file) the type system just sort of disappears — I mean, I rarely fight with it. I do agree though that most of the complaints with these systems, languages, and tools really come from the vast amount of competing “getting started” and build guides that always seem to get out of date or use some radical new way of doing things that upsets the whole ecosystem. There have been so many changes in this regard. That, I will say, I don’t have an answer for.