Mint-lang: a language for the front-end web | Hacker News Reader

Mint-lang: a language for the front-end web

mint-lang.com

112 pointsgalfarragem106 comments

What I would really like is for JS to have a good macro system so I don't have to subscribe to the two caste hierarchy of language creator and language user.

Sweet.js [1] did it for me initially as cspjs[2] had async, await and more years before ... but I never found the time to ramp up to the updated version sadly so I can't comment on its state now.

[1] https://www.sweetjs.org/

[2] https://gitHub.com/srikumarks/cspjs

The two caste hierarchy is my biggest issue with Golang. Macro capability exists in Golang, but only for the upper caste of language creators. It makes me feel like the language creators of Golang purposefully decide that users of the language aren’t smart.

You might be interested in trying out Nim. It's a language that empowers the user, giving access to AST macros, compile-time function execution and generics.

I would say that using Nim's metaprogramming capabilities to create a great SPA framework is a better direction than creating a brand new language.

I'd second this, especially since Nim has already got decent server-side capabilities as well means you can write an isometric web application where the server-side is written in a language with performance comparable to C.

My only gripe with Nim is, as usual with non-mainstream languages, lack of libraries and frameworks (and lack of polish in the ones that exist, like Jester). The language itself is good and it's still evolving, so it has a chance of getting even better.

BTW: I've read your book, great job! The "Advanced concepts" part was a bit too short (I'd gladly trade some of the earlier chapters for more examples of both FFI and metaprogramming), but I generally enjoyed the book.

Also, I like how the code listings are annotated - how did you generate them? Is there some software specifically for this, or did you have to position all the arrows and lines and text manually?

> My only gripe with Nim is, as usual with non-mainstream languages, lack of libraries and frameworks (and lack of polish in the ones that exist, like Jester). The language itself is good and it's still evolving, so it has a chance of getting even better.

We need you to help us change that :)

> BTW: I've read your book, great job!

Thanks!

> Also, I like how the code listings are annotated - how did you generate them?

I used asciidoc to write the book and then my publisher applied some magic to format everything nicely. Not sure about the details I'm afraid.

Programming is as much about communicating with your peers as it is about getting the computer to do what you want. Go's inflexibility results in uniform code which makes it easier to understand.

Macros allow you to introduce dialects which can be powerful in their expressiveness but often result in significant departures from the original language.

When someone new comes into the project they have to learn the dialect before they can even read the code. More often than not they give up and rewrite the code from scratch in a language they understand.

Sometimes additions to the language make sense, but there's a real cost, a cost that often gets ignored. Do it to much and you kill the golden goose.

I agree with the first point, but not the second.

The go language seems more than anything to be "you can use our language, but it serves us and our wants first and foremost."

Now, I like the enforced style guide. That's not my gripe. It's that go deliberately treats certain platforms as second class, deliberately treats feature requests as second class if they are not complementary to what the original creators intents.

I don't wanna get shot for opening the can of worms about generics for the millionth time, but it just seemed like such an obvious solution to a widespread, pervasive, irritating problem. It was an issue early on, before there was really a lot of back-compat surface to even think about, but it wasn't what the Google posse wanted, and it didn't happen.

In the case of go, I believe the true cost of making it better is that Google is learning that when you use an internal product for a wide array of projects, and then later on you decide to flesh it out and open source it, you lose the ability to react to your audience as easily and that also narrows the surface for people to come in fresh to the project and contribute or provide feedback.

Go shot it's own foot. We (non-googlers) certainly didn't do it to them.

All this aside, the technical prowess at work on the team, especially in the past twoish years has been really impressive. At least they have stellar developers.

It's not a comment on a users intelligence. It is instead a recognition that not all users value the same things. Therefore it is helpful for consistency and the writing of robust maintainable code that Go be opinionated at the language level. You don't have agree to with them but they made their choices informed by their years of writing large complicated codebases and they enforce those decisions at the language level. They have no wish to allow someone else to subvert those decisions since it would be counter to the goal of the language.

