If you want runtime assertions with flow you can use flow-runtime [0].
Babylon merged TypeScript support yesterday [1]. This means that in the future it should be easier to setup Babel with TypeScript.
I agree with the decision to go with TypeScript. It has drastically better community support. Most third-party components won't have flow annotations. Flow would've been a lot more successful from the start if it had started out with DefinitelyTyped support. Heck, even now I'm still wondering why they don't do that.
Yep, if anyone can/wants to help out with this effort I would follow/review the issues/PRs in our typescript label https://github.com/babel/babel/pulls?q=is%3Apr+is%3Aopen+lab... (I help with Babel). We'll be working with the TS team to definetely get some better docs on how to setup both Babel and TS once we land the changes in Babel and release 7.0
I was wondering does this make it possible to use proposals which have support in babel but not yet in typescript (e.g. do expression) when writing typescript?
At this point, it make senses for someone to write a TypeScript definition to Flow definition converter. Given how similar the languages are, I feel like you might even get away with using hacky Regex-based transformation instead of using ASTs for a lot of libraries.
I never did understand why Facebook and Microsoft ended up competing on this front.
> I never did understand why Facebook and Microsoft ended up competing on this front.
They ended up competing, but they did not start competing. The projects were started in isolation from each other. The fact that they are written in different languages (Flow: OCaml, TS: TS) makes it hard to merge efforts.
Between Flow and Typescript, looks like the latter has all the momentum. But I see one way in which Flow could become relevant again: by becoming 100% compatible with plain JS.
I would love to have type checking, but I'm weary of solutions that aren't really JS, and could fall out of favor or lack good support in the future. I'm pretty sure I'm not the only one.
But Flow type annotations don't really need an incompatible syntax AFAIK; they could just use comments. This way, we wouldn't need to worry about the future of Flow. If the projects dies off or becomes redundant, we're just left with some useful comments - no need to rewrite or transpile our code to native JS.
PS I found an existing project which does this [1], but it requires an additional step and it isn't officially supported. It looks incredibly easy to make Flow work directly with pure JS with comments...
Thanks, but from a bit of research it's not clear to me: does this mean that it's possible to use TypeScript to type-check javascript files which include these annotations, without using .ts at all?
You can use Babel with TS. For example, for JSX you can tell TS to "preserve" the JSX, which means you can tell babel or some other compiler take care of that transformation[1]. You can also use babel with typescript to use the babel presets for stage-[0-4] plugins. You can use the webpack TS loader, awesome-typescript-loader, to work with babel[2].
One case I ran into: using css-loader/style-loader for my css. TS doesn't understand importing css files, so that's where Babel comes in.
In the end i decided to stick to 'old-fashioned' SCSS with an npm script; the downsides of adding Babel to my stack weren't worth the upsides of css modules. Difficult decision to make though.
I guess what I'm saying is that while there is a use case, so far it's been worth it to just stick to TS without Babel, much as I wish it'd be different.
No more experience than reading the docs and watching an old talk from Andrey Breslav [1] where he explains how a DSL for HTML generation could work in Kotlin.
I like what I see and look forward to experimenting with it once I have more free-time (currently in grad-school taking summer courses). Kotlin as a language is really compelling, so I've tried to at least stay informed about it.
> Using a typed language in our frontend has already paid dividends: our code has fewer type-related bugs, we are more confident making large refactors, and our inline documentation is focused around concepts instead of object shapes and function parameters.
Sounds like they learned from their mistake of using Python on the server-side. Dynamically typed languages for large code bases are terrible.
> their mistake of using python on the server side
I could not disagree with this sentiment more. As always, reality is more nuanced than this.
There seems to be a common theme of startups succeeding with dynamically typed languages, and adding static typing later. However calling the original decision a "mistake" is neither fair nor accurate.
After all, you don't buy a big mansion out of college because you are going to have a family one day. What is right for you today might not be right for you today.
Companies change as they grow, and switching from move-fast-and-break-things to slow and steady mode is just one of those things alongside all others.
Dynamic languages were great at bringing these companies where they are now: it allowed them to be agile and fast to market with a small team.
Are they going to benefit from switching? Yes, absolutely. But was the original decision a mistake just because the priorities and cost/benefit curves have changed now? I really doubt it.
Having used many languages over the years, the biggest advantage I've seen to dynamically typed languages is that they're easier to learn.
Python and JavaScript are probably the most common "first languages" taught in school. The dynamic typing and lack of complex IDE, compilation, and build system make then easier to learn. Most founders only have a few years of programming experience. Most startups can't afford to hire anyone experienced. Given these constraints, using these languages makes sense.
Dynamic language aren't any faster in practice. You can write quick and dirty spaghetti code in anything. It's only the naive that consider building large, or potentially large, projects in languages without static typing and strong IDE support.
In time I've realized that dynamic typing doesn't give any real advantages. It allows you to reuse variables, something that should never be done. It allows you to put different objects in the same array without having anything in common, which also seems like a bad idea. What else do you get? The language still has types they're just not visible when your writing code. I would much rather have compile-time types so I can use auto complete
Having used many languages over the years, the biggest advantage I've seen to dynamically typed languages is that they're easier to learn.
I love Ruby because of its delightful standard library, its thoughtful syntax which makes manual refactorings easy, not because or in spite of its dynamic types.
I detest Java because of its verbose syntax, its love affair with XML, and because it isn't a good unix citizen. Not because of or in spite of its static type system.
I detest Javascript because of its non-existent standard library, its many, many design errors (slowly being fixed, I know). Not because of its particular type system.
All other things being equal, I would prefer my language of choice to have statically checked, expressive type system. Unfortunately, all other things have not been close to equal historically. Things are improving, and maybe these days it's possible to have your cake and eat it too.
In practice the Python language is so easy that you rarely have bugs related to types. And when you got it, you find it out pretty early.
Types are useful when you grow, but thinking that you can't do anything big and robust without it is ignoring all the people that actually do so.
Another thing is that the simplicity and power of Python leads to having a lot of libs that are actually clean and solid for a lot of stuff. If I need to create anything under 100000 vis/day, I'm 3 times faster than a Go or Java dev on the backend. Literally 3 times.
I also produce better results. With things like Django rest framework, I can get the same REST API, but all the edge cases will be way better handled, small error messages, multi type of auth, etc.
Those things exist because it's fast to code in Python. And yes, dynamic typing help with that a lot.
So yes, it's true I don't have as much code completion and I have to remember a bit more about the code, but it's an exchange I'm making.
When I want to scale up robustness, I use type hints with mypy and get a strong code completion on PyCharm.
3 times faster with zero proof? Java has similar REST frameworks, notably Jersey and Spring Boot. There's also the Play/Dropwizard crowd and Vert.x . Look at spring boot code vs flask, it's almost identical.
Java libraries, particularly those maintained by Google and other tech giants are some of the most solid code ever written. I doubt Python or any other language comes close to the quality of popular Java libraries.
I still don't see how dynamic typing helps with speed? Any Decent IDE will fill in the types for you so you don't even need to key then mostly
Actually develop in spring boot vs flask, and you'll see just how much faster it is to code in flask. Spring Boot has many peculiarities and boiler plate you have to deal with. Flask just works.
>I doubt Python or any other language comes close to the quality of popular Java libraries.
You complain about proof and then you throw out this line.
Couldn't have written this any better. Also add the need to write shed loads of "test code" in order to reduce the probability of runtime fatal errors that would have been caught by a compiler; and the fact that source code becomes very hard to understand and maintain due to lack of semantic clues from things like types and structure definitions.
Also add the need to write shed loads of "test code" in order to reduce the probability of runtime fatal errors that would have been caught by a compiler
People always say this, and I've never understood it. Can somebody provide an example of a test that you "have" to write in a dynamically typed language that you wouldn't with static typing? If you're referencing nonexistent properties, then any test that hits that line will fail, and such a test should exist regardless of whether you're using static types.
No, that's exactly the point: with a statically-typed language, you wouldn't need a test for a non-existent property reference. The compiler will choke on the bad reference, and any test that uses/references the module in which the code resides will fail to compile. In other words, just simply trying to compile the complete codebase serves as a baseline "type/sanity test". The compiler will simply not allow you to produce an application containing such code.
>There seems to be a common theme of startups succeeding with dynamically typed languages, and adding static typing later. However calling the original decision a "mistake" is neither fair nor accurate.
People forget how old reddit is. Most good options in this space for statically compiled languages did not exist back then, so there wasn't really a decision to make. It even predates rails.
It's hard to "prove" anything in discussions like this. Having been thrown in a few million loc projects, all written rather badly, I found it way easier to figure out what was going on in the ones with static types. At the very least, if you're inheriting an unknown codebase static types are in my experience a 10x speedup when measuring time to actually getting productive.
Dynamic language does not make you more agile, it makes changes more risky and refactoring harder.
However, large part is that for frontend, static languages are just getting there. You need not just language, but also libraries, tutorials, tooling, IDE and so on and so forth.
Typescript nor flow does not absolve you from the need to learn javascript and web in general. If you are working on your first bigger project and still learning good techniques, architecture and concepts, css, having to also learn typescript or flow syntax on top of it off-puts people.
This is partly why I'm so curious about languages like Racket, that let you start with easy, freewheeling dynamic typing, and then move, in parts, to Typed Racket. We just need to convince some big software engineering project to start down that road, so we can collect the data about the approach :-p
TypeScript is not your run of the mill static language.
TypeScript was the first time I ever used a static language without feeling like it was getting in the way or I was losing the power of a dynamic language. So no, they didn't learn their mistake from using Python, they were just coaxed into using an incredible language since, barring masochism, you must compile from something into JavaScript nowadays, and TypeScript is an absolute pleasure.
- Type inference for the laziest. Hands down better than Scala, Swift, or Rust. The only language I've ever used that can infer recursive functions:
function factorial(n: number) {
if (n == 0 || n == 1) return 1;
else n * factorial(n - 1)
}
- You can define mix-typed maps without a sweat:
const defaults = { debug: false, title: 'Banana', width: 100 }
- And as a bonus you can suck the type out for later use:
type Settings = typeof defaults
- You can mix types without the compiler demanding umpteen incantations.
- Gloriously simple union types.
- Regex types are coming! (e.g. all strings that look like a URL)
- You can type the API of some hidden dynamically-typed insanity if needed.
- You get a REPL for free, and it's pretty easy to debug production code if you haven't mangled all your names.
- Haven't figured how to type something? Want to prototype something quickly? No worries! Your code will still compile.
Elsewhere one would have to define a struct/class and them create an instance.
This becomes immensely helpful for the incredibly lazy with one off object definitions and wrapper types. If you introduce a class definition alongside an instance, you're now forced to manage two peices of code. The class definition and instance definition. In this case they're coupled which aides maintenance in my experience.
Specifically structural record types, and many statically typed languages don't have them. (not Java, not C++, not Haskell, not Rust, yes Swift, yes OCaml)
Any of the mainstream functional languages (which are most likely to have type inference) can infer the types of all functions, unless you use funky language extensions that make type inference undecidable. Rust has a Hindley-Milner system, so it should be able to "infer recursive functions" too (but I can't say for sure since I don't use it).
I'm pretty sure that's just "administrative" and imposed by the syntax (e.g. think Java/C++ function declaration syntax), instead of being something the compiler can't infer. Thanks for clearing this up, though.
Correction: might be coming.* It's a GitHub issue that's received a lot of attention. Apologies, my memory gets optimistically fuzzy when I swoon over a language. ;)
Prove how? They could have succeeded in spite of dynamic typing, not because of it. Facebook defined a new programming language to add static typing to HHVM. The process of plugging into WordPress is infamous in its disorganization.
There’s a lack of good statically-typed languages, so it’s natural for many popular things to be built in dynamically-typed ones, but that doesn’t make the dynamic typing approach better.
But you're right. Moreover I noticed obsession with a particular language is often a hallmark of a junior engineer or a recent grad. This this idea of "If you don't use Go/Node.js/etc you'll totally fail".
They could have succeeded in spite of
dynamic typing, not because of it.
You think the otherwise smart and successfull founders of these projects all made the wrong choice when it came to selecting the right tool for the job?
Facebook defined a new programming language
No, they wrote a faster runtime.
to add static typing to HHVM
No, they added type annotations.
There’s a lack of good statically-typed languages
No, in the past statically typed languages were the norm. C, C++, Java...
It's just that dynamic languages outcompeted them.
> It's just that dynamic languages outcompeted them.
All "trending" languages are statically typed (Rust, Go, Swift, Kotlin, ...) and all the popular JavaScrip-improved-languages are statically typed as well. Even further, many dynamically typed languages have pushed in recent years to add type annotations or even static typing (e.g. mypy).
Dynamic typing is the brainchild of the 90s for rapid initial development. Sustainability has been a big issue from the outset.
The 90's also saw much commercial experimentation with visual environments (e.g. Visual Basic, Delphi, JBuilder) with round-trip conversion between the layout form and underlying code. They were promoted for R.A.D. (rapid application development -- remember that acronym?) but, like dynamically typed languages, they also had sustainability issues.
Of course, like dynamic typing and Lisp, visual environments also had Smalltalk from way back, but they were before big business became infatuated with the ideas.
How do products like Delphi have sustainability (maintainability ?) issues ? Delphi/Object Pascal is statically-typed, so you can't even build an application that has issues with the code-behind for a form.
You can see errors at run-time from mismatches between the code-behind and the forms, but this has nothing to do with the language. It's just the way that certain products like Delphi decided to handle such mismatches. You'll see these types of issues with any code that performs run-time serialization/deserialization of class instances. Our product, Elevate Web Builder, uses a similar architecture with its WYSIWYG form designer/forms (they use JSON instead of a custom key-value format), but it simply ignores properties in forms that don't exist in the actual code.
People say this mainly because of the brace-enclosed blocks of code being functions. However, that is really just a syntactic sugar for lambda (and can even have explicit arguments: (lambda (x y) ...) <--> {|x,y| ... }.
there's the "everything is objects and messages sent to them" bit too, which is definitely from smalltalk. ruby took the good bits from several languages.
Smart answer successful founders of Wikipedia took an existing wiki engine. Their aspirations were not in the software development area.
Highly dynamic languages like Python or PHP or Perl are easy to start with, so they're great for prototypes. Then either a serious rewrite follows, using a statically checked language, or scaffolding is erected to continue to make do with the dynamic code. Microservices help!
No; but a single microservice is a smaller code base that a large monolith, so the problem . Also, you normally control the microservice's interface more strictly, and change it less often, and care about compatibility and versioning more, than for a typical internal API.
If type annotations support a static verifier, they implement static typing (which, after all, is just having a static verifier that uses some combination of annotations and inference to validate types.)
> You think the otherwise smart and successful founders of these projects all made the wrong choice when it came to selecting the right tool for the job?
Not at all! I think dynamic typing hurts code, but there are:
- not always alternatives
- many other slightly suboptimal choices that it’s quite possible to succeed in spite of
> No, they wrote a faster runtime.
I’m referring to Hack, which is in fact another language with static typing. (Type annotations are static typing with compromises, and you can see what’s being gone for.)
> No, in the past statically typed languages were the norm. C, C++, Java...
Those are not remotely good. Some examples closer to being good are Rust, a step in the right direction that’s still unfolding, and Haskell, a wonderful language hampered by a slow compiler and a lack of decent packages. (And probably several less popular languages, but popularity is an important factor…)
"Those are not remotely good. Some examples closer to being good are Rust, a step in the right direction that’s still unfolding, and Haskell, a wonderful language hampered by a slow compiler and a lack of decent packages. (And probably several less popular languages, but popularity is an important factor…)"
Wait: so you are arguing that startups should use languages that are either incomplete (Rust) or that have slow compilers and poor library support (Haskell), or possibly some other "good" language that doesn't actually even exist?
I’m saying that dynamically-typed programming languages are the best choice right now, but that it’s not because they’re dynamically-typed; existing fare for statically-typed languages is just worse.
Probably should have clarified that earlier since it looks like I agree with the statement that choosing Python was “a mistake”; sorry. I don’t. Vehemently.
>You think the otherwise smart and successfull founders of these projects all made the wrong choice when it came to selecting the right tool for the job?
Nobody is perfect. Mark Zuckerberg has had his fair share of controversies for example.
>No, in the past statically typed languages were the norm. C, C++, Java...
Not good examples for your argument. These are largely considered poorly statically typed. Compare to ML, Haskell, Ada, Rust, Swift for reference.
"They could have succeeded in spite of dynamic typing, not because of it."
Yes, they could have. Evidence for your hypothesis would be the existence of similarly successful companies that used compiled statically-typed languages from the beginning.
The same can be said about any company to justify your opinions, like Linkedin, they use Java and Scala and their page speed is so slow. Compared to Facebook they are like a 1900' tractor. A facebook page opens in less than a second, a Linkedin page in 5.
And until you have gone back and forth a couple of times, building moderately complex systems; it's difficult to appreciate the advantages that static checking bring to the table. Sure, it's possible to achieve the same effect with unit tests; but having half of those tests written and rewritten for you by the compiler definitely helps. Back in the days, I wanted to buy into the Python/Ruby hype as much as anyone; but having implemented several complex systems in Python/Ruby, I'm not that excited about the idea anymore; once they pass a certain point, agile begins to feel more like Jello.
I’m saying that the parent doesn’t prove its point, and I’m not attempting to prove its parent’s point.
> If you started your career recently, it's easy to be caught up into this "static typing" as some kind of the only way.
I didn’t, and the bulk of what I’ve built has been in languages with dynamic typing. See https://news.ycombinator.com/item?id=14675577. Dismissing stuff as “recent starts” is pretty cheap, anyway.
Most of these languages are pretty terrible to run at scale.
Also, all of the examples you cite a rather the "in spite of" kind. Wikipedia? Struggles to maintain the code base, lest to speak of significant new development. Wordpress? Afterwit of web security. Facebook? Facebook literally developed a new PHP implementation (edit: actually, two) and then turned that into a separate language (which is statically typed) because that's easier than to clean up their PHP code base. YouTube? Maybe some help pages are still on Python. The application most likely isn't at all. GitHub? Goes down every few days with 500s after buggy code was deployed.
They all started with dynamically typed languages because that was what the founders knew best when they started working on their project. Yes, you can build successful projects with dynamically typed languages but it is a pain to refactor when you grow. You even introduce a class of bugs doesn’t exist for statically typed languages. You don’t see them redo everything only because the cost would be to big. Some developed their custom tooling to handle the language they are stuck with, see Facebook.
> You even introduce a class of bugs doesn’t exist for statically typed languages.
Conversely, you're also able to write equivalent functionality with less code and with idioms you can't use in statically typed languages. It's an engineering trade off, the static typed handcuffs prevent you from making a certain kind of mistake but they also prevent you from writing certain kinds of code that are extremely powerful; many prefer the power over the handcuffs. Type bugs just aren't that painful.
I've had professional jobs writing both Python and Haskell. My Python code has to be far more verbose and complex than my Haskell, and the Python's harder to maintain too!
> Type bugs just aren't that painful.
You haven't learned the true power of a decent type system then.
While certainly Haskell lets you do more, you can get some interesting help from even the C type system. For instance, I was able to enforce "this can only be called from the main thread" with no runtime overhead.
You explained this once to me before and it was very cool. Did you ever write a blog post about it? I think it would be neat to link to in the future when these sort of discussions come up.
> You haven't learned the true power of a decent type system then.
Conversely you haven't learned the true power of dynamic types or like coding with handcuffs to keep you safe. What static types offer me is not as useful to me as what they forbid me from doing, so no it isn't an issue what what I don't know, but rather of what I do. And Haskell, no thanks, I'm not a masochist.
> and the Python's harder to maintain too!
That's an issue with Python, not with dynamic types. My Smalltalk code is a joy to maintain.
And what exactly do static types forbid you from doing? (For the sake of argument let's consider state of the art static type systems such as those found in Haskell, OCaml, Elm and Purescript)
State of the art is hardly relevant, what's relevant are languages in demand by employees that dynamic language are actually in competition with so no I don't accept that restriction for the sake of the argument as it's moving the goalpost. However plenty of meta-programming techniques including the use of dynamically interpreting message sends to methods that don't exist in the context of the receiver, i.e. Smalltalk's doesNotUnderstand or Ruby's method missing are but one example.
Look, I get it, you like static typing, how about accepting that we all don't; we value different things from a language, and extreme late binding in all things is something we value more than being protected from ourselves with a type system. Don't assert to others what they have or haven't learned just because their preferences differ from yours.
I think you're responding to an argument I didn't make.
You claimed "Type bugs just aren't that painful". Haskell allows you to make all sorts of bugs into type bugs, from SQL well-formedness, through certain concurrency guarantees, to guarantees that your HTTP routing is correct. So yes, type bugs can be very painful, and that's a good thing!
Using Haskell is more painful than any type bugs it might help fix, no thanks. One can write correct code without a type system to guarantee it for them, we're fine doing this rather than dealing with said pain in the ass type system. Haskell is not my idea of a good programming language, it's not what I want from a programming language, it's not conducive to how I want to program. It's an esoteric language for a reason, few people like it and it'll likely remain that way.
OK, if that's your opinion then fine. I just wanted to challenge your claim "type bugs just aren't that painful". On the contrary, they can be and should be!
You can't challenge a claim about how I feel about something, if I say something doesn't hurt, nothing you can say will convince me it does. Pain is subjective, keep that in mind when trying to tell others how they feel about something.
> you're also able to write equivalent functionality with less code
The amount of code one writes says more about the language than whether or not it's statically typed.
To me, adding "bigint" or "bool" to the occasional variable and function declaration isn't "more code", it's an extremely terse way of avoiding different code (e.g. type assertions).
That's not what I mean by more code, by taking advantage of dynamic typing you can write more generic code than is even possible with generics in a statically typed language; code that works for any type, whereas a static language either forbids you or forces you to write multiple versions of the function. You can't write a single Max function in C# that works for any type supporting >=, it simply can't be done. This is typical of static languages, they forbid perfectly good code because it "might" be used inappropriately or because the type system can't guarantee it won't.
> by taking advantage of dynamic typing you can write more generic code than is even possible with generics in a statically typed language; code that works for any type, whereas a static language either forbids you or forces you to write multiple versions of the function.
If you can write code that works for some combination of types, it's because those types present a common interface that could be specified in a sufficiently-expressive static type system, either via something like OOP interfaces or something like Haskell typeclasses.
> You can't write a single Max function in C# that works for any type supporting >=, it simply can't be done.
You can, in fact, do so for any type supporting the IComparable<T> interface. That the operators are defined independently is a C# type-system quirk, not a fundamental limitation of static type systems.
> that could be specified in a sufficiently-expressive static type system
Ah the mythical sufficiently-expressive static type system, I'm concerned with type systems that are in use in real jobs, not vaporware ones that could exist if only. Dynamic language support it now.
> You can, in fact, do so for any type supporting the IComparable<T> interface.
Which requires forethought on the designers of said library, I'd rather have duck typing which works without requiring correct future planning with interfaces.
Nothing is stopping languages from allowing both. For example, it could have some form of compound type declaration.
Meanwhile, how often is code made worse because you have to write multiple Max implementations? And I doubt that there's many instances where such repetition is necessary, or can't be mitigated with wrapper functions.
> Nothing is stopping languages from allowing both
Nothing stops pigs from flying either... hypothetically, but they don't, and languages don't, so debating what they could do is rather pointless, they don't.
> how often is code made worse because you have to write multiple Max implementations
Similar situations occur quite often.
> I doubt that there's many instances where such repetition is necessary, or can't be mitigated with wrapper functions.
That they have to be mitigated is the point, I don't have to do stuff like this at all in a dynamic language, things just work.
Congratulations, you have worked out that there are no perfect languages. I don't understand what point you're trying to make, other than you prefer one set of trade-offs to another.
The biggest advantage of dynamically typed languages is the ease of using deeply nested data structures with mixed data types. This is just a pain in languages like Java and Scala where the Any type is often reverted to.
Type systems can enforce so much more, depending on the language. They make reasoning about the code far easier for both human and machine. They enable efficient optimization. They allow far superior static analysis. They allow superior IDE assistance. They improve code navigability (ag/grep). There are countless advantages to static typing, and most of the disadvantages simply don't exist in modern languages any more. Meanwhile, dynamic languages haven't evolved significantly, except to add type annotations, which are like types, just almost always less powerful and not enforced by default.
Dynamic languages excel at fast initial development and "gimmicky" code (wildfire monkey patching, introspection, dynamic code generation etc.), and to get there you pay dearly. Practically all other properties suffer; stability, maintainability, performance, memory usage, ease of deployment, distribution and so on and so forth.
That doesn't mean that dynamic languages have no place, or applications developed using them are somehow generally inferior to those written in statically typed languages; choice of language is only one mosaic stone of many. But it is also a foundation stone, and dictates many constraints, both technical, and social.
Since most of the stuff I work on are prototypes that might never see the light of day, I love dynamic languages like JS. I always find it confusing why more implicit casts aren't allowed when I have to use things like Python or C#.
If print() in Python includes a string and an int, I think the interpreter should be able to implicitly cast my int to string in order to make it all work. As it stands, I have to go back in and cast it myself, which kills productivity.
Any idea as to why implicit casts aren't more supported in strictly typed languages?
I'd prefer a warning on runtime than having to go back to the code.
> Any idea as to why implicit casts aren't more supported in strictly typed languages?
That's the difference between weakly and strongly typed. If you take a strongly typed language, and add implicit casting, you get a weakly typed language.
How this is resolved (or if at all) depends a lot on the language. For example, in C++ it is straightforward to define implicit conversions (which can become confusing). In Python on the other hand, it is generally up to the receiver to call some kind of conversion function, like str(), which will use an object protocol (like __str__) on the instance. This is what print("foo", 1) does, or "foo %s" % 1.
> You even introduce a class of bugs doesn’t exist for statically typed languages.
As type systems vary, almost every statically-typed language allows some errors of the class statically-typed languages, in general, can prevent, so this is not really true.
What is true is that on the continuum from no static validation to something like Idris or Agda, you accept more statically-avoidable type errors the closer you are to the former rather than the latter.
I bet a lot of their business logic is written in Java or C++. As far as I know Facebook has a lot of C++ and Youtube's video handling is probably also not written in Javascript.
I am a HUGE coffeescript fan. What I liked about flow was seemingly unobtrusive typing/type hinting. I am not a fan of type-strict languages because I spend more time thinking about types and contracts around them than milestones/design goals.
Anyway, to each their own. I want "Unobtrusive Typing" to be a thing.
Plain Javascript is valid typescript. You can add types where you need them, via type declarations or jsdoc comments. Typescript is easy to use in a partial way, the type system only gets complicated if you turn on all the strictness settings and have to explicitly annotate every type, even in dynamic code.
Eevee's Law: Facebook and Wikipedia could have been written in Brainfuck, as long as they can find enough smart people to mangle it. The fact that a major site is written in a language doesn't say anything about the quality of the language.
GitHub is _mostly_ Ruby -- there's Go, Python, C, and I think some Haskell in production on the website (there used to be some Erlang in there too, but iirc that's gone now). The Visual Studio and Unity extensions are written in C#. The new GitHub Desktop is written entirely in Typescript.
Facebook still uses PHP for a lot of templating/page generation, they use a bunch of stuff on the back not least HHVM which was great because it forced/focused the PHP team in a bunch of areas, php7 is a huge I improvement over 5 on just about every metric.
It's not amazing as a language still but it's much much better and the ecosystem has really improved, modern PHP leveraging good composer components is pretty good.
Even some good static analysis tooling these days.
I never understood why people fetishize writing monolithic applications myself. In practice, any large application can be broken down into isolated components that you can reason about independently. It seems like people often use a static typing as a crutch instead of spending the time to design their applications properly, and break them up into small reusable components that are easy to maintain.
My team has been working with Clojure for the past 6 years, and we've built and maintain a number of large applications. Dynamic typing is absolutely not a problem for us.
I find that immutability plays a far bigger role when it comes to maintaining large applications. When you work with immutable data, it becomes possible to safely reason about parts of the application in isolation. This is a key factor in making large apps maintainable.
This is only possible if you can precisely draw business domain boundaries. Micro-services add large operational overhead. If you slice you application in wrong way you will suffer...
IMO it is better to start from monolith and then extract services.
There aren't any micro-services in our applications. However, drawing business boundaries is much easier to do in Clojure than most languages I've used.
You have a common set of data structures that all functions operate on. To create a piece of domain logic, I simply need to create a namespace, and put the related functions there.
This style of code is highly composable. Since majority of functions are doing generic transformations, the domain specific logic is expressed by chaining these functions in a particular way to get a desired transformation. When I need a different kind of transformation, then I just chain the functions in a different order. My experience is that the business logic naturally bubbles up to a thin layer at the top.
Mistakes? A dynamic language with fast protyping and a vibrant community helped them build a successful business. Sounds like a lesson of success to me.
Had they started building it in C++ or Haskell they might still be building it with 0 customers onboard while some other company which used Python would be dominating the market.
"Dynamically typed languages for large code bases are terrible."
Perhaps this is what you believe based on your experience or opinions on internet.
However large code bases, complex systems, have been used successfully, for example for:
- Driving the Deep Space 1 (DS1) NASA spacecraft for 3 days without manual input.
- Search for airline ticket reservations encompassing almost all the airports in the world and most airline companies, not to mention all the diverse routes available. Really complex stuff. (ITA software, currently in use across the globe)
These big, complex applications were written in a dynamically typed language.
You should perhaps mention that your examples are also written in a Lisp dialect which is a rather different thing from your average 90s script language.
The most important metric for Startups is time to market, developer productivity, fast iteration times and developer ecosystem which is why most startups (and many of the most popular websites) still use dynamic languages today.
Once their core feature-set is established and they've developed the product they want they can go back and optimize accordingly and rewrite parts of their code-base to use the most appropriate language, e.g. rewriting hot spots in C/C++/Rust/Go, highly concurrent features in Erlang/Go, etc. If code-maintenance becomes problematic they can explore annotating their code-base with Types, adopt linters or even rewrite into a statically-typed language. None of this is a mistake, languages/technologies are a tool to achieve your business objectives, if adopting a dynamic language lets you get an MVP quicker and add/change features based on Customer feedback quicker, then that's likely the best choice.
End users don't care what language servers are written in and it's definitely not a mistake to start with a dynamic language, even today.
Of course if you feel most productive with a statically-typed language that's a fine option as well which may result in less technical debt/rewrites later at the cost of initial velocity upfront.
I believe that we tend to get causality wrong on this one. I don't think dynamic languages have some intrinsic property that makes us more productive or facilitate faster time to market.
Rather, I believe that people who are concerned about the soundness, consistency and maintainability of their code, and hence favor powerful static type systems, are incapable of prioritising time to market.
Statically typed languages increase productivity by catching errors early, but decrease productivity by making users jump through hoops.
e.g. at one end of the spectrum is Java, which everything has to be a class. Even if you want to write a function, it has to be expressed as a static method in a class. In Java it's just not possible to implement ideas in the most obvious way, it has to be done in the Java way.
Conversely, TypeScript was designed to work with JavaScript (which is very dynamic), so it has a very capable structural type system. The productivity penalty is negligible.
What I love about TS is that it's up to me how much effort I want to put into the type system. I find that I end up using TS even for very small projects, because I can use it for only 'the important' bits.
That said, my background is mostly Ruby/Python/JS/PHP, so for all I know this is true of many statically typed languages (but from what I read this is not the case).
Still, for those with a background similar to mine I can highly recommend TS as a great starting point for more statically-typed code, precisely because it's opt-in if you want it to be.
End users absolutely care when the program or service is slow, unstable, drains your battery, is constantly offline, or has major security flaws.
Now there is no guarantee that a dynamic language will have those issues more than a static language, but I for one sleep better at night knowing my compiler is doing so much more work for me.
> End users absolutely care when the program or service is slow
A Ruby API with a good caching strategy is faster than a C/C++ binary with none and it's much easier to implement sophisticated caching strategies in dynamic languages.
> unstable, drains your battery, is constantly offline
Servers don't drain battery. Unstable, constantly offline has no correlation and is not limited to dynamic languages
> but I for one sleep better at night knowing my compiler is doing so much more work for me.
Right, choose whatever helps you sleep at night, but your language/tech choices isn't always what helps everyone else sleep.
A static language is less likely to throw a runtime type error, or coerce some value incorrectly, than a dynamic language. That does correlate with being unstable and offline.
Servers don't drain battery, but they cost money, so inefficiency matters server-side as well.
And comparing a fully-featured dynamic language implementation with a less-featured implementation in a fairly weak statically typed language isn't really a productive comparison, is it.
No bad developers create unstable software that's slow and offline all the time, not dynamic languages. The largest Internet sites were built on dynamic languages, they wouldn't have achieved their market position if they were slow, unstable or offline all the time - it's amateur hour to think it has any correlation with being implemented in a dynamic language.
Again a good caching strategy makes every language fast and in the law of large numbers scalability is more important that script execution performance. Servers of failed Startups also consume less energy then successful ones - another great example for spending precious dev cycles optimizing on the wrong thing.
Mose developers are average developers. If I have an average developer writing my mvp or adding user-defined features, I'd rather have a static type system to save them time. Otherwise they have to write more tests or fly by the seat of their pants, which may lead to all the issues I raised.
Just because successful companies use dynamic languages doesn't mean dynamic languages produce successful companies. And plenty of those companies had plenty of scaling issues and growing pains that just throwing a cache in front of didn't solve.
Dynamic languages are only faster to develop in because they are more ubiquitous and familiar, not because they inherently decrease the time it takes to write software.
And if you get to that point, where time is no longer a factor, then choosing dynamic just leaves more opportunities for inefficiency and runtine errors.
Your preferences helps you, other developers have their own language and tooling preferences they choose to help make them more productive.
> Just because successful companies use dynamic languages doesn't mean dynamic languages produce successful companies.
Talented resources is usually an ingredient that's shared amongst most successful companies and there is no shortage of talented developers preferring dynamic languages. Dynamic languages like python are also extremely popular in complicated fields like science, AI and machine learning, etc.
> And plenty of those companies had plenty of scaling issues and growing
Inefficient software can be written in any language and scaling issues are more often the result of poor architecture and unoptimal implementation than language performance. A successful company with growing pains is also more valuable than a failed company without.
> Dynamic languages are only faster to develop in because they are more ubiquitous and familiar, not because they inherently decrease the time it takes to write software.
That's incredibly naive. Developer iteration times are much faster in dynamic languages, tools that enable live programming, Hot reloading, faster run/build cycles have a direct impact on developer productivity and are commonly born from dynamic languages. A rich developer ecosystem is also an important factor in being able to quickly adopt well-written tested and hardened libraries which popular dynamic languages have aplenty which is a direct result of being able to attract a large pool of talented developers, languages that can do this are more popular than ones that don't, irrespective of their type systems.
> other developers have their own language and tooling preferences
Of course if you prefer a language, use it, but don't argue that your preference has any bearing on how well your language helps you avoid issues like runtime type errors that other languages don't experience. You either have to write more unit tests, or pray, or be infallible.
> there is no shortage of talented developers preferring dynamic languages
There is also no shortage of talented developers preferring static languages. And given the two, I know which developer I prefer. Especially since I've never worked with an infallible developer, even in the upper echelons.
> Developer iteration times are much faster in dynamic languages
I disagree, I find I'm about as productive in either, but in a dynamic language I have to write more unit tests or pray, and I don't like wasting my time on either.
> tools that enable live programming, Hot reloading, faster run/build cycles have a direct impact on developer productivity
> Of course if you prefer a language, use it, but don't argue that your preference has any bearing on how well your language helps you avoid issues like runtime type errors that other languages don't experience. You either have to write more unit tests, or pray, or be infallible.
I've not once mentioned my preference. My preference and where I spend the majority of my time developing server libraries and Services C# which I consider the most well-balanced modern statically-typed language available.
But I'm not naive enough to think everyone would be better off developing in C#, most startups prefer dynamic languages with good reasons stemming from being quicker to market, faster iteration times, more malleable in implementing customer requirements and having a rich pool of talented resources available. There are a lot of smart people sharing the same opinion, like Alan Kay:
> If you’re using early-binding languages as most people do, rather than late-binding languages, then you really start getting locked in to stuff that you’ve already done. You can’t reformulate things that easily.
Smalltalk was first released 45 years ago and it still has live programming features like being able to re-program its IDE while it's running that I've never seen any static language been able to do. There's a whole class of software I can't imagine being built in a static language, like Wordpress rich extensibility and plugin ecosystem, I've implemented a few Wordpress sites and custom plugins which would've taken an inordinate amount of time in a statically typed language. I've spent a few years developing PHP and I very much dislike PHP based on its language merits, but I have an appreciation of what it's been able to be built with it.
There are other classes of software that are extremely hard to implement in a statically typed language like React which IMO is revolutionary in developing complex UIs.
I also think it's infeasible for tools like Webpack to have been written in a typed language, where its able to import any kind of asset in the source files that use them, being able to easily chain loaders together, running incremental watched builds that transpile source code, generate source maps, inline images, cache-breakers, etc. Webpack's Hot reloading feature would also take significantly more effort to develop in a statically-typed language. Tools like this are born from dynamic languages because it's simply much easier to do which would've taken significantly more effort in a statically-typed language.
I also develop and maintain http://techstacks.io (Server in C#, not that it matters) and see the amazing number of successful products being built with dynamic languages, not in-spite of them. From what I've seen a large majority of successful SV startups use dynamic languages.
Languages and technology should be a tool to achieve your objectives, many technology choices involves trade-offs, dismissing and throwing shade on successful companies usage of dynamic languages prevents you from seeing the benefits they have in using them, what advantages they have and which scenarios where they'd offer the most compelling value. The reason why many amazing software and talented engineers use dynamic languages isn't because they don't know statically-typed languages exist - it's a mistake to write-off other people's choices because they don't share your same views.
That's fine, no one was talking about you specifically.
> I'm not naive enough to think everyone would be better off developing in C#
That's good. Neither am I, so I'm not sure why it is being mentioned.
> There are a lot of smart people sharing the same opinion, like Alan Kay
Smart people also have the opposite opinion. It doesn't mean anything; that part is all subjective.
> There's a whole class of software I can't imagine being built in a static language
A static language can have an "only known at runtime" type that lets you do the same thing as the default in a dynamic language, when it is needed.
> There are other classes of software that are extremely hard to implement in a statically typed language like React
Define "extremely hard". Would you consider Elm "extremely hard", for example? And why can't that model be used in other statically-typed languages? I think it's only a matter of time, personally.
> throwing shade on successful companies usage of dynamic languages
All I'm "throwing shade on" is the idea that users don't care about quality, and that static languages have no inherent quality advantages over dynamic languages. I disagree with either idea.
I have no qualms about which companies use which programming languages, as long as the result is a quality product from my (the user's) point of view.
If they get that quality through dynamic languages, good for them. I think they worked harder than they should have, and I think they are spending more money on server infrastructure than necessary, but that's their choice.
But I don't believe for a second that the quality, performance, or the end user experience was improved because a dynamic language was chosen. And this discussion (at least, where I chimed in) was precisely the point where the end user experience was called into question.
> A static language can have an "only known at runtime" type that lets you do the same thing as the default in a dynamic language, when it is needed.
In almost all cases runtime "holes" in static type languages provides a sub par development experience that's worse than both dynamic and static typing, it's definitely not a strategy for developing the same class of software on and it's not comparable to using a first class dynamically typed language. The places where it works is in static type systems are used to annotate a dynamic runtime like TypeScript, Hack and (less so) Dart.
> All I'm "throwing shade on" is the idea that users don't care about quality, and that static languages have no inherent quality advantages over dynamic languages. I disagree with either idea.
Suggesting dynamic languages are "slow, unstable, drains your battery, is constantly offline, or has major security flaws" is throwing shade with no basis in reality.
> why can't that model be used in other statically-typed languages? I think it's only a matter of time, personally.
It doesn't exist because it's simpler, requires significantly less effort and is more naturally suitable to implement in a dynamic language. In these classes of software choosing a static language is the wrong choice that will always yield inferior results due to their lack of dynamic capabilities and interested resources who naturally gravitate around dynamic language ecosystem. No doubt many devs will still try using their preferred static language but they will all fail to achieve anywhere near the level of success, featureset and penetration of equivalent dynamic language implementations.
Of course as it's software, given enough resources anything is possible, like Apple is able to do with Swift Playgrounds but they're in the unique position of being able to change Swift's language and runtime to introduce the capabilities needed to make Swift Playgrounds feasible - which is major strategic project for Apple which I still hold would require significantly less effort using a dynamic language. Google has the same benefits with what they're able to do with Dart where their flutter project offers a compelling live programming experience for developing native mobile Apps. Both would be considerably harder if they weren't able to change the language and runtime to make it easier for them, e.g. snapshots would be nigh impossible without language/runtime support.
Likewise their exists classes of performance and mission critical software that's not suitable for dynamic languages, but it's not always a mistake to start with a dynamic language first to prototype quickly then rewrite once the system requirements have been identified and solidified.
> Suggesting dynamic languages are "slow, unstable, drains your battery, is constantly offline, or has major security flaws" is throwing shade with no basis in reality.
What I suggested, if you go back and read my initial comment, was that static type systems give you a higher chance of improving performance, efficiency, and quality. I never said dynamic languages guarantee those issues, or that static languages guarantee the absence of those issues.
And there's plenty of basis in reality.
> It doesn't exist
It does exist.
> requires significantly less effort and is more naturally suitable to implement in a dynamic language
Maybe since dynamic languages are popular. I'm not convinced that dynamic typing made this easier, or if it just so happens that most people know dynamically-typed languages.
But that's beside the point completely.
The point was pretty simple (I thought...): Quality is visible to the end user, and all other things being equal, a static type system has a higher chance of resulting in quality software.
Now in the real world, of course, all other things aren't equal (otherwise everyone would just use statically typed languages). But choosing a dynamically typed language for those other reasons (your developers are more familiar with it, it has more libraries that you need) should be a conscious choice made knowing full well that you are opening your self up to a class of errors that you could have automatically avoided. If that trade-off is worth it to you (it is worth it to many) so be it. But the trade-off is still there, and when it does cause quality issues, users will notice.
I'm not saying using a dynamic language is a mistake and I'm not saying using a dynamic language guarantees the quality of the result will be lower (nor am I saying a static language guarantees the quality will be higher, although I believe it helps a lot), so arguing against those points is falling on deaf ears.
I've provided a number of examples, you've provided exactly none.
> I never said dynamic languages guarantee those issues, or that static languages guarantee the absence of those issues.
Your comments are full of snide comments against dynamic languages:
> That does correlate with being unstable and offline.
> plenty of those companies had plenty of scaling issues and growing pains that just throwing a cache in front of didn't solve
> choosing dynamic just leaves more opportunities for inefficiency and runtine errors.
> You either have to write more unit tests, or pray, or be infallible.
> but in a dynamic language I have to write more unit tests or pray, and I don't like wasting my time on either.
> and all other things being equal, a static type system has a higher chance of resulting in quality software.
Which is categorically False. Software quality refers to how well it adheres to its fitness of purpose and how it competes with competing alternatives.
Users generally prefer to use software which are easier to use and provides them the most value where by being able to iterate
quickly holds the most value, which is arguably an inherent benefit in dynamic languages and why they're a popular choice amongst startups. Especially when you're competing in a new market category, velocity is of utmost importance.
In fact almost all successful companies that I can think of that were competing in a new software category were developed using dynamic languages including: Facebook, YouTube, Instagram, Spotify, Dropbox, GitHub, Pintrest, Reddit, AirBnB, Uber, Slack, Khan Academy, Coursera, Twitch, Hulu, Kick Starter, Patreon, Trello, etc. Results are overwhelmingly in favor of building new products in a dynamic language. I struggle to think of any recent successful Startups that were able to out compete their competitors and achieved their dominance starting out with a static language. The major ones I can think of predominantly built with typed languages are: LinkedIn (2002), Netflix (1997), Ebay (1995), Amazon (1994). The most recent one I can think of is Stack Exchange (2009) (which I know of because I used to work there :). Of course once they've established market dominance and implemented their core feature-set many go back and focus on optimizing their system of which many identify and rewrite hotspots in more appropriate languages. Which remains a strong case for starting out with a dynamic language first.
> But the trade-off is still there, and when it does cause quality issues, users will notice.
There's a trade-off on whether adopting a static language is worth it, of which most successful SV Startups don't agree with - and their users are better off for it.
> Your comments are full of snide comments against dynamic languages
They are not snide, nor are they "against" anything any more than saying "the sun is yellow" is "against" the color blue.
Half or more of the things you quoted aren't even about dynamic languages, and the other half are true (or do you care to refute them? For example, if you don't write tests to take the place of static typing, and you aren't praying, then you are either infallible (ha!) or you are lying).
> Which is categorically False
Believe what you want; it's clear you aren't interested in opening your eyes. So be it!
And that big list of companies has nothing to do with the discussion. Of course they use dynamic languages. Almost everyone does, because they are popular and because some tasks seem easier in them. But there are still quality issues that could have been prevented.
> They are not snide, nor are they "against" anything any more than saying "the sun is yellow" is "against" the color blue.
> Believe what you want; it's clear you aren't interested in opening your eyes. So be it!
You forgot "Calling the Kettle Black". But I'm more than comfortable with my experience with multiple languages in each style enough to be able to identify their strengths and weaknesses and which scenarios each are better suited to, of which I've listed several examples which are better suited to dynamic languages. Likewise there are many that are not.
> if you don't write tests to take the place of static typing
Tests are essential to software quality and static typing does not absolve you from writing tests. Static Typing enforces Type correctness, it does not enforce program correctness.
> And that big list of companies has nothing to do with the discussion.
It has everything to do with which language yields the most benefits and whether Startups have made a mistake in adopting them, I posit they haven't and Empirical evidence suggests that they're a more suitable choice for Startups.
> Of course they use dynamic languages.
Of course.
> Almost everyone does,
Ok.
> because they are popular and because some tasks seem easier in them.
It's because they provide more value than not.
> But there are still quality issues that could have been prevented.
For which they often provide more benefits then they give up, which is entirely the point, that adopting dynamic languages is not a mistake.
My proposition was that dynamic languages offer better velocity which lets you get to market quicker. Static Typing helps with type correctness and maintenance of large code-bases and it's a perfectly fine strategy to rapidly prototype with a dynamic language first then rewrite identified hotspots and problem areas in a more appropriate language. Script execution performance is often not the bottleneck, a good caching strategy can make any language fast, areas which don't benefit from caching, i.e. high writes / high concurrency would benefit from a rewrite and in a growing user-base, scalability is more important than script execution performance.
> Tests are essential to software quality and static typing does not absolve you from writing tests.
No one said they did. You have to write fewer tests with static typing, not zero tests.
> My proposition was that dynamic languages offer better velocity which lets you get to market quicker
Velocity is subjective - perhaps for the developers in question dynamic languages are quicker to market, but I argue that is more because of familiarity and popularity, and less because of dynamic typing.
For example, developers I work with are just as proficient in both types of languages, and get to market just as fast with static typing, and in the long run they don't need to rewrite or chase typing bugs or spend more money on scaling inefficient software.
> No one said they did. You have to write fewer tests with static typing, not zero tests.
Typing is not a substitute for tests, you test for desired functionality in both. Albeit there's a stronger culture for testing in dynamic languages given they're more of a necessity.
> Velocity is subjective
No, Velocity can be measured.
> but I argue that is more because of familiarity and popularity, and less because of dynamic typing.
That's no argument, it's a weak and sheltered assumption showing a lack of first-hand experience. Don't presume to know that of which you don't know.
> For example, developers I work with are just as proficient in both types of languages, and get to market just as fast with static typing,
Of course you can't know that for sure, but it sure fits your thwarted view of them quite nicely. If that were true most Startups whose existence are hinged on their ability to get to market would not be overwhelmingly be in favor of using dynamic languages. Your goals as a technologist should be to adopt an unbiased view, identify strengths and weaknesses of each tool so you're able to make informed decisions about which use-cases are best solved by either. Your unknowledgeable and disparaging remarks on them wreaks that you're more interested in trying to confirm your own biases than you are on from ever being able to benefit from them in any capacity. Learning the idioms and being proficient in multiple languages will make you a better programmer, you'll learn elegant techniques, new perspectives and be able to identify friction that you can apply back in your primary language. You'll also be more productive in the large number of use-cases where they're naturally better suited. Add one to your toolbox today!
> in dynamic languages given they're more of a necessity
Sounds like you came around.
> No
Not everyone agrees that dynamic languages lead to faster velocity. Velocity is a function of many things (environment, culture, tooling, existing code bases, developer skill and familiarity with a language, how low you set your quality bar for your mvp, etc) and as I mentioned a few times now, different developers have a better velocity when working in statically typed languages.
"Improved velocity" is not an inherent property of dynamic languages, it depends on many other factors as well. I'm not sure why you keep ignoring that point (well I have an idea why...)
> it's a weak and sheltered assumption showing a lack of first-hand experience
It's not an assumption, it's an observation that I think extends beyond my direct experience.
I've trained many developers who were huge dynamic language proponents much in the way you are right now: any mention of an advantage found in a static type system sent them off into vague or straw-man arguments about how productive they found themselves in their dynamic languages, how flexible it made them, and how handcuffed they thought they'd be if they tried a statically-typed language.
In reality, they had never taken the time to learn any of the decent statically-typed languages, and when I probe as to why, the reason is usually because it takes more effort and because those languages aren't as popular (and sometimes a fear of the unknown).
Once they get up to speed, they find themselves just as productive, writing fewer tests, and producing higher quality software.
Of course it helps that the culture around me fosters that kind of thing: we write or provide tooling, and we have the senior developer resources to help other developers where a quick stack overflow answer won't solve their immediate problem, but as I said a few times now, those points are all orthogonal to mine.
> [Long string of ad hominem remarks]
I'm not sure why you think you know me, my experience, or what I'm proficient in, but you are mistaken (and if you had read the comments you replied to more carefully you might have realized that).
Since that's not a productive way to discuss a topic, I'll leave things here. If you wish to change the way you converse, I may be back, but it's unlikely.
I wanted to leave it, but it's full of misguided assumptions, so I'll keep try it short.
> Sounds like you came around.
No my experience hasn't changed, I've delivered solutions in multiple languages (with a majority of them in static languages) and am familiar with realities and cultures in each. I'm a proponent of technology and adopting the best language/tool for each use-case. I could list all the areas where dynamic > static and vice-versa but you're not interested in learning where they provide the most value so I wont bother. Using a single language/tool for everything is an inefficient use of developer resources. When I started out I also used to hold an affinity to my preferred language, but that eroded over time as I became aware of where my preferred language and ecosystem deficiencies and where their strengths lie, my primary concern is adopting the best technology that creates the most value with the least time and effort where I regularly use and explore different languages and frameworks to gain experience in them so I can identify their strengths, techniques, approaches and which areas they excel at.
> Not everyone agrees that dynamic languages lead to faster velocity.
An overwhelming majority of successful Startups do, you've yet to show any evidence suggesting otherwise, just biased hearsay. The most valuable Internet properties and successful startups are built on dynamic languages so your disparaging remarks suggesting they're "slow, unstable, drains your battery, is constantly offline, or has major security flaws" is a completely false straw-man that amateurs would say - those are not a function of language or in anyway represent the value created or talented engineers using them. If you actually believe this, it shows you don't have any first-hand knowledge or experience using them so I can only assume your remarks are used to reaffirm your own technology confirmation biases, either way that's how it comes across when delivered as a baseless slur. Personally I would've liked to see some examples and empirical evidence backing up your theories, because as it stands none of them hold any water.
You continue to argue against points that were never made and you claim my position is something which it is not. At this point I have to assume you are doing it intentionally, but either way, I'm not interested in being misrepresented constantly.
Actually I really wish there was an option similar to typescript for Python. There are promising things.. but the annotations, for example, are just not there yet
I'm very satisfied with the new typing [0][1] module. It's part of the standard library since Python 3.5 and it provides type annotations similar to those of Typescript. It's still missing some features (IMO), but it's also under active development, so I guess more useful features will come.
from typing import List
Vector = List[float]
def scale(scalar: float, vector: Vector) -> Vector:
return [scalar * num for num in vector]
def greeting(name: str) -> str:
return 'Hello ' + name
its not always about the size of the site, but the size of the code base, the amount of the services and most of all, the amount of engineers working on it.
In the many years I've done front-end with Javascript, type-related bugs were very, very rare. Textbook logic as why to use strong types make absolute sense. Yet in the real world, I've had to fight with logic, DOM, UX, framework incomprehension and other types of bugs - not types. Type issues were anomalies among bugs. When they came up, they were the easiest to fix.
Am I alone here? Anyone in the community have concrete examples of type-related bugs that took so much time to required using something like Typescript? Can anyone quantify that?
> In the many years I've done front-end with Javascript, type-related bugs were very, very rare.
Wow, really? My experience has been the complete opposite.
Most of the bugs that slip into production have been dumb type errors. Things like accessing a property on an null/undefined value, or on an object that doesn't have that property and unfortunately JS just returns `undefined` instead of complaining (these silent ones can live longer before being spotted).
It's because of these kind of bugs that i've found many JS codebases tend to become brittle to the slightest change, and very difficult to refactor into a good shape. And why i'm seeking statically typed languages like TypeScript on that front at the moment.
But that's really a symptom of a "big ball of mud" design (non-design, really), where everything has dependencies scattered all over the system, and to change anything you have to consider everything.
Type checking can help you with a few kinds of problems you'll have trying to make changes in those kinds of systems, but you still have piles of problems and it doesn't do anything to help improve the underlying issue.
Static types can help you with some small problems, but that doesn't mean much when the problems you have are big.
> But that's really a symptom of a "big ball of mud" design (non-design, really)
Yep, that's exactly the problem :)
The thing is that, without ease of refactoring, it's very difficult to change that big ball of mud into something prettier. In fact, i'd say that without ease of refactoring it's kind of inevitable to fall into that big ball of mud "design" in the long run.
(Note: static type systems are not the only tools to help with refactoring. Good test coverage, style guidelines, a well documented / simple architecture, are of course very helpful too.)
Exactly. Static types ( I've used flow not typescript, but similar ) and good unit tests allow ridiculously easy and merciless refactoring of enormous swaths of code in an extremely short period of time with incredibly high confidence.
Integration tests ( not to be confused with functional tests / i.e.: selenium ) that test multiple classes in concert via input / expected output give the most bang for the buck, because you know your code works as a whole.
Static types are especially useful in big ball of mud design because you can refactor it (like change the shape of a canonical object) and mechanically fix all write/read sites without running the code.
Not sure how that's a small problem unless you never refactor code.
It's more likely that OP finds such errors just as frequently but because they are relatively straightforward to fix he doesn't weigh them as much as edge case debugging.
I've heard this same argument from a coworker working on a different project recently working on React/ES6 stack - I check their TFS history and find 3 such fixes in last 2 weeks (and they have reviews before checking in to TFS).
There's a lot of type bugs in my code as I type it, and while I'm writing the unit tests, but I've been keeping track for the last year or so when they happen in QA or Prod and they are quite rare for us (as part of an evaluation of if we should move to Flow/TS).
But there was a heavy correlation between type bugs and the kind of code being written. Our transactional frontend apps? Most bugs are browser css issues, weird environment specific edge cases, misunderstandings of the backend, memory leaks, etc.
In apps that are data heavy though, or backend JS apps, its a whole other story. Type bugs all day every day (though a part of it is because we don't do many and they aren't high profile here, they're very light on tests).
So we moved the later to using tests. While it helps a lot, we did end up with a different kind of issues: broken type definition issues and bugs in the type system. Turns out a very large portion of DefinitelyTyped definitions (especially those of the more obscure libs) are broken and you can't trust them, but you lose a lot of time fixing runtime bugs the type system forced you to make. And while they never hit production, there's more bugs than expected in TS itself, and it takes a while to figure out if I'm doing something wrong before I go look at the bug tracker (the issues I hit have almost always been reported already, but I don't expect them). Fortunately that last category rarely cause issues in production.
If you're only writing good tests, there's very few tests you wont write: eg, if I test that my function returns the string "Foo", I don't need to test that it returns a string.
And even in sound (er) type systems like Haskell or Elm, I'd (probably. There are ways...) have to write that test.
In JS with Flow or TS though, there's very few (good) unit tests you don't need to write anyway. If your tests are filled with "expect(foo()).toEqual(expect.any(string))", the team needs to be coached on writing proper unit tests regardless of types.
Though the topic that most teams don't know how to write effective unit tests and that type systems help those teams is a totally separate one.
The short answer is: it depends. With TS you can choose how much type "soundness" you want. The --strict option is very useful[1], but even having it enabled you can still choose to explicitly type something as `any`, and bypass the typechecker if you want.
Something to note though: the example given in the article is not showing any problem in TS. That's how its structural type system works. Both Animal and Bird classes don't have any properties, so the type of their instances is the same as `{}`. If you change the Bird class to something like:
class Bird extends Animal {
song: string
}
Then the line that tries to push a `new Animal` into an Array<Bird> will not type-check, because the types are invalid :)
Unfortunately I feel that this type of example expresses what not to do with type systems -- favoring composition over inheritance goes a long way to not finding yourself in a brittle type hierarchy and especially in a JavaScript environment where composition is so easily used (and with typescript, still type checked)
Type errors might not be the biggest issue up-front when writing new frontend code, but refactoring JS becomes really hard as the LOCs grow. Typescript (static typeing in general) really helps with this as you can get instance feedback about how you're changing interfaces between parts of the system.
Another reason i've enjoyed TS is the editor intellisense support. It's really helpful when using a library to get type info in your editor instead of having to google when you forget what a function returns, for example. This is also helpful when you're coming back to code you wrote a long time ago, or a colleague wrote it, and you don't know what particular variables/function arguments/object properties are at a given spot in the code.
Like others, my experience was also complete opposite.
The app I did was a financial related app so we do some good amount of number crunching. From calculations, to transfers, and storage.
You won't believe how many type errors we had throughout the stack. It's definitely because of JavaScript's inability to do type checking.
One workaround people did was to do the type checking in the first few lines of the function call, which is how people that still do raw JavaScript, do it today.
function add(a,b) {
if (typeof a !== 'number') { ... }
if (typeof b !== 'number') { ... }
return a + b;
}
This eventually creeps throughout in the code and introduces this code smell.
This above can be solved by just using TypeScript.
For me it is not about catching bugs that would make it into production; I agree those are relatively rare. It is about catching simple mistakes while I'm in the middle of coding or refactoring. These are mistakes that even without the warnings would probably not even make it into a commit, but the warnings directly in my editor in real-time are an even shorter round-trip than test executions. It results in less fumbling around to find the actual cause of some failure.
I have seen quite a few of those - mostly in returning promise vs actual value from function in some special case.
The other class of errors was with objects that reference other objects - e.g. function takes `loggedUser` parameter which is expected to have property `finishedLevels` or some such and someone sends it `bestFriend` object that kinda looks similar but does not have 'finishedLevels` property.
Most importantly, you have to code differently when writing without typing. It felt as if my hands were cut of at first - I was often in "I would solve this easily in Java just by making interface that would communicate list of needed methods, but cant in javascript because there is no such thing as interface". This is also the likely reason why you do not see many bugs - you probably learned to avoid all those patterns and idioms.
Even more importantly, it really helps with refactoring if you can rename function/variable or change number of its parameters and have all the places (and exactly them) that call that place return error. I can refactor much more aggressively when working with java vs javascript. In java, I spend a lot of time changing existing stuff, when I am tired to do hard work. In javascript it is special thing you do when you are well rested and fully focused.
One major argument is that TypeScript gives you arity checking on function calls, especially as you're refactoring. Seems like a simple thing, but after using TypeScript I realized how much time I wasted solving things like that.
I am not a Javascript person, but my personal experience has been similar.
FWIW, I used to do maintenance programming on a ~250 KLOC application suite written in C. And nearly all of the "type errors" the compiler caught were instances of using some type T where you needed pointer-to-T or vice versa, which is a non-issue in Javascript.
Lately I have warmed up to statically typed languages, but among all the bugs I have run across in dynamically typed languages, unexpected/invalid/wrong types were very, very rare.
The benefit of good type system - IMHO - is not that it keeps you from putting string where a number is required. That kind of problem happens, but is usually easy to fix. But a type system that helps you distinguish between, e.g., numbers that are temperatures and numbers that are air pressure measurements is worth having around.
EDIT: I admit, C's type system is exactly the most sophisticated one I've seen.
> FWIW, I used to do maintenance programming on a ~250 KLOC application suite written in C. And nearly all of the "type errors" the compiler caught were instances of using some type T where you needed pointer-to-T or vice versa, which is a non-issue in Javascript.
How is that a non-issue? If you don't have unit tests covering your entire code base you wouldn't notice a bug like that until it broke in production.
Having type checks let's you catch obviously wrong things like accessing a Promise return value directly rather than interacting with it as a Promise (i.e. then or async/await).
In C, there is a distinction between a value and a pointer to some value. In Javascript, as far as I understand, everything is a reference, so the specific mistake the C compiler caught would be impossible to make in Javascript in the first place. (Then again, C does not have concept of promises.)
I am not saying type checks are bad or useless. In fact, over the years, I have grown to appreciate every little bit of advice a static analyzer can give me. But among the bugs I have produced using dynamically typed languages, few had to do with using the wrong type.
> C's type system is exactly the most sophisticated one I've seen.
Oh-oh, too late to edit.
Of course, what I meant to say was: C's type system is NOT exactly the most sophisticated one I've seen. ;-) I like C a lot, but type safety was not its top priority.
Is it "necessary"? Of course not. Lots of people have done without. I do find that it makes it more productive and easier to debug, especially if you're making something like a SPA with complex functionality.
Also, the point isn't so much that there is one major, hard-to-fix bug, but that there are lots of small ones that you never encounter.
I agree. Type-related bugs of the kind that TS can catch are indeed rare and trivial. However, TS does help with documentation, intellisense and refactoring. Personally, I will usually go with Babel/JS, since I don't find that the benefits of static typing outweigh the costs.
Everything required to add that to regular Javascript: transpilation, extra markup and understanding and mastering a new tool. Another layer to manage and debug if you will.
Assuming you use ES6+ in production, so you need a build step anyways, would you still say TS adds costs that aren't worth it to you? And if so, which costs? I mean that in full honesty, as I generally find myself conflicted whenever I start a new project: TS or ES2015+?
> Javascript, type-related bugs were very, very rare.
That's because you're not seeing them. I bet that if you plug your frontend to an error-reporting tool (e.g. Sentry) you will be overwhelmed to see all the corner-cases you are overseeing.
Catching wrong-type bugs is, for me, relatively low on the list of reasons I enjoy using Typescript. A few of my higher items would be: strictNullChecking, intellisense, and refactoring.
Agree the academia-touted benefit of type-checking isn't that helpful in practice. But types help with documentation and tooling (completion, data-mapping etc).
Types are (apparently) crucial for large projects. However, the #1 benefit is speed, which I don't think Typescript can provide.
After I wait eight seconds for the page to load, I see your lovely reminder that I should "View Reddit in the app because I deserve the best." At the very least, you could have the decency to harass me about your app while I'm already waiting.
Also, I can load the desktop version of the site in under a second on my phone. IMO y'all should've stuck with some good old fashion HTML and CSS, especially since there's nothing dynamic about Reddit's content.
Hell, you guys could probably get away with responsive styles alone, but I get it. As a business, you find it optimal to piss off your users into downloading an app so you can send them push notifications, dig into their contacts, and find out where they're eating tacos.
> IMO y'all should've stuck with some good old fashion HTML and CSS, especially since there's nothing dynamic about Reddit's content.
Agreed.
I use mobile tethering as my home internet. Currently reddit loads in under 1 second per page usually. The new JS-heavy profile page usually takes 5 seconds or more to load (assuming I'm willing to enable JS to see whatever crap is on one when I bump into them -- usually I'm not...) Note that that's with full bandwidth. When I hit my data cap, I'm throttled to 8KB/s... The current design of reddit is one of the few sites that I can actually reliably load quickly under those conditions! They should seriously think twice about throwing away something that works that well.
Personally, I find the entire experience to be incredibly slow. Loading the front page takes multiple seconds, there is a noticeable delay between tapping a link and any form of response, and back navigations are often unexpectedly slow.
Non-SPA related, I also think that many of the touch targets are too small, or work in unexpected ways. Tapping a username collapses a comment, even though there's an arrow next to it. Tapping an image associated with a link doesn't follow the link, it expands the image (even if it is an article link). Tapping the title takes you to the comments, not the article. The only way to get to the content is to click the itty bitty domain title beneath the title. All of these behaviors are different than how the desktop view behaves. For a site that calls itself the front page of the internet, it's getting harder and harder to get to actual content.
That's funny. Reddit took over my [desktop] web surfing precisely because of how much faster/cleaner it is than any other comparable website. Beaten only by HN.
I am going add my experiences here, in hopes someone from Reddit sees them, but they are more or less the same as everyone else's criticisms.
The reddit mobile site takes 13 seconds to load on my Nexus 6 over wifi. Then it has the nagware ad to try to get me to install the app, which only has a tiny 'go to mobile site' link directly underneath the large 'continue [to download]' button. Once reddit has finally loaded, every link will then first ask you if you want to view the link the app, before allowing you to continue. Meanwhile the UI, while cleaner, is debatably worse off UX wise as everything is now small and laggy.
So to summarize, it is terribly unperformant app, filled with dark patterns and dubious UI improvements.
On Chrome on iOS on iPhone 6, posts take too long to load, and having more than 3 gifs expanded at once crashes my browser. Also manual pagination instead of infinite scroll is a little annoying.
I've worked with TypeScript on and off for a couple of years now. I don't like it.
The compilation step is a major pain. Even after using it for several months straight, I feel like I'm in a constant battle with the compiler. It's slow and difficult/annoying configuration problems keep coming up from time to time. It slows down my debug cycle and the compilation delay makes me lose my train of thought. I used to love using console.log() to quickly test an assumption in JavaScript; you cannot do this with TypeScript (it's not practical given the 5 to 20 seconds compile time); you have to use the debugger every time and step through stuff (even when you have a very good idea about which specific variable you want to check) - It's extremely cumbersome.
I have gone back and forth from dynamically typed languages to statically typed languages many times for years and I've spoken with engineers who used to be Java developers for many years, then switched to Javascript, then TypeScript and they shared the same thoughts as I did. TypeScript is slow and restrictive in a way that is unnecessary. It's got Microsoft all over it.
Also it forces all developers to use bulky commercial IDEs like WebStorm because you rely more on code completion to help you figure out the right types. You can say goodbye to Atom, Sublime and the rest... Atom's TypeScript plugin is not good enough unfortunately.
At my previous work, even developers who said that they liked TypeScript secretly didn't like it because they used the 'any' type Everywhere.
I wonder if the people who are making this decision have actually tried TypeScript themselves for any decent amount of time on a decent sized project. I don't think they know what they're getting into.
I decided not to renew a lucrative contract at a finance firm as a front-end developer in part because I did not enjoy using TypeScript every day.
> It's slow and difficult/annoying configuration problems keep coming up from time to time. It slows down my debug cycle and the compilation delay makes me lose my train of thought. I used to love using console.log() to quickly test an assumption in JavaScript; you cannot do this with TypeScript (it's not practical given the 5 to 20 seconds compile time);
Have you ever used `tsc --watch`? First build can take long but modification and rebuild takes < 1s.
> you have to use the debugger every time and step through stuff (even when you have a very good idea about which specific variable you want to check) - It's extremely cumbersome.
You don't "have to" use the debugger if you prefer `console.log` all the way. However in the debugger there is a "watch" tab for inspecting specific variables.
> Also it forces all developers to use bulky commercial IDEs like WebStorm because you rely more on code completion to help you figure out the right types. You can say goodbye to Atom, Sublime and the rest... Atom's TypeScript plugin is not good enough unfortunately.
Using console.log is not practical with TS because I only get one chance per debug cycle to log the value of the variable which I think is of interest. If that doesn't give me any insight, I have to log another variable. This is fine with JavaScript because it takes me about 2 seconds to add a console.log and check it. With TypeScript, the cycle takes about 10 to 15 seconds, so it's not efficient to do that, so yes, I end up having to fiddle with the debugger, add watchers and hover over individual variables... I kind of have to deal with the debugger's clunky UI every time which is slower. If source maps don't work correctly (as was the case for a lot of projects), then the debugger is even more of a pain.
I've worked on TS on large existing projects as part of large teams. In my last project, we did have some sort of file system watcher but it still took > 10 seconds on average to compile. Launching the project from scratch took longer than 1 minute. From time to time, I did have to relaunch the whole app; usually for a different reason every time.
I have been working now for 2 years with Typescript on a heavy SPA in combination with ASP.Net / AngularJS 1.5 components, and absolutely love it. I have zero compiler issues. We started with plain javascript but switched to Typescript later on, and it still amazes me how many small mistakes we made that have been preventing by just adding typing. Automatic Refactoring and Find Usages alone are worth 10x the small delay in compilation.
The biggest gripe I have is that Chrome debugging is hell, because sometimes it will recognized the typescript, sometimes only the javascript. I have hit Ctrl-P many times to "establish" mappings between files running in IIS Express and local files. Miss and hit.
I use console.log all the time so I don't understand your comment in that regard. It works perfectly fine with Typescript.
Ah yes I had forgotten about the source map issues. My point is there is almost always something wrong with it depending on the project. The source maps issues are pretty serious.
Not having the same code on paper and on machine so to speak does make debugging typescript a little hard. It's a little bit of a black-box.
I code typescript for Angular 2/4, and although yeah, the aforementioned debugging pains are annoying, the time saved on having types to enable linting and strong predictable variable comparisons, is much greater.
Also, needing console.logs everywhere should be discouraged. Your code should be clear enough that you don't need a console.log debug line to print the boolean result of a comparison, for example. This is the whole point of typescript like I said, to make variable comparision and management easier so that you don't need that console.log line...
I don't mean leaving console.log everywhere, just when debugging, when you want to check the value of a specific variable quickly without having to click around in the debugger.
Developers from statically typed backgrounds just don't seem to understand this use case. It's the quickest way to find an issue when you have a good idea of where the problem might be.
I suppose. I come from the C and C++ world, before I moved onto webdev (quite rare for a young millennial like me to be dinkling around with static C-related languages, I've been told by older colleagues), so I guess that I don't see it from the most understanding point of view.
I also used a fair bit of C/C++ in the past, the debugging process feels very different to me. It's definitely much slower but in that case it's worth it because of the flexibility you get out of it.
When you use Javascript for a few years, your habits change and you get used to really quick debug iterations. With Typescript, you get slower debug iterations but you don't get any extra flexibility beyond what Javascript itself offers. No pointers, no threads, no low-level access to system calls, no custom memory allocation, no performance gains... It doesn't have any of the features that make C/C++ an awesome language.
You don't need years of trials. One thing that people forget is that types are a parallel ecosystem more times than not i.e. DefinitelyTyped. So you do not have that lock-step that is praised. So imagine wanting to use a brand new webextension api - stop, add it to types. Want to upgrade a dependency - stop, the types are not working/incorrect/incomplete e.g. https://github.com/DefinitelyTyped/DefinitelyTyped/issues/17...
AFAICS the Typescript types ecosystem is bigger simply because Typescript has been advertised to devs coming from a background of a statically typed lang, and they cannot imagine not using types, thus they drown in them.
Flow on the other hand appeals to those that want types primarily in their own codebase, and come from inferred/dynamically typed langs, where you gradually add static types starting with key sensitive parts in your codebase e.g. Erlang http://learnyousomeerlang.com/types-or-lack-thereof
I think some developers have had a grudge with Javascript since the dawn of time and just cannot move past it. They'd rather move mountains than try to adapt to the environment.
Definitelytyped is frustrating; sometimes they have the type definitions sometimes not. Often the definitions are out of date and new ones are not available. Sometimes I feel that it's better not to use it at all... That way I don't have to think about it.
You don't have to add types to start using a new library or web extension. At most you have to add 'declare var foo: any;' or cast a builtin to any if the type declaration doesn't have the property you need. Typesript always lets you use the any type as an escape hatch if you don't have types.
What about using the TypeScript toolchain as a JavaScript static analyis tool without actually writing in TypeScript? (tsc can still verify your js files are minimally 'correct' through type-inference, for example).
I'm coming at this from the Elm-camp, and my first impression (and largely why I think languages like Elm is promising) is how languages that are implemented as supersets of other languages have the potential to be as bad as their subsets.
The example that I was given was C++ and C, but I think TypeScript with it's gradual-typing approach is forced to remain potentially as bad as JavaScript itself - that is, if you're feeling weak and want to "get shit done", you can bypass all the goodness that TypeScript undeniably offers you.
For a language like Elm, the type-system is invariably gonna have your back - a value-proposition I think means a lot more in practice than some self-proclaimed pragmatists realize :)
I absolutely love Elm, and think it's great because it's a totally new approach for the frontend. That said, new approaches take much longer to build the critical mass for adoption than incremental ones (like Typescript). In a lot of ways, Elm reminds me of this Onion article from the early 2000's.
"Ghost Of Christmas Future Taunts Children With Visions Of PlayStation 5"
There's a project on my plate right now that when I saw the requirements and specs, I immediately thought, wow, Elm in a year from now would be absolutely perfect for this.
But it's just not there yet, so I'm exploring things like Typescript that have the advantage of the Javascript ecosystem beneath it. But I really cannot wait for Elm to be production-ready across the board and not just for specific use cases.
Or to go all-in - we have a `--strict` flag that gives you `noImplicitAny`, `strictNullChecks`, `noImplicitThis`, and a mode that always puts you in `"use strict"` mode.
I don't understand why `strictNullChecks` is not the default behavior. It being a special compiler option makes me somewhat dubious of TypeScript in general.
Dynamic language proponents sometimes like to say that static types can't catch all errors and are therefore of little use.
Static type proponents sometimes like to say that unsound type systems that leave escape hatches are of little use.
The truth is that both are somewhat wrong.
Types are a tool. They help catch some errors and help code evolve - even when not completely sound, they still help catch some errors and evolve code.
They also don't understand all correct code, so sometimes they get in the way and when that happens, its important to get them out of the way in a manner that doesn't compromise things too much.
Nothing is black and white, there are only shades of grey.
In Haskell you can also explicitly cast to any type a using "error", "undefined" and "throw". But that's just what exceptions are in Haskell. This is fine, as long as it's only used in exceptional cases.
Wondering why Dart was not considered. Large apps are written in it (Ad sense UI, Ad Words UI, Google CRM). Has good tooling (IntelliJ plugin, Webstorm). It's fairly easy to pick up - Java/C# like syntax. It's harder to shot yourself on your own foot (it's not JS superset). It has strong mode. It has superb tooling and package manager ( dartanalyzer, pub)
Dart is for Google, by Google, and external engagement has been as neglected as for all of Google's front end efforts. Google ceded the thought leader position in this area years ago and everybody knows better than to trust any of their new efforts.
There's still polymer which is developed by chrome team and angular2 by ads department and those seem to be quite industry proven. E.g. angular2 is one of the main adopter of typescript.
Yes, and what kind of reasoning is that? You do not fork a language to make your framework a little more convenient. It's inane. That's how you end up with both a dead language, and a dead framework.
Microsoft saved them from themselves. (I expect they could have arranged to have the feature added without first publicly declaring their intention to fork the language, but that's above their community engagement skill level.)
Google's Closure Compiler was the best version of compiled JavaScript for five years. It should have been the winner, but Google did nothing to make it palatable to the open-source community (docs are a disaster, the code is full of unexplained Google-specific workarounds, it integrates with nothing), got trampled, and now they're forced to adopt someone else's tech to remain relevant. Google is so bad at this.
If you look through the flow source code then you'll find many facebook-specific features. Search for 'Facebookism'! I don't know about Dart. But TypeScript is written primarily for the community, not for Microsoft.
Because Dart is a different language. Typescript is (mostly) Javascript with type annotations, so there is nothing new to learn. In theory, you can just change the extension of a file from .js to .ts to convert it to Typescript.
I recently moved to a company using Flow from one using TypeScript, and it seems like the tooling ecosystem for TypeScript is way better than flow. The emacs plugin for flow in particular is practically nonexistent, and doesn't even provide proper syntax highlighting. TypeScript's by contrast is amazing.
I recently had to do some Node.js scripting. My JavaScript experience was minimal and having worked almost exclusively with typed languages I considered Typescript. I decided against it eventually because I figured you need to know JavaScript first to understand the JavaScript ecosystem even if you are writing your own code in TypeScript.
Does this make sense or is it feasible to skip learning JavaScript and jump directly to TypeScript?
TypeScript is, strictly, a superset of javascript. You probably could "jump directly to TypeScript" but you would not be able to "skip learning JavaScript" as TypeScript is based off the concepts in JS.
That being said, I don't see why you couldn't learn them concurrently; you can learn the basics of TypeScript and then simply rewrite any relevant JS example code into TypeScript to learn JS code in a TS context.
Edit: I should also point out that integrating with any JS libraries may require you to install the '@types/' package alongside it to maintain type-safety. For example, if you're using jQuery, you can install the '@types/jquery' package which will expose all the type information for the jquery package.
The downside of going straight for TS is that it's a bit more work to figure out how to build and debug (with sourcemaps) if you're not too familiar with front-end development.
On the other hand the upside, and a very big one, is that if you set up the relatively simple TS build process, you automatically get all the ES2015+ stuff for free, even without needing to figure out Webpack and Babel and the like (with some caveats front-end-wise, primarily Promises and Fetch).
You need to understand JavaScript and the ecosystem. Even if you're going to be writing TypeScript, other people will probably be using regular JavaScript. But TypeScript is a superset of JavaScript, so it shouldn't be very difficult to pick it up. You need to learn to crawl before you can walk, as they say.
If you want to develop an in-depth understanding of the language, I suggest reading through the ExploringJS [0] series. It covers pretty much every single edge case and detail. You don't have to read each book cover-to-cover, you can just skim parts you're familiar with.
To give you an idea of how awesome it is... Exploring ES6 is my go-to reference for anything related to ES6. When I first discovered the book I'd already been writing ES6 code for a while, and I thought I knew everything there was to know about it. But upon reading it, I was blown away by how many things I hadn't been aware of.
> Does this make sense or is it feasible to skip learning JavaScript and jump directly to TypeScript?
It's definitely feasible and it will even save a few headaches. It's especially good for learning the API because, of course, it provides intellisense.
I find myself downloading type definitions for JavaScript libraries because it's often a quicker form of documentation than the library's official docs.
> I was more worried about not understanding other code and libraries that are written in JavaScript style.
There isn't much stylistic difference; TypeScript is not a huge departure from JavaScript.
I didn't expect TypeScript to be a problem. I was more worried about not understanding other code and libraries that are written in JavaScript style. It seems a lot of design patterns used in the JavaScript world make sense once you understand the strengths and weaknesses of JavaScript.
You'll need to understand JavaScript. One of the things I like about TypeScript is that it tries to 'fit' JavaScript, but the consequence is that you need to understand JavaScript to be proficient in TypeScript.
That said, I suspect it won't be too difficult, and quite worth your while, to learn 'idiomatic JavaScript' if you have experience with at least one other language. And especially with ES6 (which is 'included' in TS), if you have any experience with Ruby or Python you'll be fine with JS and it might even be a relatively pleasant experience.
Typescript is very similar to ES6 (new JavaScript). You can probably learn both with TS. You might not learn the weird JS quirks if you have to go back to ES5 at some point though.
Reddit should stop promoting their app on every freaking action you do on their website. I refuse to install because of it. Just build a better website.
Javascript is a weakly typed language and no superset like Typescript or Flow will solve this problem, just mitigate it.
However, on the other hand, I think that a good, experienced developer has no problem with that. The bugs that the experienced developer "fears" have nothing to do with type errors, which at the end are rather easy to solve...
> The bugs that the experienced developer "fears" have nothing to do with type errors, which at the end are rather easy to solve
Not sure how you define "experienced developer", but I think you got it backwards.
A good type system enables you to structure your code in a way that most sublte bugs are "converted" to type errors. That's the magic of types!
Your type definitions aren't just some syntactic sugar so that the type checker finds some typos.
Your type definitions are a vital part of the code base that you design to protect it from changes that introduce subtle bugs - the kind of kind you can easily foresee when you wrote a particular module, but which others (or yourself after 6 months) won't be aware of. This is especially important on refactoring, but also super helpful for non-trivial extensions.
In that sense the types are like unit tests. Although they are less flexible than unit tests (so they are no substitute), they make most of your unit tests unnecessary and are shorter and easier to write and to maintain than those unit tests. Most importantly, however, they "test" all cases, statically at compile time, not just the specific cases of your unit tests.
Good reply, but the benefits you described are already realized by strong typing, which is not the same as static typing.
A language with strong typing (which additionally can be a dynamically typed language, something that many people are not aware of) will catch any of such type errors, without having to bother adding type specifications/signatures everywhere in your code. Thus, those are bugs that are trivial to solve.
And this, to paraphrase your post, protects your code from changes that introduce subtle bugs.
You can also have a language that is statically typed but that has weak typing! Which language? C. And i think everybody knows the extra effort needed to keep a C program bug free. And this not only due to lack of automatic memory management!
I have been programming for most of my life, that is about 23 years of programming on where 20 of those years were using statically typed languages, including many years programming on large, business-core systems on Java and C#. I since have gone to dynamically typed languages and never looked back. You just need strong typing, that's enough.
A compiler verifying against a static strong type system proves certain properties about your program which provides some assurances about what your program can and cannot do.
You might be able to prove more assuring properties about your program with a test suite.
When the GP said:
> A good type system enables you to structure your code in a way that most sublte bugs are "converted" to type errors. That's the magic of types!
I am almost certain that s/he meant type errors uncovered without actually executing the program. In a dynamic strongly typed language, you will need to execute the program and force it into these errors - presumably using a test suite.
> A language with strong typing (which additionally can be a dynamically typed language, something that many people are not aware of) will catch any of such type errors, without having to bother adding type specifications/signatures everywhere in your code.
A static type system does not need type specifications/signatures "everywhere" in your code. In Java and C#, it does. But many modern languages, TS included, can infer static types to a large extent.
> I am almost certain that s/he meant type errors uncovered without actually executing the program. In a dynamic strongly typed language, you will need to execute the program and force it into these errors - presumably using a test suite.
Yes, this is exactly what I meant. Well, I was really arguing for both, static and strong typing, although my argument concentrated more on the "static" part, as that gives you safety and correctness guarantees that cannot be achieved with assertions and unit testing at all.
> A static type system does not need type specifications/signatures "everywhere" in your code. In Java and C#, it does. But many modern languages, TS included, can infer static types to a large extent.
I relied on type inference a lot when writing OCaml code. However, I noticed that on some places I still want explicit types. (I just don't want to be forced to type them on every variable.) For example, on most function definitions an explicit type helps a lot. Otherwise, the compiler can only tell you that your function call doesn't match your function - but can't tell you whether your function is wrong, or the code using it. With an explicit typing of the function, you know exactly which side is wrong. Also, in case it is the function, you'll note this when writing the function, not later on when trying to use it.
As much as I am disappointed that Nim wasn't chosen, I am impressed that it was mentioned at all. Nim's JS backend is still rather young, and tooling is definitely lacking. But you can make some pretty cool things with it[1].
Yeah, I did a double take when I saw it on the list. We use Nim at my new work extensively for some back end stuff (mainly homomorphic encryption experiments, but a full implementation of Paillier is also in it!) and I've just started getting the team to leverage it for the front-end too :)
Yep, especially because IBM just gave me a 20-core (8 hardware threads per core) POWER8 server with 256GB of RAM to run this stuff on, so I'm going to have a lot of fun getting Nim up and running on it!
The intellisense you get with TS is quite nice, as is improved refactoring. I also think typing in function signatures is a good thing and increases comprehension.
But the type-safety you get with these kinds of static languages only catches a few trivial bugs. There are also some situations where TS complains where it shouldn't, for instance it doesn't handle JS' built in reduce function very well.
In the end, it's a trade-off between the benefits and added costs. It is in no way a given that adding static typing to your JS project will be beneficial when all factors are considered.
By contrast, does anybody think that having "stronger" dynamic typing (don't convert strings to numbers as implicitly, etc.) like Python's would not be a huge benefit?
That's actually one reason why I often opt for TS. While the 'stronger dynamic typing' isn't the most sexy benefit, it has saved my ass quite often.
There are so many situations where my input is strings (JSON through various API's) that should get turned into just integers, floats or (string) constants shortly after being consumed. Using TS types from this point onward promotes discipline to do so on my part, removes any ambiguity going forward, and alerts me if I treat these values as strings or any other wrong type (which commonly happens to me, at least, when using vanilla js).
I agree - one thing is noticing bugs, which is easier with stronger dynamic types.
And as you say it's also important to setup some boundaries so that bad values can't travel to the other end of the program before you notice, which is a pain to debug.
I like to make value checks on module boundaries, but do much fewer checks inside modules. I typically do this using assertions. Optional types can be a way to do it with less noise. But they still can't replace asserting arbitrary invariants, like invariants involving multiple values.
I've been using TS since it's .8 days, and love it - but I think it's stretching things to say that it's an excellent language. It's a pragmatic language that makes JavaScript (which is an awful language) tolerable.
It's an extremely conservative language, offering little to nothing interesting that would make anyone switch from other solutions.
The ecosystem doesn't help it either:
For the frontend, it's stuck in a middle ground where it requires a JS interop layer (unlike TS, where it's typings are just an extra) but doesn't offer anything significant like Elm, BuckleScript, F#, ClojureScript and so many other great languages do when it comes to expresiveness. It doesn't even have algebraic data types, something TS does.
For the backend, it competes against almost all the frontend languages (due to node or native) as well as the big boys with huge ecosystems, variety of paradigms and amazing performance.
For mobile it has Flutter, which competes with Xamarin, Kivy, Qt and other bring-your-own-widgets solutions (deal-breaker for some apps and teams). In this case, Flutter is something I wanted to try out since those other solutions left me wanting and so did React Native, but Dart being such a lackluster language completely put me off of it, now having to turn to native with Kotlin after all this time looking at (and somewhat helping develop) the x-plat ecosystem.
I don't doubt that Dart will remain healthy for a long time due to Google's investment in it, but honestly, even if Fuchsia ends up being Android's succesor and Flutter ends up as its graphical toolkit, I'd instantly start looking for languages targeting the Dart VM or native interop.
The three biggest issues I have with it are these:
1) Language. Elm has set the standard for web languages and after using it for a while, JS or many of the popular replacements such as TypeScript are plain insufficient when it comes to providing as many compile-time safety guarantees. Doesn't help that I'm getting into Idris and even Elm's shoes are starting to feel a little too tight.
There's a project to write Elm and target React Native, but it's still too immature and it makes the next two issues worse.
I've yet to look at RN development through a BuckleScript stack, so that may be an acceptable alternative (even if not as safe as Elm, but on par/better than Kotlin)... but won't help at all with the next point.
2) Requires very complex tooling. This complexity will rear its ugly head when doing anything slightly out of the ordinary. All solutions (including Expo) I've seen seem to suffer from that issue, just with different defaults and different amounts of work necessary for different tasks.
I am not oblivious to why this is, since RN is not only based around the JS ecosystem and all the insanity that comes with it, it also has to deal with being a fat abstraction over native rather than take the easy way out, rolling its own cross-plat rendering and give up native widgets.
3) While it has come a long, long way, performance on old Android devices is still not always as smooth as native. I'm not sure how much this can realistically be improved since the bottleneck is interop, and avoiding it or shifting work around between native and JS is just not something I want to worry about.
However, this third point has improved so much I'm ready to handwave it away if the former two weren't a thing.
Lastly, not an issue with React Native itself, but JetBrains absolutely has the intention to bite into iOS' territory with Kotlin Native... and assuming they can pull off a half-decent adaptation of Apple's APIs I'm betting they will be the ones to finally take the x-plat cake, which makes it hard for me to believe investing time and code into RN solutions is a better proposition than native.
Hope that was useful in some way. If I should clarify anything or I have any misconception about RN please let me know.
" offering little to nothing interesting that would make anyone switch from other solutions"
Huh ? Compared to JS - Dart seems like a heaven. Don't known Elm - but looking on syntax it seems it's not so easy to pick up as for someone with Java/C# background. It's true Dart is not another fancy lang - it's very pragmatic.
Compared to JS, yes. But it's not JS that Dart truly competes against, it's all the other compile-to-JS languages some of which I mentioned, and Dart simply can't beat their pragmatism and/or expresiveness.
Elm is deceptively easy since it has great docs, the best compiler errors in the entire industry (no exaggeration here) and skips all the voodoo incantations of pure functional programming favoring a familiar language instead. Took me a couple of days to start writing toy websites with it coming with no functional experience, and a week to be productive.
I've been digging a bit into Dart as I've read through Fuchsia's docs and poking around with the source.
It looks like a great language, but I think it hasn't done well on the web because it has very poor interop capabilities with JavaScript and its ecosystem. I'll note that I haven't dug that deeply into Dart, so maybe there's some great resources I've simply missed so far.
TypeScript and Flow are both great options because they work completely with existing codebases. They can be adopted gradually and integrate well with the ecosystem.
Another language that looks promising is Reason [0]. It's still very young, but they seem to be working hard to create an awesome language with a great interop story. Check out their getting started [1] guide. Most of the info related their interop is in the BuckleScript User Manual [2].
TS has nice features to avoid js bombs but all JS 'bad code' is legit by definition (JS superset). TS is super nice compared to JS but it is NOT excellent Lang.
> all JS 'bad code' is legit by definition (JS superset)
That's not true. There's a lot of JS code out there that is certainly not legit in TS. Probably the shortest example is `1 === "a"` which produces a TypeError, but if you use TS at all you'll understand that a lot of bad patterns are made painful or impossible thanks to the strict type system.
== versus === and all the other weak typing wats, undefined type still exists in typescript, no integer type, UTF16 strings are the ones coming to my mind and I don't even program in JS/TS
In a word, "correctly". The result of an expression with + or isNaN() will be of whatever type the JS spec says it should be. This is one of the less frequently touted, but more useful aspects of TypeScript - the lib.d.ts file acts as a partner to explain to you how the built-in JS type system actually works without you having to memorize or look up everything in docs.
For == vs === use a linter, same as you would for warts in other languages.
What's the issue with undefined - is it that you would use null instead?
I don't feel a need for integer type, but maybe that's because I grew up on JS. Integers feel like warts to me in a lot of cases, ie why would 2/3 == 1?
2/3 === .666666666666666629659232512495 is probably worse, because it can seduce you into thinking it's accurate. Why is `2 / 3 * 3 === 3`, but `1 / 3 * 3 < 3`?
JS's floating-point-or-bust, combined with some weird Math semantics, makes it challenging to write numerically correct functions.
Floating point tends to break all sorts of assumptions. For languages without static types, bignum integers and distinct operators for truncating vs FP division is probably best. This is how Python 3 works, plus Haskell and SML (with static types).
TypeScript addresses many of JavaScript's type-related issues but retains other JavaScript insanity: bizarre array semantics, Unicode ignorance, no integer arithmetic, regex facepalms, Math weirdness, etc.
The root of the wtf is how Arrays play double-duty as both indexed and associative. The ES spec says that if you modify a property of an array object, the implementation must check if the (necessarily String) key changes after being round-tripped through a UInt32 conversion. If not, the key is a special array index that bumps the length; otherwise the length is unaffected.
var arr1 = []; arr1[2147483648]=1; // arr1.length == 0
var arr2 = []; arr2[2147483647]=1; // arr2.length == 2147483648
var arr3 = []; arr3[-1]=1; // arr3.length == 0
This is JavaScript so naturally .length is settable:
var arr = []; arr.length = 3; // works!
But implementations are still required to distinguish between keys that are undefined and keys that outright don't exist:
var arr = []; arr.length = 3;
arr[0] = arr[2] = undefined;
for (key in arr) print(key); // 0, 2
And of course you can set whatever random associative array property you like:
var arr = []; arr[1] = true;
arr[3.5] = false; // "works", .length is still 2
The intent is that array implementations may use efficient unboxed contiguous storage, but the spec requires that arrays may be sparse so it's still necessary to track which keys are actually set even if values are undefined.
Want to iterate an array's keys? There's no requirement that array indexes start at 0, and you may encounter random other keys from the array prototype.
Every time I see something like this, I stop and consider just how saner Lua is, even though in many ways it adopted similar approaches (e.g. associative arrays doubling as regular ones).
I think this [1] is one of the better references I've seen on this question. It's an analysis of bug-counts across Github projects. There's a correlation between number of lines of code and bugs. And there's a correlation between languages that favor simplicity and bugs. But there's not a a correlation between static typing and bugs.
So, I think we can say that you don't choose static typing in order to write fewer bugs.
I've worked in lots of code-bases, both static and non. Indeed, the bug rates are fairly consistent across them. The worst code bases I've seen (from a maintainability perspective) were actually old C++ and Visual Basic ones.
Refactoring is easier in statically typed code-bases. But, in my experience, it's not significantly better. What makes a bigger difference is immutability, functional purity (within reason) and a preference for obviousness (as opposed to, say Ruby-like magic which makes me pull my hair out on a semi-daily basis).
I tried typing functional programming library Ramda using TS, and got frustrated it still had some limitations (e.g. needing overload codegen in lieu of variadic support).
I tried finding what TS can do now, and figured out type-level tuple iteration, among a few others. The current roadblock seems to be getting function return types. Progress, for anyone interested:
https://github.com/Microsoft/TypeScript/issues/16392
At this point I'm amazed how close we are to typing anything, despite having only 5 (!) type-level operators, with their respective warts.
Gotta comment ... I dove into TypeScript about a year ago and dropped it. I saw the value but because of a large number of libraries and custom components of my own, switching purely to TypeScript wasn't easy and I was in a hurry.
Fast forward several months and I picked it up again. I've now been writing everything that I would have done in JS in TypeScript and have built several applications using both Angular and React entirely in TypeScript. I've also sold my teammates on switching to the language.
When I was (stuck) writing JavaScript, the frustration factor was high for me. I'd get nebulous errors[0], hunt around the line it referenced, swear a little, and trace the code back to the cause. I would wildly estimate that one out of ten attempts at blindly running my code would succeed[1]. Even on unit tests, which had a higher degree of success since they were testing much less, still had a much higher fall-over[2] rate than I get in typed languages that I enjoy. The addition of types, which adds a little overhead, flipped that over. I am still surprised every time I refresh a page that uses code I'm modifying and it loads. The reduction in time spent debugging (and swearing) makes me enjoy the language more every day that I use it. It's even left me longing when I am writing code in other languages (mostly Java/C# these days) and features I have come to really enjoy (union types, intersection types and to a lesser extent the duck-typing nature of the language[3]).
Since crapping on any language, or feature/lack of feature of a language tends to become a religious war fought with verbal violence, allow me to admit a few points: Traditionally, I avoided JavaScript and jobs related to it. Personally, I hate the language. This means I've spent considerably less time researching all of the best practices/techniques for surviving those cases where I have to write JavaScript. I started in C and Pascal and prior to a few months ago spent 99% of my time in typed languages. I am an advocate for unit testing[4], but I find test-driven development requires me to work backward and it's less productive for me. I'd imagine that if I went all in with TDD, I might see fewer of these problems, but many of the best practices for JS development are best practices in the languages I am more proficient in and despite following these practices, JS design led to these practices being less effective at reducing bug frequency. Yes, I could just be a yelling 'get off my lawn' because I'm unwilling to change[5]. But I've also worked closely with highly-skilled JS developers who could rapidly produce incredible things as a result of its flexible, dynamic typing. Incredibly, though, one of those 'huge JavaScript advocates' was the one who told me to give TypeScript a chance late last year. Though he would always fight me on the "dynamic vs. static" thing, his argument was that TypeScript's type system was light-weight enough to keep out of his way while strict enough to lower the frequency of self-inflicted foot bullet-holes (paraphrased). Really, though, ... two nulls, asinine boolean implicit conversions necessitating code like double-bang and === / !== operators[6] should be enough.
[0] Often depending on whatever framework I was using, but I've rarely found one that returns an error that results in a really obvious 'oh, I know what I did to cause that'
[1] I like to check that a component renders visually appropriately and often do a quick check before I've written all of the required unit/integration tests to make sure it's rendering accurately (right data/right result).
[2] As in, something fails badly enough to stop execution rather than just failing on an assert for an incorrect result.
[3] It's a love-hate thing for me -- the result is being able to reduce boilerplate making mostly-compatible types interact, but the down-side is that the compiler giving a pass to "A=B" when "A" has at the properties of "B" results in some subtle bugs that have already bitten me more than once.
[4] Though I don't buy into TDD (either before writing the code or after) solves most of the issues of dynamic typing. I've had more than a few tests fail because of a type-related issue...in the test.
[5] Except that I love learning new languages and 'keeping up' and have found that as I've aged, I can pick up new languages far more quickly than I could in my early 20s... [plug]RUST![/plug] I'm also not terribly old, nor terribly sensitive about being called an oldster.
[6] I don't recall who, but someone was once reading code out-loud and said "if action fuckin' equals 'ADD' and payload.Length doesn't fuckin' equal zero". Adding in the fuckin' every time he encountered the "really, really [not] equals" operator. So that is how I mentally read those. I'll never forgive him (sorry for the swears ... and doubly sorry if you end up reading code like this as a result).
upvote should be a global with capital letters. but writing it like that might be a leaky abstraction of the underlaying database storage. should the web dev really have to know that some variable is represented by a tinyint later converted to a float, then "optimized" to a 32 bit int !? why make it into a failure point when there is so little gain in performance and make little sence in a high level, lose typed language such as javascript. stop writing javascript like its java!
> Typescript also came with a lot of “social proof” and better assurances about its longevity There are several large projects using Typescript (examples include VSCode, Rxjs, Angular, and Typescript itself),
While I agree with the sentiment, I don't understand why they include "Typescript itself" in this list. Isn't that a circular argument?
Not really. It's direct proof that the language is good/fast enough that the people creating it chose it for themselves. The flow team, for example, wrote their language in ocaml.
Typescript as a project might be bigger than the rest. E.g. compared to flow the typescript repo has double the stars and quadruple the commits. If those metrics mean anything.
Agreed. I don't see the use case for Reddit to be a SPA. Given that it's a list of documents linked together, I can't see a better use case for a plain old static hypertext document.
> Should work on both the client and the server. SEO is very important to Reddit, so lack of universal rendering is a deal breaker.
Are client-side only JavaScript applications not handled well by the likes of Google et. al. today? I was under the impression that they run a full JS interpreter.
Its still nowhere as accurate nor as good SEO wise. It means you don't get zero SEO, but if you want to be at the top, you want to do everything you can.
I suppose I'll piggy-back this off your comment, since mine doesn't really deserve to stand at the top level, but I am also surprised this blog post can't stylise TypeScript correctly...
From what I know of the Reddit community and their feedback on anything any of these "new devs" have done, it's not going to matter how pretty, well-typed or "scalable" (whatever that means) the code is.
All the new product is just awful. I feel sorry for them.
Here at Streak with have 10s of thousands of lines of code written in Flow. Our main app and the InboxSDK are not open source but we do have some smaller open source libraries on our github. Check them out!
I thought it was an adorable font that made the comments read light and whimsical, but then again I shipped a product that used Comic Sans as its main font.
I had a very difficult time reading it as well, but then, I couldn't handwrite in cursive to save my life, so there's probably a correlation there.
I assumed this font was for marketing purposes only; regardless, I also assume that they let their devs customize their own IDEs look-and-feel, so to each their own.
It looks like there are at least 2 different fonts there. With different fonts used for different parts of the syntax. Which actually seems like a good idea, to further visually distinguish different things beyond just color. But to work right you need to choose fonts that are very visually different.
"We picked Typescript because this is what we feel everyone else is using and wow are we late to this party"
Take nothing away from TS but the mobile Reddit is all the proof in the world that no matter the language, the paradigm or the ecosystem, someone can still use it to turn out a horrible product.
Babylon merged TypeScript support yesterday [1]. This means that in the future it should be easier to setup Babel with TypeScript.
I agree with the decision to go with TypeScript. It has drastically better community support. Most third-party components won't have flow annotations. Flow would've been a lot more successful from the start if it had started out with DefinitelyTyped support. Heck, even now I'm still wondering why they don't do that.
[0] https://codemix.github.io/flow-runtime/#/
[1] https://github.com/babel/babylon/pull/523#issuecomment-31172...