Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing TypeScript 2.1

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

211–220 of 226 posts

Re: Announcing TypeScript 2.1

#211

Post by g00gler »

RyanCavanaugh wrote: post #85
g00gler wrote: post #23

Earlier quoted context omitted.

I have to second Mr.timruffles. After using TS in a couple of projects I grew to miss it when I couldn't use it. If you don't like the C#-ness of Typescript, try using Facebook's flow. Typing isn't a magic bullet, typescript isn't even type safe, but it sure makes development easier and your apps more stable.

Where do you perceive the C#-ness of TS coming from? TS and Flow are ~90% identical (most programs accepted by one would be accepted by the other) and TS adds only a few purely optional syntactic features (namespace, enum) that are widely found in other languages.

* Disclaimer: Correct me if I'm wrong, I haven't used flow extensively but I did check the docs.

One big thing is TypeScript classes are entirely different than standard JS classes. I guess you don't have to use them but it adds Abstract classes, interfaces and access control (eg private, protected vars).

Re: Announcing TypeScript 2.1

#212

Post by nojvek »

tomatsu wrote: post #51
nojvek wrote: post #21

Would be so cool if the js engines ignored types like python3. Then I could just write Typescript and run it on node/browser

That would work except for enums. That's the one simple thing the engine actually has to do.

JS should just really support enums. Its such a great feature of a core language.

I wonder if there is any ES proposal for enums.

Re: Announcing TypeScript 2.1

#213

Post by stcredzero »

klodolph wrote: post #160
stcredzero wrote: post #140

Earlier quoted context omitted.

There's definitely a spectrum between static and dynamic type systems The key word is spectrum. and plenty of people who identify with either camp. What does it mean when people take something that's actually a spectrum, then divide that into two opposing camps? Does this sort of activity generally get public discourse closer to the truth, or farther away from it? It usually does the latter, in my experience. Hopeful…

Honestly, I feel like I am on the receiving end of some moralizing here—when someone tells me that my language "brings public discourse farther away from the truth" I wonder how I could have offended them so deeply. The difference between a dichotomy and a spectrum is itself a false dichotomy. Ask any biologist what a species is, and they might stammer out some kind of weaselly definition full of hedges, and that sam…

Honestly, I feel like I am on the receiving end of some moralizing here—when someone tells me that my language "brings public discourse farther away from the truth" I wonder how I could have offended them so deeply.

Please re-read. I never said your programming language "brings public discourse farther away from the truth." Otherwise, please provide a quote. What I said is that some discussion about language "brings public discourse farther away from the truth."

I just re-read, and perhaps you are talking about human language. Also, no, I'm not offended. I'm just making an observation about how talking about things in a certain way can shape thought in non-beneficial ways.

Ask any biologist what a species is, and they might stammer out some kind of weaselly definition full of hedges, and that same biologist might turn around and publish a dichotomous key which tells you how to identify a particular species according to an easy set of rules. The same goes for politics, human sexuality, and yes, type systems.

When I encounter political discussions online, I sometimes have a person pattern-match something I've said, then declare all of my political beliefs for me. In those situations, false dichotomy -- or rather unawareness of the spectrum -- has distorted someone's thinking away from the truth.

I suspect this happens to Golang a lot. Basically, the Go language designers seem to be heavily into the Pareto Principle. So they are very willing to have a quite barebones level of tooling, and leave a lot of features out. This is especially true for their type system. They seem (to me) to have succeeded in getting most of the benefits of a type system while minimizing the disadvantages, while having much of the "feel" of a dynamic language, while also avoiding most of the downsides. It's a kind of pragmatic minimalism I've only encountered before in dynamic languages like Clojure, Lua, and Smalltalk.

Re: Announcing TypeScript 2.1

#214

Post by Noseshine »

whatever_dude wrote: post #204
Noseshine wrote: post #183

Earlier quoted context omitted.

Thank you!!! This is the one answer I was looking for. And it seems to be very recent, committed Nov 7 for 2.1: https://github.com/Microsoft/TypeScript/pull/12160/commits/7... Looking at the discussion on GitHub for the issue that lead to this commit I'm a little amazed at how much difficulty some people seem to have had with the simple concept. "Just pass it through without code changes, only remove type information…

I assume it's because "no code changes" implies you could potentially be creating something that doesn't run where you want it to. Modern JS development means you need to be aware of the EcmaScript version you're writing in , and the version you're targetting . Once you're aware of it, transpiling with TypeScript means you don't necessarily need to target `esnext`: if you write ES5 and target ES5, it'll just remove t…

  "no code changes" implies you could potentially be creating 
  something that doesn't run where you want it to.
Eh... I don't see how those arguments are possibly serious? Is this forced hand-holding of adult people truly your attitude? I deliberately select a non-default option. You (not directly you probably, but you chose to represent that POV) don't know anything about me or my situation. But immediately you start worrying about stuff you don't know anything about, that I might not know what I'm doing, might... could... possibly... hypothetically... Sorry, but this reply, or the attitude you presented which I know may not be your own, really pisses me off, to say it quite frankly. Don't even try to defend the forced(!) nanny attitude, even if you just tried to present what you think is other people's argument.

Re: Announcing TypeScript 2.1

#215

Post by woah »

edblarney wrote: post #148
woah wrote: post #131

Earlier quoted context omitted.

What OO does typescript have that js doesn't?