You as a user can choose to live with those decisions or use a language that gives you more freedom. All such decisions come with a series of tradeoffs. Just make sure you are making the decision in as informed a way as you can.

Rob Pike, in his own words, claims that programmers at google are "not capable of understanding a brilliant language", and that this is the reason why Go is designed the way it is.

The full quote:

> The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

-- Rob Pike, 2014, at ~20m50s of https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr...

That's been my experience at Microsoft. I'd love to start a new project there in F#. And I think the kids there would eventually grasp it and create better code. They're certainly smart enough. But it would take a while to unlearn OOP. My first year or two of F# code was complete crap. So given average tenure of a fresh grad bigcorp employee is a couple of years, it would not be worth it. I think this is a good decision though an unfortunate reality by Rob Pike.

A solution might be to change the hiring process to test FP concepts instead of OO, or to use a lisp- so users do not need to learn a complex type system in addition to FP.

If they are using C# (I'm making that assumption - I could be mistaken), the type system in F# isn't a huge leap in terms of learnability. It wasn't that way in my experience, anyways.

The learning curve seems to be with other aspects - like where the hell do I put my I/O? Error handling? How do I trace (or write) all these functions that are piped or composed together? Questions like those are what I tend to see. Both personally and when pointing other people to F#.

As an ML, F# isn’t a pure FP, so I/O and error handling shouldn’t be that hard.

But ya, functional oragami will make debugging harder even in C#.

I think it would be easy enough for the go compiler to support macros, while keeping them disabled by default. There could be a cli flag for go build that enables macros. It would be easy to have a company-wide rule to keep macros disabled. It would be trivial to prevent code with macros from passing CI if that was one of your organizational requirements.

> It makes me feel like the language creators of Golang purposefully decide that users of the language aren’t smart.

If they are anything like Guido for Python, I think the idea is quite the contrary.

Language users are smart. Just too smart for their own good.

