TypeScript 3.6
devblogs.microsoft.com
devblogs.microsoft.com
Yes it takes me "slightly" longer to write code initially, but that time is recouped almost straight away by the intellisense suggestions, refactoring, and code checking. My code often "just works" the first or second time.
Therefore after using Typescript for a couple of projects, I was excited to start adding type hints into our backend Python code, but I was quite disappointed by the value that they added. Perhaps I'd just become spoilt by Typescript.
Disclaimer: I have not used MyPy. I'm just interested.
In the latter they don't enforce much, you just get a JS or regular Python file. (mypy is not a transpiler like TS, mostly because it explicitly wants to be able to target legacy JS runtimes - eg IE8 ES5 - whereas mypy needs a recent Python that supports type annotations)
There's a reason why strong static typeable code looks the way it looks (basically functional programming). You can type a monad chain, because it's a container type for arbitrary types interacting, but you can't easily type a switch nested in a for loop that uses a queue to walk a tree.
Of course the flip side is that to walk a tree functionally you need recursion schemas, and they are ugly/complex.
On the implementation side, I've found TypeScript's type inference to be far more capable. I've encountered several mypy bugs around type narrowing. The issues I've filed have greeted by a "yeah, this is a problem, but low priority since you can restructure your code to make it more explicit." I understand staffing is an issue for community projects, and the PSF is trying to do a lot with very little, but that doesn't change the fact that it's a deficiency when compared to other systems.
* it doesn't track the state of the variable. If I get a value thats Optional[int] there is no way to say 'if a is not None:' it will still complain that the variable could be none
* even with the mypy experimental TypedDict they're basically unusable IMO
* there is no 'keyof' Coming from typescript it's been very lackluster.
- TypedDict is an option but if you can, dataclasses work much better
- mypy does refine Optional[T] to T with an if check. Maybe you need to futz with the compiler options?
- Does Literal["foo"] not work? I've been using it with pydantic for de-serializing a tagged union of dicts and also for function args.
e.g.,
def call_to_service(api_type: Literal["users", "teams", "orgs") -> None: ...I think you're right, something must be mixed up. But then again this is the latest version of python and mypy, on intellij, so I'm not sure what I did wrong, it's using otherwise default options.
On point 1: def use_int(n: int): return n * 2
def foo(n: Optional[int]):
use_int(n) # MYPY complaints here because n could be None
if n is not None:
use_int(n) #MYPY allows this because it understood it cannot be None
Accepted = Literal["foo", "bar", 3]
def accept_values(v: Accepted):
print(v)
accept_values("foo")
accept_values("bar")
accept_values(3)
accept_values("wrong") # MYPY complains
accept_values(5) # MYPY complainsFrom the points you make it seem like you haven't really figured out how to use mypy...
TS and Python/Mypy are my daily drivers. I don't find the experience working with mypy any worse than working with TS. In fact I prefer composing and consuming types via dataclasses and NamedTuples over interfaces and TS classes.
type Animal =
{
type: "Dog"
dogtag: string
name: string
} | {
type: "Cat"
name: string
allowedOutside: boolean
}
function f(a: Animal) {
console.log(a.name) // always allowed
console.log(a.dogtag) // compile error
if(a.type === "Dog") {
console.log(a.dogtag) // Allowed
}
}
from typing import Union
class Dog:
dogtag: str
name: str
class Cat:
name: str
allowedOutside: bool
Animal = Union[Cat, Dog]
def do(a: Animal):
print(a.name) # Always allowed
print(a.dogtag) # MYPY error
if isinstance(a, Dog):
print(a.dogtag) # MYPY allowsBut the fact you have to import Union instead of using a pipe bothers me. It's useless boilerplate and verbose. So not o Python. I reported it, but Guido told me it will not happen.
And I have to agree with him. Just look at the mess sclalaz did/does with its use of clever pictogram-like symbol names.
Python is very much a language where newcomers are the norm. Make the source code at least a bit self-teaching seems like a good feature.
I'm sorry but "|" is not only a very commonly known operator in the entire programming world, it is already an officially supported operator by python, vastly used by the community for doing unions: sets use it, sqlalchemy use it, pandas use it.
Let's not confuse explicite and paperwork.
The Typescript docs have more details and advantages for this specific scenario: https://www.typescriptlang.org/docs/handbook/advanced-types....
Ref Link :- https://www.typescriptlang.org/docs/handbook/advanced-types....
Some people are choosing node at backend just because how good typescript is.
interface IntMap {
[name: string]: int
}
interface StringMap {
[name: string]: string
}
type IntMap = Record<string, int>;
type StringMap = Record<string, string>;Interface ObjMap<T> = {[name: string]: T}
And the use it as const intMap: ObjMap<int> and voila!
After working with it for a while, the type checker ends up being painful to work with. I'm using React, and it's difficult to write higher order components that are correctly typed. Additionally, probably related, styled components often get messed up with the type system.
However it's a godsend for nodejs.
There's even a specific one on how to type HOCs: https://github.com/typescript-cheatsheets/react-typescript-c...
TypeScript adds negative value overall once you consider real use cases. Eventually everyone is going to have experienced issues with incompatible dependencies, outdated type definitions, incompatible TS version config settings, incompatibility issues with bundling tools, source mapping issues, monorepo issues, issues related to debugging in a deployment environment.
I think that the biggest problem with TypeScript though is that it gives a false sense of high code quality which actually makes the real code quality and architecture a lot worse. With code completion and the ability to jump around the code very easily, TS makes it easy to keep track of classes and type definitions over many files without having to actually think about the class hierarchy or file and folder structure but this is a short term approach and leads to significant long term issues.
Here's a [comparison of Haxe and TypeScript](https://blog.onthewings.net/2015/08/05/typescript-vs-haxe/).
I think a list of highly adopted libraries written in TS would be great. One I recently realized was TS is immutable.js!
TypeScript is a strict superset of JavaScript, so all our real-world JavaScript is TypeScript already — you can literally just change the file extension from .js to .ts.
Now, our existing JS code probably isn't great TypeScript, since it doesn't leverage those great machine-and-human-readable docs (the type system).
So, compared to code written from the beginning with TypeScript, our existing code doesn't go as far toward reducing the likelihood that we humans miss something while programming, and introduce a bug. And we probably won't get all the automated assistance that we could be getting from our machines, in terms of auto-complete, as-you-type errors and warnings, automatic imports, etc.
But for projects coming from JavaScript, it's hard to overstate the importance of being able to start from a place where all your existing code works like it always has, and you can choose the right mix of when/if to upgrade your legacy JavaScript code to TypeScript.
I think that design decision is probably the key to TypeScript's explosive adoption and popularity. A lot of languages could give you strong typing, and the increased code correctness and massively improved tooling that comes along with that — but I don't know of any others that literally require no code changes to start adopting them.
Of course, the choice to remain a superset of JavaScript does place some significant limitations on what kinds of cool improvements TypeScript can add. It can't break JavaScript code so lots of cool things one might imagine won't be possible. Still, a great tradeoff IMO.
I had the impression this has been debunked already.
There may be some cases like that (though I've never seen one in the real world, since I started working with TypeScript three years ago). And there have been and will be more bugs in TypeScript and its compiler, etc.
Such claims might be true in some pedantic sense, but aren't really meaningful unless you are in some kind of internet flame-war thread on Reddit or something.
In the real world, for the purposes of writing software, Microsoft's claim[1] that "TypeScript is a typed superset of JavaScript" is generally true.
[1]: https://www.typescriptlang.org
EDIT: Maybe I shouldn't have said "strict" superset. That might have just been me accidentally editorializing.
EDIT 2: After reading the post you linked, and its (good) comment thread, I understand where he was coming from, but as he notes in his update at the top, it mainly boils down to different interpretations of what "superset" means in this case. I think in the end his assessment is the same as mine above.
I'm sincerely asking, why are you excited for Microsoft? It seems like you're cheering for them, and I'd like to understand where this excitement comes from.
Is it like a sports thing where you're rooting for team MS vs Mac or something? If MS gets bigger and dominates more, what's in it for you?
I think "and from microsoft!?" would be one way to do that clearly. Not that it matters.
It's joy. Just, joy.
With dynamic typing, you don't get the immediate feedback of breaks when making frequent changes. You don't get the safety of automatic refactoring. You don't get auto-complete and easy of discovery of APIs.
I really don't understand the idea behind dynamic typing being better for prototyping unless that "prototype" is only a few lines long.
However I think it’s important to have used both for a while so you can make a good decision what you prefer.
Even though I seem to be in the “intelligent” camp by your definition.
Exactly, I always found static typing to be annoying clutter and Python seemed to work even at scale. I removed the few type hints the codebase had.
Then I had to spend a year in C# professionally. At the end, I was fine with both, no preference. Then I jumped back into our Python and only then realized the utility of typing - it felt chaotic, my (IntelliJ) IDE was no longer helping me and every time I had Prod type related bug, it feeling dumb.
Ended up type hinting the critical parts of the Python.
I think of it as "I don't care what the type is, but I also shouldn't be able to do anything with it"
All things being equal I prefer something like Haskell because it is very clean and expressive. But I hate excessive types when you are dealing with generics 3 level deep or when you have these funky type signatures dealing with monad transformers. It's just too many layers of abstraction that takes you away from the actual data / parameters.
When I'm writing something small I find typing slows me down. But when writing something bigger, working in a team, or working on a codebase for a longer period of time the typing acts as documentation. Typing something and having Intellisense tell you what is in a class is extremely helpful. Otherwise you have to jump to the file or look through documentation.
For me it's less about the errors it catches and more about the time saving of not having to read through code that I am calling in order to understand what I need to pass to it.
In general. strong typing is great when you are working with other people's code and 3rd party libraries, but excessive overhead when you just want to experiment and crank out something small.
For static-lovers, the idea of "just fix it if it breaks in production" is horrible. For dynamic-lovers, the idea of "spend time on work which doesn't get you closer to solving the problem" is essentially wasted effort. (Static-types are 'meta' code; the equivalent program works just as well without the types declared).
I've heard a good strategy is that the first-iteration should be dynamic (this gets the problem solved quickly), and static typing is good for further iterations (static-typing is better at conserving what's there).
This is a huge problem with front-end. Too many people who don't know what they don't know, and think their use case is the only one.
Given that you have a good system for monitoring errors in production and a low friction deploy process so you can quickly and easily fix errors when you discover them, I feel these kinds of errors are honestly not worth guarding against in most contexts outside of those where getting everything perfectly right the first time is a hard requirement (health, fintech, other safety-critical industries, etc).
Of course, most companies lack either or both of these ( a good system for monitoring errors in production and a low friction deploy process), so they use static typing as a clutch to try to reduce the chance of errors making it into prod simply because they know they'd be slow to fix/detect those errors. That's a poor reason to choose static typing IMO, but I think that's by far the most common reason.
Whether or not that delta is worthwhile compared to a dynamically typed codebase with a well-optimized deployment/error detection system is not always clear however. Especially considering the costs of a static type system in limiting expressiveness compared to dynamic code and the mental overhead required when building abstractions that require layers upon layers of generics and higher order types to fully specify statically (library authors probably feel this pain the most).
I'd encourage you to keep your mind open to it's potential benefits as I've felt it has been a truly transformative experience that I'd like others to share.
It's also common to encounter errors in production that are difficult to reproduce in the development environment, this is especially true of data-type errors in dynamic languages where some unusual edge case creates a strange data structure that would simply be impossible with static types.
There's also a chance that the developer fixing the code didn't actually fix it and instead only introduced enough guard logic to handle that one specific case based on their best guess regarding the shape of data that can come through, thus redeploying with a 30% error rate instead of a 60% one, repeating the cycle of attrition testing against the production environment until the error rate is "noise" but maybe not completely fixed.
Now I avoid using regular JavaScript.
I'm impressed how many bugs it prevents, and it prevents them early.
Refactoring in TypeScript is literally magnitudes easier and quicker.
Such arrogance.. ..and unfortunately so typical for TS proponents..
Sure but unless you have coverage of all error cases, it’s nice to have that check at build time vs some untested corner case in production.
> Given that you have a good system for monitoring errors in production ...
Runtime errors are a totally different beast.
> ... and a low friction deploy process so you can quickly and easily fix errors when you discover them, I feel these kinds of errors are honestly not worth guarding against in most contexts outside of those where getting everything perfectly right the first time is a hard requirement (health, fintech, other safety-critical industries, etc). Of course, most companies lack either or both of these ( a good system for monitoring errors in production and a low friction deploy process), so they use static typing as a clutch to try to reduce the chance of errors making it into prod simply because they know they'd be slow to fix/detect those errors. That's a poor reason to choose static typing IMO, but I think that's by far the most common reason.
Fixing things earlier is cost effective regardless of your deploy speed. Sure it’s worth more the longer the cycle, but not having to run unit tests because the compiler knows “foo” is not “fo0” saves time as well.
I'm not saying detecting errors earlier through static typing has no value of course. Just that there is a spectrum of value a team can derive from static typing that scales based on the length of their deploy and error detection cycle, and at the lower ends of that scale it's not always clear that static typing provides enough of value to justify its costs.
And that if a team doesn't already have them, investing to minimize the deployment and error detection cycle is often much more valuable than investing in static typing because it's an effective tool for both dealing with runtime errors as well as errors that could have been statically determined.
For a small team full of talented engineers (e.g. a startup) it's not unreasonable at all to just... not make typing errors. I've put 5+ large apps into production in the last decade and could probably count on one hand the number of times I've really struggled with something type related.
There's certain anti-patterns that make up the majority of type-related problems in JS. Things like inconsistently mix 'n matching falsey types, adding or removing properties from objects in unpredictable ways, or leaking stringified numbers and bools everywhere.
Other classes of type problems can be solved in dynamic languages by structuring code in more self-documenting ways and properly augmenting any remaining ambiguity with comments.
If your team is naturally coding in a way that respects the dynamic typing of the language then your benefits from TS are going to be much more marginal, and that needs to be taken into account when comparing the costs and benefits of it.
My guess is that we'll see a harder split in the JS community in the next few years. Most people are going to drift towards only taking on TS or JS roles in much the same way most JS programmers wouldn't take a lisp or C# job at the moment.
This is one of the advantages of typescript over a language like clojurescript.
If you're really dynamic, the type of company won't matter, right :)
You can disagree but:
> Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust.
http://www.faqs.org/docs/artu/ch01s06.html#id2878263
Statically and strongly typed languages excel exactly at this.
If you opted to forego static typing, every step of the above function would require you to validate that you're dealing with the types you think you are. This kind of example isn't even at all uncommon.
In a large codebase, having typings, even basic ones, go a long way.
I don't know about the term static typing or if that's what really helps. I also annotate for readabilities sake. For instance, it's nice to know a variable in python is only intended to be 'ACTIVE' or 'INACTIVE':
from typing_extensions import Literal
ActivityStateLiteral = Literal['ACTIVE', 'INACTIVE']
# Lower in the code, e.g. inside a flask view
activity_state = ActivityStateLiteral = request.GET.get('activityState')
type ActivityStateLiteral = 'ACTIVE' | 'INACTIVE'
// e.g. react component
const activityState: ActivityStateLiteral = props.activityState || 'ACTIVE'
If I wasn't aware of valid values, I might search my codebase for uses of it. Usually if something is being set to true or false, it's a variable that can be true or false, or true, false, or empty (None in python, null or undefined in JavaScript).
Typescript has proper enumerated types, so you really shouldn't be using either? Using magic number values for an enum is even poor programming practice in C. You've already listed one reason why you'd use a proper enumerated type over boolean, the fact that NULL is not part of the type's domain. The other big reason is that it is semantically correct. You can limit the type's domain to only values that make sense semantically. No more comments like: // A value of '1' means the missile is armed.
Have you considered thinking of static typing as a tool? A kind of ESLint on steroids. The great thing about typescript (or checking JS with the typescript compiler) is that you can set the dynamic/static continuum anywhere you want, pretty much.
I don't have enough TypeScript experience; but from what I've seen, it comes pretty close to providing tools without mandating use and help where it can in the same spirit as Common Lisp.
I guess if your company mandates checking all boxes, which unfortunately seems bound to happen sooner or later, that doesn't help; but it's hardly TypeScript's fault.
The various Haskell-ish web languages popping up all over the place though, that's a different story. I wouldn't touch those with a ten foot pole. I'm so done with academic hoops.
The generator improvements are appreciated, though I wish it went even further and supported uses like redux-saga better (so the return type of a yield expression could depend on the type of the value that was yielded).
But fortunately, atleast in this particular case the usage semantics are really close to async/await so I have had success using a babel macro [2][3] to transform async functions to generators which restores type-safety. This is of-course a hack but has proven to work fairly well in practice.
[1] https://github.com/mobxjs/mobx-state-tree
Where did you learn it's scheduled for 3.7?
It's interesting that you don't have this problem with Java, is it because Java always has types, while TS is lenient?
Regarding your syntax criticism: I quite agree. I really really like the path chosen by Haskell. Types are obviously a major part of Haskell, but there you just separate the type signature from the implementation.
emap :: (DynGraph gr) => (b -> c) -> gr a b -> gr a c
emap f = gmap (\(p,v,l,s)->(map1 f p,v,l,map1 f s))
where
map1 g = map (first g)
type UPath = [UNode][1]: http://hackage.haskell.org/package/fgl-5.7.0.1/docs/Data-Gra...
I'm really enjoying this setup, I get to use tools that work on JS source code without sticking them in a build typeline. I find it easier to read as well - the function declarations are nice and short as all the type annotations are in a comment above. Also one less transpilation step.
Rather than having the TypeScript compiler not even transpile code into JavaScript unless it perfectly passes type-checking, I use Babel to transpile and run the TypeScript type-checker separately (with the `--noEmit` flag).
We just mandated that all new code get written in typescript (we transitioned everything to run via `ts-node` before actually using any typescript and it was super painless). Any "significant" changes to existing code (>= 10 lines diff usually) must either first convert the code to TS or add types via tsdoc. This is a "first step" PR that lets us confidently make changes in subsequent PRs after type info is there to help. Forces us to pay down tech-debt in a real way that has immediate payback.
But having runnable code without a build step is definitely a very big plus for me.
/** @param {(x: X) => Y} f */
I ended up doing this instead:
/**
@typedef {{x: string}} FooArgs
@typedef {{y: string}} FooResult
@type {function(FooArgs): FooResult}
*/
export const foo = ({x}) => ({y: x});
/*::
type FooArgs = {x: string};
type FooResult = {y: string};
type Foo = (FooArgs) => FooResult;
*/
export const foo /*: Foo */ = ({x}) => ({y: x});
With TS, RORO ends up looking like Flow (but with weirder indentation on large enough structs), whereas I'd prefer to express regular functions in terms of @callback, @param and @returns since that's more in line w/ the spirit of jsdoc. Not a huge deal, in any case, considering the upsides of comment syntax.
type FooArgs = {x: string}
type FooResult = {y: string}
type Foo = (_: FooArgs) => FooResult
/// <reference path="index.d.ts"/>
/** @type {Foo} */
export const foo = ({x}) => ({y: x})
Chrome DevTools uses Closure compiler directly, but also via jsdoc. In fact, the TS team uses chrome devtools as a test case to validate their jsdoc interop: https://github.com/microsoft/TypeScript/tree/master/tests/ca...
Its in quite a bad state with regard to how you have to structure the code to ensure Typescript doesn't throw linting errors (and even then I found the intellisense gained was not much more powerful than what my IDE already provides).
My conclusion has been that TypeScript maybe great for extremely large frontend apps, where you want to do a lot of data wrangling on the client itself (with defined Entities etc...).
Kind of a shame really since I'm using .NET core on the backend and loving it
Can you expand on this?
I currently write my apps in .net core/Vue/Typescript and use the same stack for small or large so I might be able to assist
TS is a must for long-term code which should be maintainable in several years by teams. Any lead engineer with responsibility for some crucial app and dev team not using TS is doing something wrong. But using TS comes at a cost. Even when you are savvy in TS you won't bang out code like with pure JS.
But especially in prototyping phases you need this fast-paced coding. And using TS or any type system slows you down, even when you are familiar with typed languages. Often your final code faced many iterations and I sometimes like to introduce TS later, usually at a point where I just need types but not always and as default from the first key press. In early stages I still try to test ideas, algorithms and their general feasibility and a fast 'mind-to-code' interface is crucial and types would stay in the way then.
Further, finding the right type can take some time, just google what type a React's children prop should be and find long discussions. Welcome to the TS-what-type-is-actually-xy-rabbit-hole. And declaring everything as any shouldn't be the answer.
A big drawback are also TS error messages which are super hard to grasp. You get there and you even find tutorials just for understanding TS error messages but it's unecessarily infuriating.
Moreover, VSCode, its TS language server are amazing pieces of tech but here you face also strange behaviours. Types get full Intellisense support while interfaces don't which doesn't make sense. So you need still to go the definition yourself and it's not that IDE-like feeling you hoped for or people told you.
In my setups, I use TS instead of Babel but use both JS and TS files in one code base depending on the requirements and situation.
So, my message is, yes TS is great, has probably the best type system but the tonality by its community/users needs to be much more balanced and less fanboy-ish. I just can't take devs serious who praise TS to death. This is just not true. More, maintainable code is also not just created by a type system but also sane architectures (eg React) and many other factors. Types won't make bad code maintainable. So, types have their place but not everything in TS-land is shiny.
A lot of it is due to the project's overwhelming priority being as easy to interop with JS as possible, but I've found that quite a few of TypeScript's fancier features are sugar that's entirely up to the developer to enforce.
Obviously the compatibility with JS is TypeScript's "killer feature", but it's a killer feature that has very explicit costs you're ignoring for some reason. You cannot have a truly excellent type system while trying to maintain the level of compatibility with a dynamic, weakly typed language that TypeScript does, something that the language team acknowledges themselves[0]. I don't quite see how one can call a deliberately unsound type system "the best".
0: https://www.typescriptlang.org/docs/handbook/type-compatibil...
Whereas if you were to use Angular there the types help you.
Or, if you do something in Android with Kotlin, the types are very helpful. Quick auto complete and instant sanity checking of the code.
No oops cannot call method on undefined. I found that was what took a lot of time for me when I used plain JS.
Furthermore using mixed codebases make things really slow, because then either you need to disable strict mode, or you need to provide typings for at the interface of the TS JS files.
Again, this is probably very much path dependent. If you use a lot of strongly typed things for years, then you'll be fast in that. Just two days ago a colleague helped me with some Scala, and we ended up with a few lines of EitherT monad transformers that helped type some code involving Future and HttpResult types. I felt the exact same "figuring out the types takes too long" on my own, so I initially went with less functional Scala.
So the same/similar problems (like typing React and Redux) exists in other languages as well, and for some folks it's nothing, because they are very accustomed to that kind of thinking.
Not really true and guess you misunderstood me and are not on the latest state of things. You can perfectly use the TS compiler as the compiler for your JSX code. Then you can decide case by case when to use TSX or not. and many major libs (mobx, formik) are written in TS and perfectly support TS.
I'd disagree with you statement that long usage of a typed language makes you faster. It is about choosing the right tools and static typing ist not always the right answer. But this is exactly what annoys me: the urge to evangilize everyone with static typing.
I also tend to use js-cookie and uri.js because the browser has horrible APIs for working with cookies and urls.
Why not create a beautiful statically typed language from scratch that compiles to WebAssembly? Why do we have to introduce a type system on top of an old and flawed language? I mean, maybe you'll get some type safety with TS, although it won't be 100%, but what about the future? How long will this toy technology stay?
For me, this is so typical for the JS community, jumping the boat in a whim. And IMHO this creates the famous Javascript fatigue. Learning disposable things. Therefore I moved back to C++ after 6 years of web development, learning things that actually make sense and that I can use for years to come. Not having to work with all those temporary black boxes that are praised by the community.
This is Microsoft's product, the company famous for keeping legacy going, hardly the 'JS community'
Makes it easier to see what all options are available in TSC.
Am I doing something dumb?
Finally, a release notes that explains what the product is!
Y'know, I can't think of many companies that have as much support for open source programming language development. Between Roslyn, TypeScript, what's left of F#, the Language Server Protocol, Chakra, V8, etc., Microsoft has a veritable powerhouse of compilers and PL development. Google has Go and Dart, but as far as I can tell, the development process is contained in Google mailing lists. Apple has Swift and LLVM and Mozilla has Rust, but each of those footprints isn't as large as the combo of .NET and TypeScript.
I mean, ffs, Richard Stallman is coming to speak at Microsoft. Well, Microsoft Research. But still. Stallman. That's insane.
Wait, what? That's very interesting.
I love Microsoft's language tools (TS, Vs Code, C#, LSP, ...) and I used to work on Azure, but I'm still very skeptical. For these 3 reasons:
1. https://en.wikipedia.org/wiki/Open_Letter_to_Hobbyists 2. https://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_... 3. http://techrights.org/2009/06/25/bill-gates-office-patents/
Until BillG himself comes out and says Intellectual Slavery laws should be changed, I won't fully trust MSFT's long term motives here.
I do use TS, and it's enabled me to have a bit more peace of mind than I might otherwise have. It's also totally wrecked projects before (Loopback + TS = "as any" * 1000).
In any case, the sun could shine out Microsofts ass and I'd still be skeptical of them. Windows has an abhorrent amount of code smell to it, and (as stated) I haven't heard good things about working there. Really would rather they weren't any more of a mega corp than they already are. Really don't trust them. But TS is nice.
Microsoft Welcomes Richard Stallman (2005) http://suseroot.com/rms.php
Has it been abandoned? What did you mean by this?
Its good as it is anyway.
The most striking difference is that OCaml has the ML module system, where you can have functions from modules to modules. F# doesn't.
Recent versions of OCaml now have features like first-class modules and binding operators. AFAIK F# has not added them.
On the other hand, F# has features that OCaml doesn't, such as computation expressions, strongly typed units of measure, and active patterns.
As for BuckleScript, I wish that it had better integration with the main OCaml ecosystem. BuckleScript is supposed to work well with NPM, but I am more interested in OPAM. I personally use js_of_ocaml, a compiler to JavaScript that works well with the OCaml tooling.
If Reason and BuckleScript can bring more people to OCaml, then I'm glad. However, I perceive that the people coming to OCaml with BuckleScript seem to be making libraries based around the NPM ecosystem. I feel worried that a separate OCaml ecosystem will come into existence. However, I have not observed any other OCamller voice these thoughts, so I'm probably alone or misinformed here. I'm not too knowledgeable about the JavaScript trends.
Your comment refers to me as an "OCaml person." Please know that these opinions are my own and do not in any way represent the collective OCaml community's opinion on Reason and BuckleScript.
We have `let` operators instead.
And F# doesn't have proper overloading, it has an SML-like hack working for built-in types only, and only within a function, as far as I understand. It needs typeclasses for proper overloading. There is an ongoing work on Modular Implicits for proper overloading (and even dependent types in core language), but they are not there yet.
Or type providers in .NET Core.
Visual Studio 2017 has even been released with critical bugs in F# tooling, as they weren't considered as show stopper.
In regards to VB.NET and C#, it certainly feels like second class, and occasionally even C++/CLI gets more love.
Regarding the topic: I really love what TypeScript has done and where it is today. I wish more people would adopt it or at least support it with proper definition files. I mean there is DefinitelyTyped.org but it has its flaws. Unless it's not a first class language like within Angular I still find it somewhat hard to work with it because of interoperability with plain JS libraries, which always ends in some trade-offs.
If so I remember that being a thing (potential licensing issues with the megacorp subsidiary that bottled it) so we dumped the bottle and filled it with tap to be on the safe side. Technically he didn't pay a dime and in the end it was us paying the company for the bottle and the venue (not Richard) who swallows the cost of the water and it's delivery as a utility.
At the time I was of the opinion we over-thought it a bit and involving a $100/hr lawyer was crazy. Turns out my manager was right when she said "Alexander Dmitri, I say this to you: Never under-estimate the people who might try to call this ridiculous stuff out to detract. The haters must be met with diligence."
https://en.wikipedia.org/wiki/V8_(JavaScript_engine)
Seems google does a lot of opensource stuff as well.