+ Member access private/protected + Static members (theoretically exist in JS, but much cleaner and 'compiler aware' in TS) + Interfaces When I write JS, I end up with closures within closures within closures. When I write TS, I find myself sticking to much cleaner abstraction. I end up (having to) create classes, and usually it's for the better.

A class is a pretty bad abstraction to try to fit the world into. It might work for some things, but it usually results in a lot of ceremony, and a lot of concepts in your program that exist only to service the abstraction. It's useful in JS for some special cases, but being forced into it is just going to make your code verbose and complicated for no reason. I'll stick to Flow for now.

Re: Announcing TypeScript 2.1

#216

Post by taspeotis »

mattmanser wrote: post #208
taspeotis wrote: post #197

Earlier quoted context omitted.

> There is no performance gain for most people using async/await, at all. That's simply not how it works. You have to be in a specific scenario, high load on the server's resources, not the DB, to see any benefit. If you have two asynchronous things to do, and they are unrelated, start them both and then await Task.WhenAll(file1Download, file2Download) . Look at the wall clock - it's up to twice as fast. Look ma, no…

Not a lot of things need to access two files at once. You and I both know virtually all await/asyncs are doing a singular one thing like DB or emailing or a single file access. So why bring it up? And as for your condescending "Blocking operations ... block", talk about missing my entire point. IIS is the victorian sewer, your code is the hose. IIS has many threads available to it, that's my entire point. You don't n…

I make plenty use of async requests to get files (images) and make web service calls at the same time. It's a Xamarin mobile application. Mobile apps are sometimes constrained by latency, so having a few requests in flight at once speeds things up.

Performance is not just fewer CPU cycles.

> IIS has many threads available to it, that's my entire point

My web services run on a VM with four cores. That's what I get given, and there's another twenty websites on it. The less overhead my code has the better. Just because it's not 100K TPS doesn't mean there aren't benefits.

Re: Announcing TypeScript 2.1

#217

Post by eropple »

polskibus wrote: post #137
eropple wrote: post #55

Earlier quoted context omitted.

So this is totally a hack, but have you tried changing the manifest in the VSIX (it's just a zip file) and seeing if it installs?

The official installer seems to be an exe, not a vsix, moreover VS2015 requires update 3 so there's probably more to it than just a manifest hack.

Ah, bummer. Just a thought. =(

Re: Announcing TypeScript 2.1

#218

Post by jiaweihli »

Noseshine wrote: post #190
jiaweihli wrote: post #111

Earlier quoted context omitted.

Very early on, Typescript cleverly built up an ecosystem around community-supported type definitions for popular js libraries. This makes type-checking and integration for those libraries dead simple. 2 years later, Flow is _still_ lagging behind in this area. [1] I'm not certain, but I think this may be due to Typescript allowing for a external header-like file while Flow requires inline types. For this reason I bel…

I don't understand what you mean by this may be due to Typescript allowing for a external header-like file while Flow requires inline types. Flow supports external declaration files. I use them all the time for 3rd party modules.

You're right, this has been added recently and there's also now a community effort around 3rd party modules. [1]

Though it looks like it didn't become active until after at least 03/2016 [2].

I mention this only because TypeScript has been active in this area since 10/2012 [3], which is in-line with the original intent of my comment - that Flow is over 2 years (closer to 3.5 years) behind in building this out.

[1] https://github.com/flowtype/flow-typed

[2] https://github.com/flowtype/flow-typed/graphs/contributors

[3] https://github.com/DefinitelyTyped/DefinitelyTyped/graphs/co...

Re: Announcing TypeScript 2.1

#219

Post by whatever_dude »

Noseshine wrote: post #214
whatever_dude wrote: post #204

Earlier quoted context omitted.

I assume it's because "no code changes" implies you could potentially be creating something that doesn't run where you want it to. Modern JS development means you need to be aware of the EcmaScript version you're writing in , and the version you're targetting . Once you're aware of it, transpiling with TypeScript means you don't necessarily need to target `esnext`: if you write ES5 and target ES5, it'll just remove t…

"no code changes" implies you could potentially be creating something that doesn't run where you want it to. Eh... I don't see how those arguments are possibly serious? Is this forced hand-holding of adult people truly your attitude? I deliberately select a non-default option. You (not directly you probably, but you chose to represent that POV) don't know anything about me or my situation. But immediately you start w…

"You" in my comment means a hypothetical person who could be doing the changes. It wasn't directed at you personally, since it's obvious I know nothing about your context or environment.

I'll be more careful about writing "one" instead of "you" next time.

Re: Announcing TypeScript 2.1

#220

Post by jiaweihli »

jtmarmon wrote: post #143
sixbrx wrote: post #134

Earlier quoted context omitted.

One thing you might miss in TS is the ability to just try to check or cast an object at run-time to check that it's really of some nominal type, or structurally compatible with some type/interface. TS can't do that because it doesn't have runtime type information for its types - the types are a compile-time only thing. TS does allow creating functions that return type predicates, but that requires your own manual che…

ahh interesting, that seems like a pretty significant difference. just to clarify, this means that you wouldn't be able to do things like: if (my_var instance_of MyCustomType) in TS, but you could in normal statically typed languages, correct?

As long as you're not doing type casting or any funny reflection, you can write that code and it'll be caught at compile-time.

I wrote a library [1] that does this in a readable pattern-matching way, hope you find it useful!

[1] https://github.com/jiaweihli/rematch

Post reply on HN