Like the coyotes we talked about recently on HN (https://news.ycombinator.com/item?id=17079369) who are "winning the mini-game of each human interaction, but they are losing the meta-game of what society will do if coyotes aren’t scared."

Well, just like that, language users with macros are winning the mini-game of their interaction with the current opened files in their editor, but they are loosing the meta game of maintainable projects, shareable knowledge and reusable tools.

Macros (or their small brother, "just a little DSL") are the most abuse feature in dev, period. They are too clever, the results almost never documented or even tested properly while often being very specific to the creator use cases.

I really think macros are one of the reasons why Lisp never became more popular: a small smart population love it for macros while the rest of the population just doesn't want to have to deal with all the macros BS created by the former population.

Same for Ruby. Honestly, having to go through yet another DSL du jour killed it for me.

So my guess is that the Goland creators know very well how smart the language users are. And they are afraid, very afraid.

.. and they're afraid, very afraid that if you give them that kind of power, they will make the creators roles irrelevant.

By echoing this in the echo chamber, we've perhaps deprived ourselves of getting enough collective experience with powerful programming tools to be able to establish good norms to teach high power maintainable programming. We're instead stuck in low level language wars.

Using type systems for system design anyone? Use Beta abstraction systematically?

> .. and they're afraid, very afraid that if you give them that kind of power, they will make the creators roles irrelevant.

That would be fantastic.

But right now most companies have a hard drive finding decent middle level dev.

Let's talk about your plan when american companies don't hire me to work from my bedroom in the south of France because they can't even find what they need in their own country anymore.

Unless you have a recipe to turn people that strugle with fizz buzz being able to magically understand complex abstractions.

> people that strugle with fizz buzz being able to magically understand complex abstractions

Are these the same ones who are "too smart for their own good"?

Read my comments again: you clearly missed the notion of proportion.

What's missing, as far as I've been able to determine, is a way to use Sweet.js or similar with typescript. What I really want is a language that provides me with static types but lets me have macros to generate the boilerplate that tends to result.

OCaml has its macro system and compiles to JS (via BuckleScript or js_of_ocaml). I'm not sure if ReasonML also has macros, but I wouldn't be surprised if it did, and there's a lot of articles lately about using it with React.

Personally, I never used OCaml on the frontend, but have some experience writing native apps in it and it's a really good language. Its type system is top-notch, its object system is unorthodox and powerful, the camlp4 macros allow for adding new syntax to the language - and so on. Worth taking a look at if you're searching for strongly, statically typed language for the frontend.

JS has tagged template literals. I think they're still underused.

Since this is a comment in response to an expressed desire to use macros, I'm curious -- is there some way you could use tagged template literals as a macro system? Beyond what eval gives you?

They can't directly substitute for macros because they run when execution reaches them, rather than once at load time, and because they can't inspect their code arguments.

But they do satisfy a lot of the desire for syntactic abstraction -- see e.g. https://github.com/erights/quasiParserGenerator

It's called ClojureScript. BTW, at a first glance it addresses everything Mint does, and runs circles around it. https://clojurescript.org/guides/quick-start

For the ones who want to get (a similar) developer experience while coding actual JS(X): you can use `react` together with `mobx` to the same effect. Additionally, take a look at `mobx-state-tree` to get more structured code.

And of course, there's Elm if you want to get a completely different thing.

Elm, Elm, Elm!

Elm is extremely opinionated and bottlenecked by one person. It’s great for the specific usecases it was designed for, but it gets tedious once you start interacting with external code and the outside world. The development cycle is slow and communication from the dev team is sparse. Some would argue that the slow deliberate, development pace is a good thing, but I was personally turned off by the fact that compiler bugs (and even documentation spelling mistakes) would stay open for months or years.

I know somebody is going to jump in and tell me I’m wrong, that they’re using Elm in production and it’s the best, etc. This is my personal experience from using Elm on several side projects and also in production at my last job.

If your opinion lines up with whatever opinionated tool you use, you won't experience friction and will perceive the tool as aiding your work. It's not rocket surgery.

It was the same thing when Ruby on Rails hit it big; some people swore by it and others detested it. It's like having a car that will only turn left, as long as you need to go left the car is perfect for you.

I appreciate you sharing your experience. I think point you raised are valid.

Elm works for me and makes me happy. I couldn't ask for more. Any perceived slowness in initial development is gained later by very solid foundation on which I work. Again, all you said is true.

Elm actually means Elm + JS.

Given

1) The language development pace (localStorage does not have an Elm equivalent, let alone service workers, etc)

and

2) The Elm ecosystem is very closed and only one person can actually release powerful libraries in the blessed package manager.

Make it so that Elm will still not be able to do everything we need it to to write an SPA in 5 years without javascript on the side.

I wonder more and more what Elm offers that langs like ReasonML don’t?

Elm is more constrained, eg. no synchronous JS interop; no side effects, only explicit effects, etc.

As has been said in other thread, for some that's great news, for others it's limiting.

mobx-state-tree is really neat and feels like the next step beyond redux. Not having to create explicit event names and 'action dispatchers' is a real boon to DRY. The only issue I've had is more to do with typescript and using mobx-state-tree plus react router... the type definitions and type error messages can get rather confusing to debug.

> Not having to create explicit event names and 'action dispatchers' is a real boon to DRY.

What about an action creator / reducer isn't dry?

in redux there's so much repetition that most of the time you do copy->paste->find&replace entity name.

You have the name of the action and the name of the action creator which essentially represent the same thing. I've never seen a project which had multiple creators for the same action name.

You might like my library - no actions or reducers, and great typescript support. You just use regular JS to manipulate data and the library updates the store immutably.

https://github.com/gunn/pure-store

I'm quite excited by ReasonReact. React with strong types! https://reasonml.github.io/reason-react/

I can see why they colour coded blocks. I think that project would have been unreadable otherwise. Which is ironic because even the worst of HTML with inlined CSS and JavaScript is more readable (albeit less maintainable).

