News for hackers. Stuff that matters.
Re:Why We Chose Typescript by fny on Saturday July 01, 2017 @01:02AM (#14675476)
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.

Re:Why We Chose Typescript by jstimpfle on Saturday July 01, 2017 @06:24AM (#14676411)
> You can define mix-typed maps without a sweat: const defaults = { debug: false, title: 'Banana', width: 100 }

That's called a struct (or class) elsewhere.

Re:Why We Chose Typescript by fny on Saturday July 01, 2017 @09:28AM (#14677020)
An instance of mixed-type maps*

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.

Re:Why We Chose Typescript by resf on Saturday July 01, 2017 @08:46AM (#14676877)
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)
Re:Why We Chose Typescript by jstimpfle on Saturday July 01, 2017 @09:24AM (#14677007)
What I wanted to point out is that typically a C struct is what you need. The common case is static keys and static value types but dynamic values.

What are interesting use cases for more dynamic (i.e. non-fixed set of keys / types)?

I mean, if you need something super-abstract and flexible, you are unlikely to need a built-in convenient syntax to hardcode such values.

Re:Why We Chose Typescript by mrkgnao on Saturday July 01, 2017 @01:43PM (#14678047)
, yes Purescript :)

For those new to this, good search terms are "row polymorphism", "extensible records", and "polymorphic variants".

Re:Why We Chose Typescript by mrkgnao on Saturday July 01, 2017 @04:38AM (#14676079)
> infer recursive functions

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).

Re:Why We Chose Typescript by fny on Saturday July 01, 2017 @09:41AM (#14677062)
I've tried in Rust, and it requires a return definition, as do most mainstream functional languages.

Also, mainstream functional languages aren't truly mainstream: I'd struggle to find devs who could help me in consulting gigs.

Re:Why We Chose Typescript by mrkgnao on Saturday July 01, 2017 @12:51PM (#14677827)
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.
Re:Why We Chose Typescript by steveklabnik on Saturday July 01, 2017 @01:10PM (#14677903)
It was a design decision, yes. We could infer them if we wanted to, but we don't.
Re:Why We Chose Typescript by igouy on Saturday July 01, 2017 @12:40PM (#14677786)

    let rec factorial n = 
        if n = 0 || n = 1 then 1 
        else n * factorial (n - 1)
F#
Re:Why We Chose Typescript by mrkgnao on Saturday July 01, 2017 @12:50PM (#14677820)
Haskell:

  factorial n =
    if n < 2 
      then 1
      else n * factorial (n - 1)
I think the OCaml version will look almost exactly like the F# one.
Re:Why We Chose Typescript by igouy on Saturday July 01, 2017 @12:38PM (#14677778)
>> The only language I've ever used that can infer recursive functions <<

You don't need to have used other languages to see there's no problem -- just Google -- haskell recursive factorial type inference

Re:Why We Chose Typescript by oskbor on Saturday July 01, 2017 @03:20AM (#14675849)
Where can I find more info on the upcoming regex types?
Re:Why We Chose Typescript by fny on Saturday July 01, 2017 @04:33AM (#14676060)
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. ;)

[0]: https://github.com/Microsoft/TypeScript/issues/6579