TypeScript 3.6(devblogs.microsoft.com)
devblogs.microsoft.com
TypeScript 3.6
https://devblogs.microsoft.com/typescript/announcing-typescript-3-6/
210 comments
Yes, Python's type system is nowhere near Typescript, and are closer to docblock annotations.
How? How it's not close to typescript? I mean what are features that python's type annotation (and mypy) lacks in comparison to typescript?
Was battling it today. Latest stable release of python mind you 3.7.3. We have to move structured data around from a legacy system and integrate it with our new website. Perfect opertunity for types. This also includes trying to use mypy.
Coming from typescript it's been very lackluster.
* 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.
I agree that mypy can be a bit lacking, but to address a couple of your mypy woes:
- 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.,
- 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: ...The problem I had with Literal["foo"] is that at least according to mypy "foo" is a string and it was expecting Literal["foo"].
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.
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.
That is false.
On point 1: def use_int(n: int): return n * 2
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 complains> "I'm familiar with tool A. Today I tried tool B and I couldn't figure out how to use it correctly, so it must be lacking. Everyone should know!"
From 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.
From 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.
One of the very useful things Typescript has for a dynamic-language-turned-static is smart casts, union types and dependent types union types.
Things like these are possible:
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
}
}
You can do that in Python as well though.
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 allowsAnd you can even do that with dict in the most recent version of mypy.
But 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.
But 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.
Explicit is good in Python world.
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.
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.
You are right. Let's remove the "+" operator in favor of operator.add. It's totally worth the readability.
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.
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.
It is not unique, union type and path aware type system will do this, for example in Crystal: https://crystal-lang.org/reference/syntax_and_semantics/unio...
Fairly unique as in the only mainstream programming language that can do this
Not to nitpick too much, but wouldn't the function expecting an interface be a much better fit for a case like this?
You can name the things I left anonymous, wouldn't change the principles.
The Typescript docs have more details and advantages for this specific scenario: https://www.typescriptlang.org/docs/handbook/advanced-types....
The Typescript docs have more details and advantages for this specific scenario: https://www.typescriptlang.org/docs/handbook/advanced-types....
The absence of two PEPs that haven't shipped yet cause me great annoyance on a daily basis: 0544 [1] and 0589 [2].
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.
1: https://www.python.org/dev/peps/pep-0544/
2: https://www.python.org/dev/peps/pep-0589/
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.
1: https://www.python.org/dev/peps/pep-0544/
2: https://www.python.org/dev/peps/pep-0589/
Typescript feels like it's own language. Whereas python types are just optional extra information you can add (more like Flow does), and they are rather verbose and clunky compared to Typescript
You can try and take some old JS lib and annotate it in TS. It'll work. It'll be very clunky, and full of any/unknown.
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.
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.
For one, they're not actually enforced
http://mypy-lang.org/
Disclaimer: I have not used MyPy. I'm just interested.
Disclaimer: I have not used MyPy. I'm just interested.
Both TS and mypy has strict mode and "implicit Any" mode.
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)
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)
Typescript is way more ahead and mature than Python static type annotations or other community libraries for static type check
Ref Link :- https://www.typescriptlang.org/docs/handbook/advanced-types....
Ref Link :- https://www.typescriptlang.org/docs/handbook/advanced-types....
Conditional types and the `infer` directive, I’d imagine. Which end up being very powerful.
Yes -- so I've reverted back to putting my types in docblocks. The python type system makes code too messy.
> I was excited to start adding type hints into our backend Python code
Some people are choosing node at backend just because how good typescript is.
Some people are choosing node at backend just because how good typescript is.
I am just sad that ReasonML doesn't seem to take off. I guess because of the JS interop is not as smooth. This language is even better in my opinion. Just looking at the list of its features [1] and it's syntax is so beautiful, the pattern matching being so powerful [2]. And it's based on OCaml, no null and undefined but an option type.
[1] https://reasonml.github.io/docs/en/what-and-why
[2] https://reasonml.github.io/docs/en/pattern-matching
[1] https://reasonml.github.io/docs/en/what-and-why
[2] https://reasonml.github.io/docs/en/pattern-matching
Just keep using it, its time will come when people continue to use it and JS developers see it as a viable alternative rather than a theoretical niche fantasy language, as OCaml is seen among many developers today, especially those in web development. That's what I'm doing.
Typescript has massively improved my quality of life working on JS projects. I occasionally run into constructs that are difficult to type but most of the time TS just works. Thanks to all the people behind this project for all your work!
interface IntMap {
[name: string]: int
}
interface StringMap {
[name: string]: string
}
These are:
type IntMap = Record<string, int>;
type StringMap = Record<string, string>;If you get a chance, you should also consider moving more towards ES2015 Map<K, V> and Set<V> objects instead of object literals as property maps. Browser support for Map/Set is pretty universal at this point (and easy to polyfill in the worst case that you need to support IE <= 10, which why?). You get better performance in some cases, and better handling of edge cases (strange string keys, accidental prototype inheritance, key name / language keyword clashes).
You can always make a generic
Interface ObjMap<T> = {[name: string]: T}
And the use it as const intMap: ObjMap<int> and voila!
Interface ObjMap<T> = {[name: string]: T}
And the use it as const intMap: ObjMap<int> and voila!
I feel like I'm the only one, but I don't care for Typescript.
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.
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.
All Typescript does is highlight how bad the Higher order Components pattern is. Don’t do it, use hooks or render props instead.
You're not the only one. It's an absolute pain dealing with incorrect and incomplete type definitions and lack of TypeScript examples for libraries. If all libraries I used were built and documented using TypeScript, I'd probably use it.
If you're struggling with TypeScript + React, check out the React TypeScript Cheatsheets: https://github.com/typescript-cheatsheets/react-typescript-c...
There's even a specific one on how to type HOCs: https://github.com/typescript-cheatsheets/react-typescript-c...
There's even a specific one on how to type HOCs: https://github.com/typescript-cheatsheets/react-typescript-c...
You're not the only one who believes this; you're just ahead of the curve.
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.
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.
I agree in part. I've also had the type battle with HoC... and with Redux is still pretty painful. I don't know if this is Typescripts fault though, or more to do with some of js magic that goes on. But, once you win the battle... having typed redux and HoC works great!
Personally I prefer to not use typescript on react (I don't have any experience on it and it seems like a hassle). I use it on mobx / redux instead.
However it's a godsend for nodejs.
However it's a godsend for nodejs.
It’s not really a hassle at all and adds great value with compile time checking of proptypes etc. Give it a go. If you use MobX especially you should find it really quite straightforward - I’m not sure what typing Redux is like these days, didn’t used to be much fun but I’ve not used Redux for about 3 years
TypeScript is such a fundamental milestone in the web and javascript community. (coming from Microsoft too!) I really do hope front end communities converge on typescript in an idiomatic manner.
There are many nice modern languages that compile to JavaScript. Personally, I like [Haxe](https://haxe.org/), which compiles to many other target platforms/languages as well.
Here's a [comparison of Haxe and TypeScript](https://blog.onthewings.net/2015/08/05/typescript-vs-haxe/).
Here's a [comparison of Haxe and TypeScript](https://blog.onthewings.net/2015/08/05/typescript-vs-haxe/).
I'm all for more new and innovative languages, but I think the key thing about TypeScript is not that it compiles to JavaScript, but (to quote basarat's great free book[1]) that "TypeScript is just JavaScript with docs".
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.
[1]: https://github.com/basarat/typescript-book
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.
[1]: https://github.com/basarat/typescript-book
>TypeScript is a strict superset of JavaScript
I had the impression this has been debunked already.
http://blog.jonasbandi.net/2016/10/myth-of-superset.html
I had the impression this has been debunked already.
http://blog.jonasbandi.net/2016/10/myth-of-superset.html
My own understanding is that a few persons have made comments or blog posts along the line of, "Look at this convoluted edge case I created of valid JavaScript that isn't valid TypesScript! Ha! Gotcha!"
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.
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.
Thanks for the share! That's a great one that I will read into more, but I do want to add while TS isn't perfect. I think one of the biggest advantages has been community buy-in. A language like TS would be no where if the community wasn't adopting it and increasing its adoption through network effects. If you use TS and include a library that is written in TS, there's a huge advantage to having accurate typings. Many libraries that don't use TS and add typings later usually have conflicting community provided types.
I think a list of highly adopted libraries written in TS would be great. One I recently realized was TS is immutable.js!
I think a list of highly adopted libraries written in TS would be great. One I recently realized was TS is immutable.js!
> coming from Microsoft too!
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'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?
It sounded more like disbelief or mild shock to me, rather than excitement; as in, of all companies to contribute to open source and the open web, it is Microsoft doing so.
Ah. You may very well be right.
I think "and from microsoft!?" would be one way to do that clearly. Not that it matters.
I think "and from microsoft!?" would be one way to do that clearly. Not that it matters.
Nothing has improved my day-to-day work life more in the last 5 years than typescript.
It's joy. Just, joy.
It's joy. Just, joy.
I've noticed there's a lot of talk on twitter about making TypeScript be an agreed upon best practice for frontend web developers. I'm glad TypeScript is doing well because there are certainly a lot of talented and dedicated developers working on it, but I really don't want to use static typing, even if there is a lot of type inference happening. I will need to make sure I don't plan on finding job or gig opportunities at the types of companies that are going require the use of TypeScript.
A proper type system offers a level of safety and correctness that simply cannot be achieved without one, especially as the complexity of an application grows. Also, the supposed lack of cognitive overhead without a type system is actually a subtle form of technical debt where you move faster because you eschew thinking deeply about your data structures up front, but inevitably pay a bigger price in production when you have to debug data type errors at run-time. The debt has to be paid again by every new developer tasked with working on the project because they have to organically absorb an understanding of the application's data structures that could have been explicitly defined and enforced by the computer. Finally, the extent of defensive programming required to begin to make up for a type system actually adds a ton of extra code itself (e.g. tons of guard blocks testing brittle application values at run time). Not all type systems are created equally, but a code base without types is pretty much always worse than a comparable one with types (the exception being shell scripts and other relatively simple programs that aren't maintained by a team of developers)
> I will need to make sure I don't plan on finding job or gig opportunities at the types of companies that are going require the use of TypeScript.
If you're really dynamic, the type of company won't matter, right :)
If you're really dynamic, the type of company won't matter, right :)
It's generally pushing towards the type of projects I want to work on anyways, with small codebases, and things broken down into components, and lots of freedom in how to implement things.
Sounds like you might enjoy Lisps even more (clojurescript for frontend?). In my experience, that's the pinnacle of dynamically typed.
Do you believe static typing is harmful (to the type of company you want to join), or is this a personal preference (which is totally valid)? Honestly curious.
I've found that the kinds of errors that static typing guards against are often things that would have been trivial to debug and fix in the first place (mostly things like typos).
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.
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.
> I've found that the kinds of errors that static typing guards against are often things that would have been trivial to debug and fix in the first place (mostly things like typos).
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.
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 have found the main advantage of static typing being easy, convenient refactoring. I never get my design or code to be just "right" the first time. I get the naming wrong, the functions too big, the design a bit skewed. I need to do a couple of passes, refactoring to get it in a tight shape. And statically typed languages give you tools to refactor with confidence.
This is one of the advantages of typescript over a language like clojurescript.
This is one of the advantages of typescript over a language like clojurescript.
That's totally fair.
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.
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.
I've worked in a number of languages and fwiw I've never written such error-free code as I have in Scala when embracing the type system (to a reasonable degree) and embracing immutability/fp patterns. We write only the tests that truly matter, something I've never felt is possible in a dynamic language as I personally feel you need lots of tests which are more or less provided for free by the type checker.
One thing nobody likes to mention much is that the value of a type system also scales pretty heavily with the quality (or lack thereof) of developers using it.
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.
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.
I used to think like that, until I was forced to use TypeScript at a new company.
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.
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.
> I used to think like that
Such arrogance.. ..and unfortunately so typical for TS proponents..
Such arrogance.. ..and unfortunately so typical for TS proponents..
I think “debugging errors in prod” is not generally how I like to spend my working life, with or without excellent logging and tooling for surfacing errors.
How this works in practice is usually 1) deploy some change, 2) errors start showing up that correspond to that change, 3) click a button to revert the change instantaneously (some systems can even do this automatically), 4) debug the change in dev
There is no way any of this process takes less time to solve than "I got a red squiggle in my editor and fixed the variable spelling". I don't think typos are really the only things type systems fix (type systems provide powerful ways of preventing screw-ups by allowing you to encode invariants about a piece of data and how it may be used), but if typos are indeed the extent of it, it seems unimaginable to me that the process to fix would be faster by going through code review -> CI pipeline -> deploy and then back again, no matter how fast it is to revert a change in production. Honestly that's just the compile-time safety advantage of types, half the time saved in typescript is just not spending time having to read someone else's source code to figure out how a function may be used because cowboy js devs were too lazy to document them (knex is an especially egregious offender in this regard that I thankfully don't have to use anymore).
I never claimed it was "faster". Of course static types allow you to catch errors earlier in the process than without.
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).
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).
Some patterns or abstractions are more difficult in statically typed code but after a while you start to realize you probably shouldn't use them most of the time. Static typing makes it very easy to be _precisely_ abstract, and have some proof that things which claim to be that abstraction actually satisfy a certain structure. Dynamic typing may make it easy to be abstract in all kinds of crazy ways (I'm looking at you ruby metaprgroamming) but without safety abstraction can easily be more of a liability than a benefit.
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.
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.
Monitoring is a tool to help you know when something is already broken, it does nothing to prevent problems, unlike a type system. If your error rates are spiking in production then real customers are getting a bad experience with your product, i.e. hurting sales, your brand image, and generating more work for your colleagues in the form of customer-support tickets that a human still needs to resolve even though you "instantaneously" rolled back the changes.
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.
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.
Dear god this process is insane. It’s the closest thing to malpractice that I’ve heard of in our industry lately.
I am starting to wonder if the preference static vs dynamic is some kind of character trait like introvert vs extrovert. I personally prefer static typing and use it to my advantage during development but I know very smart people who hate static typing and think it impedes them. Both sides have valid arguments but seem to prioritize things differently.
However I think it’s important to have used both for a while so you can make a good decision what you prefer.
However I think it’s important to have used both for a while so you can make a good decision what you prefer.
I think it depends a lot on previous experience, what type of thing you are developing, and your tooling. I'm very comfortable and happy bouncing between C# in Unity, React and JS, and Haskell for more CS / intellectual curiosities. For me it's more about fit and choosing the right tool for the job.
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.
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.
Fwiw we have a relatively large Scala codebase that's exceptionally bug-free, performant.and easy to modify and haven't had to reach for a lot of the extremely abstract FP patterns that warrant the most blog posts. Simple immutability, garden variety monads (IO, Either, Option) get you a long way and are simple to understand.
"static vs dynamic is down to personal preferences" was the running thesis of some of Steve Yegge's essays. His "Portrait of a N00b" is more/less one aspect of this.
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).
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).
I don't know. My favourite languages to work in are Clojure (very dynamic) and the ML family (powerful types). I'll admit I've indulged in some C++ type orgies in the past. What I don't like is dynamic types in an imperative setting (python, js). I think dynamically typed oop is a bad combo.
> However I think it’s important to have used both for a while so you can make a good decision what you prefer.
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.
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 am also starting to embrace a mix. “Any” in TS or “dynamic” in C# can save a lot of code when parsing JSON but then I usually quickly try to move over into the typed world.
`unknown` is also a really convenient type too: https://www.typescriptlang.org/docs/handbook/release-notes/t...
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"
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"
At first I thought I was going to read "I am starting to wonder if the preference static vs dynamic is some kind of character trait like intelligent vs ignorant", which would have been much closer to the truth. I think you're very incorrect.
Maintaining a codebase of any sufficient size and complexity without static typing is a poor investment of development time. It can be done, obviously, but it's a nightmare.
Typescript is a bandaid for web-development's biggest open wound. Taken on its own merits ( ignoring the garbage ecosystem, terrible tooling, etc ) Typescript is a decent enough language, but it's not a clever one.
Is Typescript better than vanilla Node.js? Absolutely. Is it worth introducing to an area without Node.js? Absolutely not.
If your project is any more complex than a four page CRUD app, in my opinion you're better off going with a bigger player like Java/.Net. These languages are more robust, more mature, there's better tooling, better community... The list goes on.
I am not sure if I want to work with you if you think it’s about “intelligent vs ignorant"...
Even though I seem to be in the “intelligent” camp by your definition.
Even though I seem to be in the “intelligent” camp by your definition.
That's fine.
Personal preference is valid only to an extent. At a certain point, with enough scale/team size/complexity TypeScript becomes invaluable. I've worked on projects that would have been intractable without TypeScript.
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.
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.
I don't like static typing, as a personal preference. I like the rapid prototyping of dynamic typing, and a type system often times gets in the way of that.
That's funny, I don't like dynamic typing for the same reason. Rapid prototyping without types makes the whole process so much slower!
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.
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.
Even if you don't opt in to full TypeScript, please do remember that the same engine powering the TypeScript language is also what powers IDE support and completions for JS in vscode and VS, so even if you're not using TypeScript _the language_, you're potentially still using TypeScript, _the static analysis tool_. Even without opting in to full type safety, having those tools available can still be a huge quality of life improvement.
It's a personal preference. Being able to make, fix, and guard against (with testing) type errors is a freedom that I've enjoyed with ruby, python, lisp (scheme/racket), scheme, and JavaScript.
[deleted]
[deleted]
I quite like static typing, though with some caveats. I strongly believe automated testing is more important. And I am also not afraid to make something an 'any' if it's proving particularly hard to type.
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.
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 think another way to look at some of the benefits of TypeScript is class introspection. By writing your classes in an idiomatic manner, it makes it trivial to see the shape of your api’s without you having to write large amounts of documentation. As well TS compiler will check you’re using the api’s correctly. Huge wins!
For another perspective, the TS compiler which is written in TS has zero classes.
There are usually plenty of opportunities to infer types and check identifiers etc. at compile time without the need to annotate anything. And the more you annotate, the more opportunities for the compiler to help.
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.
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.
This you will need to explain. :o
What kind of griefs static typing is giving you?
It changes the order in which I think about solving problems, to something I'm less comfortable with.
Is that really true though? To me this sounds more like making the validation of the program an afterthought, at best. Even in very academic mathematical models, introducing types early usually doesn't introduce much of a cognitive burden. I maintain that even when developers don't think that they're reasoning in terms of types, in many cases they are:
"This is function 'x'. It takes two items of type 'T', which have to have a member 'a', which is a number. Function 'x' multiples the two 't.a' values together and returns a new 'T' with the result in its 'a' field."
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.
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.
Isn’t it preferable to start with data modeling?
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.
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.
That's understandable - being pestered with error messages early on is not to everyone's taste and can indeed interfere with one's creative process. But can't one always start with JS and switch to TS later?
What would be the downsides of TypeScript, from your perspective?
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':
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'
For your example, I would prefer a variable called active that can be true or false (True or False in python). This is just an example but I see stuff like this in statically typed projects, where integer enums are used when a string will suffice, and strings are used where booleans will suffice.
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).
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).
"I see stuff like this in statically typed projects, where integer enums are used when a string will suffice, and strings are used where booleans will suffice."
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.
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.
I'm aware of this capability in TypeScript, which is why I specified integer enums instead of just calling it an enum. However, integer enums are still an option, and with TypeScript it would be easy to use an integer as a micro-optimization, which could be a pain if JSON gets exported and the person looking at it doesn't know what the numbers mean.
If you use a const enum in TypeScript it gets transpiled down to just the plain integer or string without any additional overhead. It just means you can't use a variable to get a value from the enum e.g. State[ currentState ] - which I'm not sure is a good pattern to use anyway.
Ah, I thought you were referring to an integer taking the place of an enum, which is a terrible practice that for some reason is more common than you'd think. I'm not too sure what you mean by 'micro-optimization' here, these kind of languages are so high level that the term 'optimisation' really doesn't apply. Regarding the JSON serialisation point: The internal representation of an enumerated type would probably depend on the needs of its serialisation medium. If it's going in a binary file, then an integer is probably your best bet. If it's going into a database, you might not have that limitation. This all depends on the scenario. As long as you're referencing the enum by its proper handle, that is.
I was thinking of it as a storage optimization. "inactive" is going to take more storage than the number 2, both serialized and deserialized. Might seem like a bigger deal than the difference in CPU usage.
I was really hoping optional chaining would be in, but turns out that's scheduled for the next minor release, 3.7.
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).
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).
Yeah, this is something I had hoped for as well. Mobx-state-tree [1] also makes use of generators for asynchronous tasks and typescript's inability to infer types of values returned from a yield is a pain.
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
[2] https://github.com/kentcdodds/babel-plugin-macros
[3] https://github.com/ts-delight/async-to-generator.macro
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
[2] https://github.com/kentcdodds/babel-plugin-macros
[3] https://github.com/ts-delight/async-to-generator.macro
Oh, it's good to hear that feature is coming in 3.7! That's something I really miss on a regular basis.
Where did you learn it's scheduled for 3.7?
Where did you learn it's scheduled for 3.7?
I know typescript is really popular around here. And I do like it for autocompletion and refactoring. But am I the only one who thinks typescript makes code unreadable? It looks so messy. I can understand a piece of normal js way faster than the same code with types. Don't have this problem with, for example, java. Maybe it's the syntax with the colons or the fact that I'm used to types appearing before the name instead of after...
Automatically ignoring types comes with intuition. After a while, you start seeing beyond the types. I hope and assume this is normal, because I've experienced this type blindness in all types languages that I've used.
It's interesting that you don't have this problem with Java, is it because Java always has types, while TS is lenient?
It's interesting that you don't have this problem with Java, is it because Java always has types, while TS is lenient?
I applaud Microsoft for popularizing gradual typing , bringing types to the js world is an enormous task, both technical and (js-)societal.
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.
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]I don't find that remotely readable. By that I mean that nothing in the code gives me the slightest inkling of what kind of command I would type or button I would click, expecting this code to run in response.
There are a lot of languages where even if you don't know that language, you can figure out what's happening. I have no idea what your example is supposed to do.
That's because it's taken from a library that deals with graphs[1]. I had to look it up, because I had no idea what it does either and I know Haskell. Here's a better example of what he meant in Elm, a language that looks a lot like Haskell:
https://github.com/bryanjenningz/25-elm-examples/blob/master...
[1]: http://hackage.haskell.org/package/fgl-5.7.0.1/docs/Data-Gra...
[1]: http://hackage.haskell.org/package/fgl-5.7.0.1/docs/Data-Gra...
It's also possible that you're providing types that inference was capable of working out on its own. You shouldn't be seeing type annotations everywhere.
Perhaps you can set your IDE to gray out the types.
Is anyone else using javascript + jsdoc + .d.ts files, and using typescript as a kind of linter?
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.
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.
Yes this has been a lifesaver. We have a nodejs application without a lot of obvious structure and lots of ad-hoc objects thrown around. Gradually adding .d.ts files, adding tsdoc comments (`@param {SomeType} foo`), and running `tsc` at test-time has already caught numerous bugs that otherwise would have required lots of unpleasant time with the debugger.
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.
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.
I do this, too -- sort of. I prefer for type-checking to give useful feedback than for it to act as a control-gate, because the latter increases the length of the feedback loop between writing code and seeing its behaviour.
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).
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).
Yes - Lighthouse does this https://github.com/GoogleChrome/lighthouse
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...
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...
I do this extensively with Flow comment syntax at work and it's great. I tried it w/ Typescript on a side project recently, but I found it to be a bit limited (e.g. @callback doesn't play well with RORO pattern) and the syntax is a bit clunky.
But having runnable code without a build step is definitely a very big plus for me.
But having runnable code without a build step is definitely a very big plus for me.
I never use the callback tag, I tend to just do:
/** @param {(x: X) => Y} f */
The problem with @param is that it requires a binding name
I ended up doing this instead:
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.
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.
index.d.ts:
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})
Good point!
[deleted]
I think I got off to a bad start with Typescript. Decided to add it to on the frontend of a bog standard Vue + Vuex erp app.
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
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
> 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).
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
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
Last I checked Vue was not working correctly with certain, newer TypeScript versions. Not sure if they fixed it up but it was that way since late last year through at least a couple months ago. I also got the impression the Vue 3 work was helping issues like that to stagnate.
While I think that TS offers probably the best type system out ther, eg way better than Go's, I'd love to see a more balanced view on TS in discussion threads like this one.
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.
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.
I wouldn't exactly call what TypeScript has the best type system out there. It's deliberately unsound, doesn't enforce full static type-checking, _and_ doesn't provide for runtime checks (there are third-party libraries, but if you're bringing up third parties one might as well argue that JavaScript has a great type system because TypeScript exists).
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.
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.
Disagree. TS' type system is fully featured compared to others and what you described as an disadvantage is actually an advantage or TS' killer feature: you can gradually convert a dynamic code base into a static one where needed. IDK of any other language that allows this.
Fully featured compared to what, exactly? If you say Java I might just have to laugh.
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...
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...
Not going to discuss this further. You have a dogmatic view on what is an excellent type system.
For prototyping using React and TS sounds like a bad idea, because React is not that well supported by the TS community.
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.
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.
> For prototyping using React and TS sounds like a bad idea, because React is not that well supported by the TS community.
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.
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.
Typescript only solves one of Javascript's two main problems. What really makes JS an abysmal experience is it's lack of a standard library. Compile-to-JS languages are in a unique position to solve this problem so I urge Microsoft to focus on a curated set of reliable libraries which can constitute a stdlib for JS. There are plenty out there already so it shouldn't be difficult.
I feel like lodash and date-fns is like 80% of what I want out of a standard library. I mostly use the built-in fetch but Axios is nice too.
I also tend to use js-cookie and uri.js because the browser has horrible APIs for working with cookies and urls.
I also tend to use js-cookie and uri.js because the browser has horrible APIs for working with cookies and urls.
JS was designed to be dynamically typed, just as Python and others, it is at the root of those languages. I can totally imagine that with all the big web apps of today type safety is a thing for some people working in large code bases. But that doesn't mean all dynamically typed languages need to perish.
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.
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.
>For me, this is so typical for the JS community, jumping the boat in a whim.
This is Microsoft's product, the company famous for keeping legacy going, hardly the 'JS community'
This is Microsoft's product, the company famous for keeping legacy going, hardly the 'JS community'
If anyone here has switched from TypeScript to Flow or vice versa, care to comment on how that's been working out? I use flow at work, and I am starting to really love it, but it seems like most people prefer TypeScript to flow.
Typescript is only language I came across, where documentation is in release notes, so to learn about feature you have to crawl all of them and there is nowhere else to find it.
I love that static typing has come to the Javascript ecosystem and I hope that some of these concepts make their way upstream into future versions of ECMAScript.
typescript is the best thing that happened with web development within 2010-2020.
Nice to see the TypeScript Playground (https://typescript-play.js.org) getting some love.
Makes it easier to see what all options are available in TSC.
Makes it easier to see what all options are available in TSC.
Frustrating, though, that there's no good repl for TypeScript.
I've used ts-node, with pretty good results.
https://www.npmjs.com/package/ts-node
https://www.npmjs.com/package/ts-node
Ts-Node is great. Startup times are slow though. 30x slower. Example for same script using node vs tsnode: "user 0.11s" "user 0m2.839s".
Am I doing something dumb?
Am I doing something dumb?
Ts-node is honestly pretty terrible. By-default you need to disable some errors that make sense in code but not in a repl. "You just imported this thing but didn't use it yet, ERROR", which means that nobody uses the thing. Granted, I'm pretty spoiled by how excellent ipython is, but clearly no one actually uses ts-node. It doesn't even remember history between sessions, and they have no interest in making that work, even deferring to rlwrap.
Interesting. I haven’t used it as a repl. Just for running ts scripts directly so I don’t have to do a 2 step compile/execute.
Dumb? No, incorrectly maybe though. Ts-node has to scan files for types upon startup - there are various knobs to control this I think. Mu bet is that it's the culprit.
Nice, finally, there are typed generators. That could possibly enable us to write something like do-notation in Haskell in a type-safe way.
TS is probably the best solution to JS problems today. And something like project Deno may even push it one step further.
> For those unfamiliar, TypeScript is a
Finally, a release notes that explains what the product is!
Finally, a release notes that explains what the product is!
Disclaimer: I'm currently interning at Microsoft.
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.
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.
Microsoft also have Microsoft Research Cambridge. Where I am pretty sure they have Simon Peyton Jones who works on Haskell there.
I think V8 belongs in the google camp.
"V8 is an open-source JavaScript engine developed by The Chromium Project for Google Chrome and Chromium web browsers."
https://en.wikipedia.org/wiki/V8_(JavaScript_engine)
Seems google does a lot of opensource stuff as well.
https://opensource.google.com/projects/explore/featured
https://en.wikipedia.org/wiki/V8_(JavaScript_engine)
Seems google does a lot of opensource stuff as well.
https://opensource.google.com/projects/explore/featured
I saw a photo of Stallman drinking bottled water once, which probably contradicts with his ideology that water wants to be free.
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.
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.
I wonder if you're referring to his talk at ChasmWare '16?
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."
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."
Apparently not the first time Stallman has had a visit to Microsoft
Microsoft Welcomes Richard Stallman (2005) http://suseroot.com/rms.php
Microsoft Welcomes Richard Stallman (2005) http://suseroot.com/rms.php
Haha, that's actually a perfect example of how Microsoft has changed. 14 years ago it was literally an April Fools day joke to say Stallman would go to Microsoft.
> what's left of F#
Has it been abandoned? What did you mean by this?
Has it been abandoned? What did you mean by this?
This is silly, F# has never been more of a first-class citizen. It's explicitly part of the .net core distributions, part of the nightly testing and validation cycles, and is in the TechEmpower benchmarks.
Try to use EF, Forms, WPF, UWP, designers, architecture tooling with F#.
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.
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.
That’s because C/C++ is what Windows is written in, and C# is likely used by a majority of their customer base. The only reason anyone pays attention to VB is because of Excel/VBA. F# (or Lisp for that matter) just isn’t as cool as Python or JS/TS in the wider general dev community. Which might be a terrible shame, but... it’s also the truth as it stands right now. I’m a firm believer all languages need a core platform or use case that they excel at, an ecosystem. And I’ve seen more of an attempt at that with Dart and Flutter than I have with F# up till now. Of course, we all know with the way Google kills things, it’s only a matter of time before the Chrome team ultimately kills Flutter somehow, unless it gets repositioned into the new way to make interactive banner ads... By comparison, Microsoft seems pretty stable, so I think F# will get its niche. It took Ruby over a decade before Rails came along to popularize it to a wider audience, and C++14 and friends reinvigorated C++ after many, many years. Even JavaScript languished as DHTML and jQuery for over a decade before seeing a comeback on servers and as annual standards mostly thanks to tooling and ecosystem developments powered by faster browsers and incredibly broad first-class platform support. F# sounds like a giant work-in-progress, perhaps hampered by the complexity of .NET and Microsoft in general — example: https://github.com/fsharp/fslang-suggestions/issues/542 By comparison, the C# community just seems faster, larger, more decisive: https://github.com/filipw/dotnet-script/issues/156
I don't know the actual status, but I do know that there aren't that many people at Microsoft officially working on F#. That could change, but I don't know the specifics.
Bummer, I've been curious about learning it.
I don't think there's ever been many people working on f#...(compared to c#)
Its good as it is anyway.
Its good as it is anyway.
Yeah definitely don't take this as a reason to avoid F#. It's open source anyways, so it'll be maintained regardless. Plus the team has gone to heroic lengths to integrate an ML into .NET. Their unification process is insane and probably technically undecidable.
I don't believe F# has been abandoned. It's actively being maintained.
https://github.com/dotnet/fsharp/
https://github.com/dotnet/fsharp/
Plain OCaml is still a better and more powerful language. F# is like a poor relative to it. The only good thing of it is .NET integration. It lacks so many features of OCaml.
And OCaml lacks features that F# has. Like proper multicore support, computation expressions, unit of measure, operator overloading.
> computation expressions, unit of measure, operator overloading.
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.
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.
Why so? Genuinely curios from a guy who knows neither.
I know OCaml, but not F#.
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.
See https://stackoverflow.com/q/179492/8887578.
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.
See https://stackoverflow.com/q/179492/8887578.
As an OCaml person, what are your thoughts on Reason?
I personally don't use Reason. It's syntax is supposed to be more familiar for people coming from JavaScript, but for me, it's weird. My least favorite aspect is the function syntax (both lambdas and function application). Are functions still curried, or...? If they are, then the syntax should reflect that.
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.
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.
It'd be news to me that it's abandoned, since we're wrapping up our latest release in September :)
V8 is Google / Chromium.
Since Edge adopted V8 as its new engine, Microsoft has been contributing to V8
Sure, but a bit silly to put it under Microsoft and not mention it in the Google list.
Do you know when? Also is it some internal MSR thing at 99 or inside-out in east campus?
Next Wednesday in 99/1919. I actually can't attend cause I'm finishing my internship. If you haven't already, I'd sign up for the MSR Talks mailing list.
what's the DG alias?
Yeah, inquiring minds want to know.
Wow, it's true. Microsoft folks can look it up on resnet.
Reasons not to use Microsoft https://stallman.org/microsoft.html
vfjmcxg(4)
> 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.
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've heard bad things about working at Microsoft. Perhaps from people masquerading as (ex)employees, though I suspect not.
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.
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.
I loved working there. The people are amazing and I made many great friends. But I was an engineer and not involved in business decisions. To me, making file formats hard to parse to the detriment of your users for business strategic advantage is smart business but wrong. I don’t want to judge people from the 90s by today’s standards, and maybe Microsoft brass really have changed their tune, but maybe they have some secret Ulterior plan, like in the past.
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.