Cool to see that this is written in Crystal.

Author here, please keep in mind that Mint is still very young and I'm still working to get things in order for a first stable-ish release (there are a lot of documentation to write and lot of cleanup work)

I'm glad that this project was written on Crystal. But does it tries to be like Elm?

The author had been using Elm before (they're an author of elm-ui, for example), so maybe there's an inspiration?

The author here, I was using Elm for a while invested a lot of time in it so there are parts of it that I like and that are parts that I don't.

In a sense it tries to be like Elm:

- good developer experience with nice error messages

- single binary that have all the tools

- enforcing types

- no runtime exceptions is you don't use JS interop

In an other sense it tries not to be like Elm:

- JSX syntax with easy compose-ability

- Straightforward JS interop

- Decentralized and open package management

I don't think I can make up my mind over small example. I don't think it is bad it is using patterns from React or Mobx as they are well known and it can help us think about development.

Syntax is not such that I am immediately sold, but also not put off. What I didn't see is some performance promise like Elm, or simplicity, where it make sense to use this over anything else.

I think it is good that a lot of people are thinking about languages and how to improve development, not everything has to be ground breaking. I will keep an eye for future work and how it develops.

Thank you for this comment! It really helps a lot to get decent feedback.

> What I didn't see is some performance promise like Elm, or simplicity, where it make sense to use this over anything else.

I was focusing on the example, it seems I should really put up more information about this on the website, but to answer for this is basically:

- it uses React under the hood meaning you have the same performance, the devtools works the same, it is possible (with some work) to use components from Mint in React and vice versa.

- the error messages are really nice (there 281 unique error messages overall) both for syntax errors and type errors

- easy JS interop using backticks

- no import statements

- fast compile times (the website compiles around 1 second)

- single binary with all the tools included (development server, production builder, favicon generator, test runner)

>The else branch must be present, if it's missing you will get a syntax error this is to make sure that all of the possibilities are covered

Is there itsokay statement to pacify the compiler more?

If if/else is an expression, what would be the return type of `if (true) { 42 }`?

    int option

which is basically a variant/union like this:

    Result of 'a | Void

You could also have a `discard` or `ignore` function/operator, which can swallow every type, so it doesn't matter what it was. Some languages actually require you to use such operators, for example, Nim and F#.

Web languages seem to be the new web frameworks for JavaScript - in the sense that there seem to be more and more of them coming out all the time.

This is really cool, and I did something very similar (more hackish) ten years ago. This is a very powerful technique, and I wish the mint team the best. The downside is really a combination of building a community and educating people about it; this is where I failed along with SEO.

> The downside is really a combination of building a community and educating people about it

Yes, this is what I'm worried about.

I'm still tweaking a lot of things and I wanted to share it with HN when I thought it was ready, but on the other hand it's a nice that it got some attention already.

I hope there will be enough interest over time to actually build up a community.

Just a empty white page on my phone.

Same. Refreshing though.

You'll need to have Javascript enabled to see the page. Mint's website is written in Mint, which is a compile-to-javascript front-end language that "tries to solve most common issues of Single Page Applications".

I have. Using Opera mobile tho.

Blank page with JS disabled.

"Nothing to see here." literally.

Awesome!!!

Why do you think it's awesome? It's just another zealous implementation of some guys unearned and unfounded ideology. You know you can write the same thing with regular JavaScript and cut out the middle-man.

A polyglot is harder to reason about than a single language, due to social concerns. Mostly this is due to the efficiency of singular concern and custodianship as opposed to disjointed languages with their own.

This looks awesome!

How about just biting the bullet and writing JavaScript?

If I decided I wanted to use Delphi, but I didn't like Object Pascal, so I implemented a Scheme over the top that gave weird deep backtraces with wrong line numbers whenever an error occurred, compiled to a single-line semicolon-delimited mess of unidiomatic Pascal, and often required me to write some Pascal anyway, you'd think I was nuts. Why do we think it's a good idea just because it's in a browser?

JavaScript has its problems, but it's far from the worst language out there. Just write JavaScript already.

I think you just described ES6 compiled by Babel pretty well. Most people have gotten used to this disconnect.

Well, with Babel you at least have source maps so you can get the original source locations in your backtraces.

There's nothing stopping other compile-to-javascript languages from having source maps too

Yes, it’s a pretty standard feature which is why it works so well. You can Typescript->ES->bundled ES->bundled minified ES and Chrome will point you directly at the original source in the debugger (once you give it permission).

One of the benefits I've seen while using Elm is that you virtually never need browser-based backtraces. The Elm compiler catches everything and has much better error messages, in my opinion.

Unfortunately, that ship sailed long ago, and the javascript community has coalesced around avoiding direct contact with the language at any cost.

Why is it unfortunate that people improve their tools with things like Elm and Mint?

And how is "just use Javascript" a response to that? Seems like yall should first try to understand why people use tools like Elm and Mint instead of assuming it's just some flippant aversion to Javascript?

You don't need compile-to-js languages to have the benefits that those languages provide. You could validate javascript for correctness and safety directly, or import js libraries which implement "types" which javascript doesn't support (because such types have to be to javascript anyway.)

But I think the primary reason to use languages that compile to javascript, rather than tools that work on javascript, is to avoid writing javascript.

That's like saying you don't need static typing if you just write better code.

The primary reason to use other languages is not to avoid Javascript, but to use better tools. I use Elm because it has built-in immutability (JS doesn't), a statically-typed ecosystem (JS' is bolted on in a side channel), a single architecture pattern (vs JS' redux/flux/react/angular/etc).

By the time you get static typing, immutability, and an architecture set up in Javascript, you may have taken on a bunch of libraries / moving parts that are more complex that using a different language that comes with all of that out of the box.

Saying I'm just trying to avoid Javascript suggests misunderstanding.

I see your point, but I also think a smaller, more focused language can be useful for teams; in order to enforce best practices.

Think Elm: it's impossible to produce side-effects or mutate objects, cause the language simply does not have the facilities to do so. The guarantees Elm gives you would be hard to maintain if it was just a library which had to deal with JS's constant dynamicness.

Moreover this guarantees do not only improve developer experience; but also compiler optimizations.

The difference is that there's no other way to target the browser. With your Delphi example, you could just use a Scheme implementation that targets the same platform. With the browser, JS is the only way to run code. That's starting to change with WASM, but it'll be while before it can be used for everything JS is used for.

On the other hand, i could rewrite your comment about assembler, in the early days of C and B and the like. As source maps and debugging get better, we get closer to being able to ignore the javascript.

Working on a project in Angular right now I’m really questioning if the layers of abstraction on front end code are worth the cost. The compile times and performance costs over writing standard JS are real.

The complexity and maintenance costs of developing a real-world application in standard JS are also real.

I would only consider something like Typescript mandatory, because static typing is just so hugely important for any maintainable project. But beyond that, it's a little more work to come up with a clean MVC pattern yourself, but also perfectly feasible to not use React/Angular/etc.

Depends on scope and number of developers I guess.

Or you could design your application to not need all the bells and whistles and complicated shit that modern front-end web UIs throw in. 90% of pages could be static HTML. Probably 95% of "web applications" could be a set of forms with post-backs.

If I'm trying to make a thick-client, I'd rather build it in a language and platform that I don't have to fight quite so much.

Have you actually done it? I have, a team of 10 to 15 programmers building it for over an year (SPA, deployed on web, iOS and Android), and now I lead a team of 5 programmers maintaining it and developing new features. I will gladly pay the cost of a good abstraction for lower complexity.

Yes, I actually have. A plain old-school Razor view UI with post-backs was infinitely easier to maintain than the cobbled together mess of javascript that we've ended up with trying to move away from that old, unsexy technology. And almost everything is an order of magnitude harder to do, or to make changes to.

Do we really need yet another language for the web?

Every alternative I know is based on Ecmascript, what other alternatives are?

ClojureScript. Based on EDN.

Elm, ReasonML

Dart ! (Lol)

PureScript (Haskell) and BuckleScript (OCaml).

Nim. I just finished developing a forum using the Karax SPA framework and it's been a great experience: https://github.com/nim-lang/nimforum.

No, we don’t “need” it. But how do you think progress is made? People come up with new techniques and tools all the time, based on their previous experiences with a platform.

Sometimes these projects wither and die. Sometimes they find niches where they’re particularly useful. Sometimes they hang around with a core of dedicated users. Sometimes the ideas they introduce go on to influence other languages. Those are all beneficial.

I’m surprised to see this same complaint levelled so often.

I'm not sure what you mean by progress.

We do need better languages, but we should get rid of languages that marginally improve. Take CoffeeScript: it pushed EcmaScript forward, but does not offer enough feature today to justify pouring enourmous man-hour resources into it.

And this is true for many more languages (Flow, PureScript, LiveScript, IcedCoffeeScript, ...) which don't innovate on many aspects but just offer a slightly different - sometimes improved - syntax. I do recognize that many languages add value, but that must be offset to the cost of using these languages. Costs which are often quite high: Googleability, StackOverflowability, documentation, tooling, develop mindshare, library support, stability - these things don't come cheap and take years to mature.

Furthermore, these "innovate slightly" languages in the webspace take away resources from improving the current state of the art in mainstream (EcmaScript, TypeScript, Dart, C#, Java, ...). For instance, instead of improving some JS tool now resources go into e.g. writing a language server for aforementioned language.

A good example is Elm which does try to innovate on core concepts (builtin reactivity). That's a conceptual feature which can bring the state of the art of programming language design further.

Last, I do not mean that we should not write any more new languages; but we should stop trying to get large-audience adoption for "innovate-slightly" languages. It's a waste of braincycles and actually hurts the ecosystem.

PureScript is not JavaScript with a different syntax: it is a language with a full Hindley-Milner type system.

"A strongly-typed functional programming language that compiles to JavaScript -- Build real-world applications using functional techniques and expressive types, such as: Algebraic data types and pattern matching; Row polymorphism and extensible records; Higher kinded types; Type classes with functional dependencies; Higher-rank polymorphism" http://www.purescript.org

Came here to say this. PureScript has innovated enough to influence both Haskell and JavaScript. It is certainly a solid language in its own right

I understand the general sentiment, but the two categories you describe seem subjective to me.

For example, why do you consider TypeScript to be a "state of the art in mainstream" worth improving, and Flow to be just an "innovate-slightly" language? Those two projects are very close in nature. And if the key difference is adoption, then why is Dart along with EcmaScript and TypeScript?

Dart is an incredible achievement in terms of type systems tech. Gilad is a major inspiration for me. Great guy.

Idk whose "side" I'm on here, but I didn't want to lose an opportunity to blurt out my love.

It's a shame dart is being managed by google. I wish they had been more hands off with the dart team, as they are deviating from server-side go so people can write mobile apps in dart. Even though they'll look almost exactly like C# apps but with better types...

Anyways yeah. Dart. Cool types. Good vm. Gilad is a cool guy.

Can you explain why you think the type system in Dart is great (or point me to something on the web that does this) -- AFAIK, that has never been made a selling point of the language.

(I have been considering Dart for a while, but haven't taken the time to look into it because it doesn't seem like it provides additional benefits compared to other languages (apart from the Flutter aspect).)

So dart has the concept of gradual typing, where some portion of the program is annotated and the rest is not. I'm not completely up to date on current dart, but for some time there was the concept of checked compilation sms unchecked. Now I think it's called strong mode.

Anyways, you could check for certain major structural errors in unchecked mode and compile very fast, and then when it's time to start propping up a release, you can turn on checked mode and catch more intricate errors.

Gilad has been working on gradual/optional type systems for years. (they are technically two different ideas but the difference is rather academic and of little use to most programmers)

Anyways, dart has strong generics, it can do contravariance easily which makes refactoring code without breaking existing call sites, the dart lang spec has a great section on this.

In addition to all this, dart has really good reflection support through mirrors, a concept I'm not very familiar with, but it makes possible a tool called observatory, which is awesome. You can have source maps for dart2js, you can see which individual classes or methods or even lines of code are being utilized, you can get a lot visualizations about your performance profile, you can look at dart from the inside of dart. It's a lot like smalltalk, but way more practical.

Sort of like how rails took a perfectly good language and destroyed it, flutter seems to have built a foundation for taking dart and exploiting it.

Now they say its client-oriented" which I assume is googlese for "if you're not using dart for flutter, fuck off."

There was also a dart llvm effort at one point, but that became too useful and was abandoned.

If you are looking for a really good functional language for web, consider F# if you have dotnet experience, or bucklescript if you have ocaml support, scalajs if you have jvm experience and also love shitty tooling, and finally, purescript if you like haskell.

HN likes Elm a lot, but it's a little too opinionated for me, and although I like the BDFL approach to FOSS, it doesn't mean that you should be the ONLY developer in the core. That makes me exceptionally nervous about adoption, especially for professional work.

YouTube search for "gilad is right" for some talks that he's given. There's one where he dives in depth to the type system and how checking works.

Sorry for no links, literally using 2G right now, travelling.

Thanks for the extended explanation. Lots of things to chew on.

Yeah, I am unhappy that they are focusing Dart more on the client side (another reason, I didn't look too closely at it) -- focus like that is probably good for language adoption in some niche, but it would be nice to have a good strongly typed language that also has good support, good tooling and extensive libraries for use both on the client side and the server side (and for mobile app development!) so you have only one language to deal with everywhere. Dart is one of the few languages that from the outside seems closest to that ideal.

Yeah exactly. I've followed gilads work for more than a decade, but they have managed this project in typical Google fashion.

I'm kind of at the age where I'm just too far removed to try and work on learning a whole new field. If I could go back, I think I'd choose type theory and compilers and spent longer in college. Instead I learned to reverse software and built my career up piecemeal, but there is so much fascinating material surrounding compilers and the intricacies of how different type systems behave and allow modeling. I see how people get their whole career sucked up into that space.

F# still has a chance if dotnet can step their game up just a few more notches. They're getting better lately.

You will probably be disappointed to know that dart is fully statically typed now (with type inference). Still a good language but missing it's dynamic soul. I too thought that gradual typing was a perfect balance.

Oh no!

Well.

What is Gilad up to now, I wonder?

For such a talented researcher, that's gotta be demotivating for him. Bless him.

I guess dart is basically ceylon now but with contravariance? Gradual typing gave it such a unique space.

Gilad left Google last July and is now at Tensyr.

Source: http://bracha.org/cv.pdf

Man, I am way the hell out of date! Thanks for searching that, I appreciate the gesture, I could've just googled it.

I'm glad to see him in a position where he will be able to be more explorative though, that's gotta be a relief for him. I'm sure once flutter started picking up more engineers he probably knew then what the outcome would be and how his directional influence would start to be limited.

The categories are subjective but at the same time driven by a plethora of factors. The fact that TypeScript is developed by a large company means that it can overcome many barriers. Another factor is that the same company develops a new IDE (editor) in tandem; this means one of the most important parts of a language (tooling) is covered. A third factor of TypeScript is the many language features it offers. Fourth, the development pace is very high compared to most other projects. The "innovation factor" of TypeScript is combined quite high, as the "compile-to-readable-js", language features and tooling support combination is not achieved by many competitors.

Flow is a nice comparison as it is also backed by a large company. They don't offer a developed IDE in tandem, development pace is a lot lower and language features are not that many compared to TypeScript. The "innovation factor" is a lot lower - of the level I think it's not worth pouring resources into it.

This stinks as a masked React

Reply on news.ycombinator.com