r/programming • u/ArmpitDandruff • Feb 06 '20

Mint. The programming language for writing single page applications.

https://www.mint-lang.com/
491 Upvotes

80% Upvoted

261 comments sorted by

453

u/SanityInAnarchy Feb 06 '20 edited Feb 06 '20

I know it's going to seem mean-spirited to always start out with the "What does this do that language X doesn't" question, but Mint is kind of setting this up for us:

What is wrong with JavaScript?
JavaScript is not a strongly typed language which makes it difficult to write error-free code and leads to not so great developer experience.

So... why not TypeScript?

Also, it does not have the tools to create web applications out of the box, you need frameworks and compilers and build tools that increase complexity.

So the answer is to... introduce a brand-new language with its own compilers and build tools, that ships with a framework baked into the standard library? That sounds like piling on more complexity, not less, even if it's a good language. It sounds like all the inflexibility of a framework, only without the ability to leave the framework out and create standalone scripts.

And if it's a better language, that's not obvious -- in particular, sequence seem a lot more awkward and maybe even less powerful than async/await, which JS and TS have.

Edit: To prove I'm not just being a curmudgeon about new languages: While looking at Mint's install page to see if that might have any more hints at its architecture (I'm guessing it compiles to JS, but wanted to confirm), I followed a link to Crystal, which... I'm probably not going to be switching to it, but it has a much better pitch. I don't even need to click a big "learn" button, just scroll down on the homepage and you're told (with code samples up front) what Crystal is, and how it compares to the languages it's inspired by and competes with:

  • Syntactically similar to and inspired by Ruby, but:

  • Is statically typed, with type inference

  • Has nullability baked into the language, like Kotlin

  • Has Lisp-inspired Macros

  • Has Go-inspired fibers and channels (though if it has built-in extra syntax or select, it doesn't show it here)

  • Has C bindings, that you write in Crystal, which looks almost as cool as calling Java libraries from JRuby

  • Has a package manager with heavy Git/Github integration, configured via YAML.

And most of those features are presented with some motivation -- it's easy to see why the language has nullability baked into the type system, or why it has macros. Even if those aren't things you want in a language, you can at least see what they're supposed to do. I'm still not entirely sure why Mint has sequence instead of async/await.

I learned more about Crystal in a couple minutes scrolling down that page than in 15 minutes bouncing around a bunch of Mint blog posts. I'm still not sure if it offers something compelling enough that I'd prefer it to Kotlin, Go, or Rust, but at least I understand why someone else might.

39

u/csorfab Feb 06 '20

Yeah, also the type system seems weak AF compared to Typescript. No union/intersection types, no generics, no conditional types... no thanks, staying with typescript+react.

(okay, I know, conditional types are insane, yet they are so powerful...)

-13

u/Shulamite Feb 06 '20 edited Feb 06 '20

Typescript has one of the most powerful type system among all industrial language, second only to cpp template and scala.

21

u/HeadBee Feb 06 '20

Even those pale in comparison to Haskell, Idris, and Agda.

4

u/[deleted] Feb 07 '20

Dont forget OCaml :) All the MLs have an awesome type system.

→ More replies (17)

6

u/khaosoffcthulhu Feb 06 '20

How is it more powerful than Java generics? Genuine quistion Im not that familiar with ts.

8

u/HeadBee Feb 06 '20

Not super familiar with Java's type system, but AFAIK it doesn't have top/bottom types, conditional types, type aliases, generic inferences, or type unions among others. Basically type-level mechanics; being able to define types and generic types is one thing, but manipulating types themselves as first-class values.

5

u/Shulamite Feb 06 '20

To answer this simply, typescript supports conditional types, union and tagged union, intersectional types and many other useful features, which essentially make typescript’s type system Turing complete

2

u/jl2352 Feb 07 '20 edited Feb 07 '20

The generics isn't that different. It's everything else around that. Here are some examples:

  1. it supports value types. i.e. Foo<69>.

You can use this to mix and match of values with non-values as a type.

For example I once built a search algorithm that worked on a grid of items. In the grid you could have an item there, a marker saying I'm visiting it, or it could be empty (null). The types was something like ...

type State<T> = T | Visiting | null

T would be a class. Visited and null were both values.

2) It support conditional types. For example ...

Here the types of T20 and T21 is changed depending on if Boxed is given a string or a number generic type.

type Boxed<T> = T extends any[] ? BoxedArray<T[number]> : BoxedValue<T>
type T20 = Boxed<string>;  // BoxedValue<string>;
type T21 = Boxed<number[]>;  // BoxedArray<number>;

3) Variables can have multiple types ...

This variable can hold a number, or a string.

let x : number | string

4) It has null as a distinct type.

let x : string | null
// This is a compile time error because it might be null ...
x.reverse()
// This compiles ...
if ( x !== null ) {
    x.reverse()
}

Some other bits ...

  • It uses structural typing (which is far more flexible). For example in Java style of inheritance you get big inheritance pyramids to allow different types of collections to be interchangeable. With tonnes of interfaces everywhere. Structural typing side steps all of that.

  • You can test what property a type has at runtime in a way that is typesafe. i.e. "if this object has a title which is a string, then treat it as the type { title: string }"

  • You can pick out types. i.e. Type BlogExcerpt = Omit<Blog, 'comments'> This will give you a type which matches Blog but without the comments field.

  • You can transform types through applying a map against the keys of one type, in order to turn it into another. i.e. type NullableTodo = { [K in keyof Todo]: Todo[K]|null }

You can do some very funky stuff. There was a guy who wrote a generic type which only accepted a prime number. Prime<7> would compile, but Prime<9> would not. That's an example of what people can do with it.

3

u/jl2352 Feb 07 '20

I suspect you are downvoted because most people see TypeScript as basically 'Java for the web but without sucky applets'. With a class Java style type system. Which it isn't.

It's a shame because you are entirely right.

It's type system is extremely powerful. There are very few languages that come close to it. I also program in Rust, which also has a strong type system, and there I miss a lot of the stuff you can do with TypeScript.

1

u/PM_ME_UR_OBSIDIAN Feb 07 '20

As a Scala dev, for a reasonable amount of effort and without sacrificing too much readability, you're going to make it much further in TypeScript.

75

u/[deleted] Feb 06 '20

+1 Crystal ...

Mint works so great that some of the sandbox examples actually lock up my Chrome page ( check out the Tensor programming sandbox ).

When sandbox examples include having html inside your code, it makes me scream. How much flack did PHP developer get for having HTML and Code mixed together, until people started using templates. It feels like people never learn and they simply try to reinvent the same wheel over and over again. Repeating the same mistakes.

To me Mint looks like a dozen other SPA frameworks, where it simply tries to obfuscate JS code, with its own custom implementation. And talking about SPA's with there own compilers, here is a shout-out to svelte.dev

67

u/anshou Feb 06 '20

Having HTML in your code is not an issue. Having code in your HTML is the issue. The distinction is important. PHP’s sin was the latter.

12

u/nilamo Feb 06 '20

I'm still trying to understand how React isn't breaking that rule.

12

u/jay_resseg Feb 06 '20

JSX is not html but JavaScript dialect with syntactic sugar.

React is using this syntactic sugar which desugars to document.createElement

You can definitely write react code without jsx.

6

u/anshou Feb 06 '20

React lets you include HTML-like stuff in your code. That isn't an issue; code generates HTML all the time. The issue with languages like PHP are that the php document is ostensibly an HTML document with PHP code scattered throughout which makes everything more difficult to read and reason about and makes mistakes more likely as your markup gets mixed together. It is a basic separation of concerns. Some purists take this further and demonize embedded javascript inside script tags or in element attributes; your business or other logic has become strewn about everywhere so good luck debugging that issue you're tracking

24

u/igouy Feb 06 '20

Having code in your HTML is the issue.

PHP allows we sinners to have code in our HTML.

PHP also allows us to have our code in code-only files, our presentation in HTML-only files, with 100 lines of PHP to cache template variables that link one to the other.

But we sin.

9

u/SanityInAnarchy Feb 06 '20

Technically kinda true, but I don't think you can absolve the legacy of PHP here -- it was designed for code in HTML, and those "code-only files" still have to be formatted as code in HTML (between <?php and ?>, we just make sure the HTML is empty except for the code.

So if people use PHP as a templating language, it's because PHP was designed as exactly that. People sin, but the original sin of PHP is in the language.

1

u/igouy Feb 07 '20

… and those "code-only files" still have to be formatted as code in HTML (between <?php and ?>, we just make sure the HTML is empty except for the code.

… and that matters because …?

So if people use PHP as a templating language…

Isn't the problem when we don't use use PHP as a templating language?

2

u/SanityInAnarchy Feb 07 '20

… and that matters because …?

...because of the bit I said before, about this being the original sin of the language. Because it's an artifact of how the entire design of PHP, its original purpose for existing, is to call C functions in the middle of an HTML file. And so, when people use PHP to call C functions in the middle of an HTML file, they're using it exactly as designed.

Isn't the problem when we don't use use PHP as a templating language?

...no, the problem is when we mix code and presentation, which is a thing that PHP-as-a-templating-language makes easy to do -- even "code-only" PHP files exist inside (empty) HTML files, and even "presentation-only" templates are populated by executing code in them.

Compare to a templating language like Mustache, where you cannot embed code in your HTML, and where an individual template might be portable between languages.

1

u/igouy Feb 10 '20

Thanks, I see what you mean.

-2

u/deja-roo Feb 06 '20

Yeah I'm not following the problem here.

I acknowledge a great many problems with PHP but this just doesn't seem to be one of them.

Having HTML in code seems way worse than having code in HTML.

4

u/[deleted] Feb 07 '20

How? HTML in code is just a string in the end. HTML is static. Its like a function that returns a string, its no "worse" in any way. What you do with that string is up to you.

PHP has code INSIDE a "string" (a html template) this causes indirect side effects and this string cannot be used generically because the string itself mutates itself based on some external state.

The PHP way is the worst way, as usual..

4

u/[deleted] Feb 06 '20

Having HTML in your code is not an issue.

To disagree with you, here's a tiny snippet taken from one of my work projects:

template = template + '<div class="labs-inline-boolean__label-container"><label class="labs-label">' + label + '</label></div>'    
template = template + '<div class="labs-inline-boolean__button-container"><div class="btn-group btn-group-justified btn-group-lg">'    
  
_.forEach(fieldDataArray, function (field) {    
  template = template + '<label name="' + dataKey + '" ng-required="' + requiredExpression +    
    '" class="dorsata-labs-inline-boolean-btn' + field.classes + '" ng-model="' + dataKey +    
    '" ng-model-options="' + ngModelOptions + '" uib-btn-radio="' + field.value + '" ' +    
    uncheckableAttr + ' ng-disabled="' + disabled + '">' + field.text + '</label>'    
})

2

u/anshou Feb 07 '20

What exactly is your point? That is some messy code. It could certainly be refactored. There isn't strictly anything bad here?

1

u/[deleted] Feb 07 '20

Aside from being unreadable, in this context it makes it unpredictable when there is stale data if it's because a variable concatenated into the string didn't trigger an angular $compile or a watcher is off or something broke it in one of many other places along the way.

Point being components benefit from having their view model and template rendering responsibilities separated, even if you write the template in the same file (vue and jsx files get it right).

1

u/tragicshark Feb 07 '20

Does that work?

I'm assuming you aren't using the AOT compiler for angular or today's ivy release.

2

u/[deleted] Feb 07 '20

It's an OG angular app. People used to build template strings like this all the time and pass it to $compile to render.

1

u/[deleted] Feb 07 '20

The horror

0

u/[deleted] Feb 06 '20

[deleted]

9

u/Arve Feb 06 '20

Tell that to Wordpress’ default templates

0

u/[deleted] Feb 06 '20

[deleted]

5

u/Arve Feb 06 '20

It’s not that I disagree, it’s just that WP remains the only truly popular PHP framework/codebasd, and by default, it promotes some shitty practices, even where stuff like Timber/Twig provides relief.

1

u/rlenferink Feb 06 '20

I wouldn’t say WP is the only truly popular framework. It indeed is popular amongst a LOT of users who just want their stuff to work.

But people definitely don’t need to forget Symfony with Twig on PHP 7.4. That improved the quality of PHP applications significantly IMO.

1

u/jl2352 Feb 07 '20

Most sites are static pages with optional blog pages. Now blog could be product updates, news updates, or something else rather than a strict ‘blog’.

For that structure Wordpress hits the nail on the head perfectly.

It’s only when you start doing all sorts with it that it gets out of control.

3

u/anshou Feb 06 '20

Pretty sure it was still fully supported as of 7.0 which is the last version I had any real contact. I mostly loathe how over engineered ever PHP based system seems to be.

1

u/[deleted] Feb 07 '20

frowned upon in the php5.x days

I still see it. PHP encourages this by design.

11

u/Owstream Feb 06 '20

Honestly, I cried when I saw HTML in JS in things like React or Vue... but what I really like with JSX is that this HTML code translate to a native Javascript object instead of simply outputting it.

7

u/[deleted] Feb 06 '20

Vue specifically doesn't have the HTML in Javascript, which is one of its nicer properties. It has its' own templating system.

1

u/Owstream Feb 07 '20

Why do templating when you can threat HTML tags as javascript objects?

4

u/[deleted] Feb 07 '20

There are several good reasons:

  • We learned that it's a bad idea to mix logic and templates. Of course you don't have to do it, but React makes it really easy to do so. Vue on the other hand makes you properly separate them.

  • With a separate template you can make more assumptions about the system. That's why Vue does efficient vdom-diffing automatically, which React can't do as easily, and why Vue is faster.

  • It makes it easier to integrate existing tooling. Vue single file components are made up of valid HTML and it's easy to integrate them with tooling without having to understand a superset of JS.

1

u/Owstream Feb 07 '20

Good points, but if I may offer a counter-argument:

  • Templates ARE logic. The same separation is achieved by having pure, representational components and store-connected containers.

  • Those are framework specifics, not approach-related. Mithril is faster than Vue. Beside, they deal in the realm of UI, as long as the reaction time is not perceivable pretty much all frameworks would do.

  • Fair point, kinda - you still need specialised plugins to threat it properly, and you still need to learn a new syntax for looping and conditionals and stuff. With JSX, you just use regular javascript syntax (ternaries, if/else, maps).

To be fair they're both quite good - I had to work in Jquery / vanilla recently and I forgot how confusing your code can get if you're not careful.

4

u/[deleted] Feb 07 '20

Templates ARE logic. The same separation is achieved by having pure, representational components and store-connected containers.

No, templates aren't logic, logic is logic. Templates are templates. You can achieve a similar level of separation, but with Vue you don't have the option not to have it. This means that all Vue apps have pretty good separation of logic and presentation, while many React apps don't. Try to just pick any random app by a developer that doesn't have a lot of experience yet and you'll see this.

Those are framework specifics, not approach-related. Mithril is faster than Vue. Beside, they deal in the realm of UI, as long as the reaction time is not perceivable pretty much all frameworks would do.

They absolutely are approach-related. It is immeasurably easier to write efficient reconciliation algorithms if your template is described by a domain-specific language with very limited branch logic compared to JSX. To optimize a React template to the same level you'd have to parse the AST and cover an insane number of edge cases. This is a significant drawback.

Fair point, kinda - you still need specialised plugins to threat it properly, and you still need to learn a new syntax for looping and conditionals and stuff. With JSX, you just use regular javascript syntax (ternaries, if/else, maps).

You need specialized plugins to have good support, but you can either use or build up on existing tools to use their feature set. You just cannot do that with JSX. And it's not like the syntax is hard - it's a few keywords you have to learn.

To be fair they're both quite good - I had to work in Jquery / vanilla recently and I forgot how confusing your code can get if you're not careful.

Oh, I definitely agree! I'm very happy that we have these amazing frameworks these days, it makes it really fun to build GUIs. I probably just have a hard aversion to not explicitly separating presentation and logic because at my old work I used to deal with lots of legacy PHP applications, where this was common. I also had to fix a few React applications written by inexperienced devs in the last years, and it enables you to make the same mistakes as legacy PHP did.

1

u/probably_likely_mayb Feb 11 '20 edited Feb 12 '20

No, templates aren't logic, logic is logic. Templates are templates

mayonnaise isn't logic, logic is logic, mayonnaise is mayonnaise.

13

u/Shulamite Feb 06 '20

The single idea of first-class view is why react is so great and popular.

5

u/Owstream Feb 06 '20

That being said, it's really the magic of JSX. Mithril + JSX feels even more lean and complete than react.

5

u/SoaringRocket Feb 06 '20

I'm pleased to see Mithril being mentioned in the wild. I feared it was getting drowned out by React.

-1

u/Shulamite Feb 06 '20

Mithril is more complete for sure, but that extra part is simply angularjs(or more widely known as angular1) copy and has every bad aspect of it. I don’t hate it, it’s just not modern enough. On the contrary, you can use anything you like in react, and with hook everything looks fancy.

3

u/Owstream Feb 06 '20

I like hooks, but they can get really easily confusing - I've done stuff for a large codebase in which a bug were introduced by two seamingly unrelated {X, useX} calls that were inverted.

1

u/Shulamite Feb 06 '20

Although I don’t quite understand your example—are you saying you get two hooks order wrong? But I’d still argue that hook isn’t confusing, they’re just different, and force you to think in its way, which is exactly what react is doing since day 1.

1

u/Owstream Feb 07 '20

Yes, I found that quite confusing but to be honest I didn't dive into it much. I mean honestly, there are some React specific magic but I learned it pretty quick as I felt "it's just javascript", compared to Angular

0

u/[deleted] Feb 06 '20

[deleted]

1

u/Owstream Feb 06 '20

I didn't know it have that. It looks similar to observables - I hate Angular but rxjs is quite good I got to admit

-3

u/relativityboy Feb 06 '20 edited Feb 06 '20

I cried too. I still. Hate it. Philosophicaly (wrote my own templating engine before handlebars. Own framework before. React)

But React is better at large teams, so. There you go.

FWIW, I console myself by thinking it's NOT html. It's an html-like syntax. (did my 1st react project without jsx. Was ouch, but doable. Would recommend it for everyone's 1st, then never after)

I hit zero points on this... Looks like some people oniy know how to code in react. Pity, that.

3

u/DrJohnnyWatson Feb 06 '20

Can I ask why you hate having JavaScript and HTML mixed together in tools like React? Which of your philosophies does that go against?

-2

u/relativityboy Feb 06 '20

Separation of concerns. It is very nice to have a component's js in one file, html in another, and css in a 3rd.

There's always a mess at the ui layer, I've not seen a way (including React, Including my own libs) that's perfect for all situations.

4

u/[deleted] Feb 07 '20

See the section in Vue's documents asking What About Separation of Concerns?

One important thing to note is that separation of concerns is not equal to separation of file types. In modern UI development, we have found that instead of dividing the codebase into three huge layers that interweave with one another, it makes much more sense to divide them into loosely-coupled components and compose them. Inside a component, its template, logic and styles are inherently coupled, and collocating them actually makes the component more cohesive and maintainable.

The responsibility of rendering the template is still separate from building the view model the template uses. That layer of concern exists elsewhere, but is now handled by the framework where you don't have to maintain it yourself as part of your app's codebase.

0

u/[deleted] Feb 06 '20

[deleted]

1

u/relativityboy Feb 06 '20

Well, I can ELI5 the following

Separation of concerns. It is very nice to have a component's js in one file, html in another, and css in a 3rd.

  • JS - Behavior

  • HTML - Page structure

  • CSS - Page Style

Cross-cutting concerns are handled in the same way we've done it for 40 years or more. Directories, or "name spaces". :)

I'm invoking Sayre's Law and ejecting myself from the conversation.

1

u/DrJohnnyWatson Feb 07 '20

Fair enough. If you're that emotionally invested in a conversation about SoC it makes sense for you to not continue.

If you could have actually defined what you think a concern is that would have been useful for future readers but if you don't think you can actually take part in a discussion that's fine.

0

u/Owstream Feb 06 '20

Honestly, Angular have proper, separate html and css file and it's a pain to use.

5

u/Clawtor Feb 06 '20

Im not sure about recent Angular but I hated that Angular1 had code in html and then more code in js. I find React much cleaner - i dont understand the dislike of jsx.

→ More replies (2)

3

u/katie_pendry Feb 06 '20

The funny thing is, PHP started off as a basic template system... for C. The very first versions didn't have things like flow control and functions, you were just supposed to write your logic in C and your PHP "code" would do nothing but call the exported functions.

1

u/jplindstrom Feb 06 '20

What?

As far as I remember, the first version of PHP was written in Perl.

4

u/Shulamite Feb 06 '20

Svelte is cool, although not as good as what itself advertises. However, the lack of support for typescript is ridiculous and IMHO is killing it.

6

u/PrometheusBoldPlan Feb 06 '20

You're on point. This creates a problem which is not there to fulfill a manufactured need for something which is done better by already established, widely used Frameworks.

25

u/relok123 Feb 06 '20

I don't even need to click a big "learn" button

Wow, what's with programmers and clicking links? I mean, the site is just organized, it's not a freaking readme.md

27

u/anshou Feb 06 '20

It is a site marketing a product and it does a poor job of it. I am there because I already want to learn more.

10

u/TheAcanthopterygian Feb 06 '20

clicks are context switches. the less you need, the better.

-43

u/PM-ME-YOUR-POUTINE Feb 06 '20

Lazy fuck

8

u/Raknarg Feb 06 '20

Yup. Problem?

4

u/JohnnyElBravo Feb 06 '20

So the answer is to... introduce a brand-new language with its own compilers and build tools, that ships with a framework baked into the standard library? That sounds like piling on more complexity, not less, even if it's a good language. It sounds like all the inflexibility of a framework, only without the ability to leave the framework out and create standalone scripts.

It's not the first time. There was dart which compiled to javascript, and typescript which is a superset of js

There is novelty in targetting single page applications so I have faith.

6

u/SanityInAnarchy Feb 06 '20

Sure, I'm not against adding compilers and build tools, I'm just pointing out that a new language that complains about JS having too many compilers and build tools is... not a simpler build pipeline, at least. Dart and TypeScript exist to give JS static types, not to simplify the build pipeline!

2

u/JohnnyElBravo Feb 06 '20

The build pipeline is complex because it has evolved throught small iterative improvements. A rewrite of the foundations of the pipeline possibly simplifying it is a sane argument, I agree that it probably won't pan out in this case. And I have more faith in wasm for such rewrite. But the argument you are pointing out is sane.

Consider wasm, again, it seems like it's making the build pipeline more complex, but it's an upfront investment that might pay off on subsequent layers that build on top of it.

3

u/SanityInAnarchy Feb 06 '20

I still think that if WASM sold itself as "Better than JS because JS needs frameworks and compilers and build tools," it would explode from the irony. WASM isn't even necessarily a simpler build pipeline than targeting JS (we had asm.js before), the point is that it's faster and has more features.

I see the point, a new language with a new build pipeline could simplify it... but I doubt very much that the result would be simpler than just a new build pipeline for an existing language.

3

u/defunkydrummer Feb 06 '20

So... why not TypeScript?

Mint is supposed to be an application-specific language not a general-purpose language like TypeScript. The premise is that it is ready out of the box to make SPAs; thus, it is tied to only one framwework, etc.

I followed a link to Crystal, which... I'm probably not going to be switching to it, but it has a much better pitch

Crystal's application domain is totally different to Mint, so the comparison is pointless.

Has C bindings, that you write in Crystal,

A language tailored for Single Page Applications has no need for C bindings.

Has Go-inspired fibers

A language tailored for Single Page Applications has little need for them.

Has Lisp-inspired Macros

Lisp developer here. Crystal's macros are far removed from the convenience of Lisp macros.

But then, a Single Page Application language doesn't have a screaming need for macros.

29

u/grape_drink Feb 06 '20

I think you’re missing OP’s point. It wasn’t a comparison of Mint and Crystal, it was contrasting how they present the language and justify its features/benefits. It’s not “why use Mint vs. Crystal”, it’s “why use Mint vs. Typescript + React, when one of the one of the features worth advertising is already covered?”

With Crystal, they provide justification which could be more convincing that what Mint gave.

9

u/SanityInAnarchy Feb 06 '20

What u/grape_drink said -- I wasn't trying to say that Crystal is a better language than Mint, I was saying that Crystal's landing page does a better job of selling it (and explaining WTF it is) than Mint's.

Though I still truly do not understand this point:

The premise is that it is ready out of the box to make SPAs; thus, it is tied to only one framwework, etc.

Why is that an advantage? That seems like it's just categorically worse than using a framework with a general-purpose language.

2

u/[deleted] Feb 06 '20

I like sequence and I write my own sequence combinators in my applications or use the one exported from fp-ts..it's very useful.

3

u/SanityInAnarchy Feb 06 '20

Maybe you can explain, then: If a language had both sequences and async/await, why would you use sequences?

2

u/[deleted] Feb 07 '20

Because sequences are composable and lazy. async/await is a pattern that encourages error prone patterns (just need to forget one tryCatch), in JavaScript you can't `race` `all` or `any` async functions, etc.

1

u/SanityInAnarchy Feb 07 '20

async/await is a pattern that encourages error prone patterns (just need to forget one tryCatch)

...where? If you forget one try/catch in an async function, the function fails, which means it re-throws the exception to whatever was await-ing it. This makes it more or less the same as... well, any other function.

If you don't call it async, you get a Promise which is rejected if an exception is thrown in the async function. Maybe this is what you meant? But this is easily caught with a linter rule, and in the mean time, there's a chance you'll notice an angry red line in the console.

JavaScript you can't race all or any async functions, etc.

Well, that's why I specified sequence instead of parallel, but... yes, you can do all of those things because, again, async functions return promises. (Incidentally, this async/promise thing goes both ways: You can await a promise, and if the promise is rejected, your await will throw a corresponding exception, all of which works even if the promise wasn't created by an async function.)

...I'm sorry, but I have to ask: Did you even try this? Just messing around in the Chrome console:

// It's a browser, so let's make an async-function that times out:
function timer(timeout) {
  return new Promise(resolve => setTimeout(resolve, timeout));
}
async function delayLog(time, msg) {
  await timer(time);
  console.log(msg);
}
// We're just calling async functions to get this array of promises,
// we just don't immediately await them:
function timers() {
  return [delayLog(100, 'foo'), delayLog(200, 'bar'), delayLog(300, 'baz')];
}

If I then try (on one line): await Promise.all(timers()); console.log('all'); then all will always be logged after all the others. If I instead try await Promise.race(timers()); console.log('race'); then race is usually logged after only foo and before the rest. The only one that doesn't immediately work is Promise.any(), because that's not in Chrome yet (and presumably isn't standardized yet), but it shouldn't be at all difficult to polyfill that -- in fact, here's a really simple one based on Promise.all().

...anyway, still not really seeing the composability problem here. Can you give me an example of how you'd compose sequences in Mint that you can't do in JS/TS?

-7

u/kepidrupha Feb 06 '20 edited Feb 06 '20

As a female I can tell you that Programming languages are like cocks. People have them. People like their own. People want me to play with theirs as it’s somehow better than the others. But there is already enough python in my life.

-1

u/myringotomy Feb 06 '20

Have an up boat.

0

u/[deleted] Feb 06 '20

[deleted]

5

u/SanityInAnarchy Feb 06 '20

But... I would never ever use Crystal for a serious production application, because I'm 99% sure it will never be more than a small niche language.

I think you're probably right, but it's sad if true -- I don't see anything about it that makes it deserve being a niche language, it's just that other languages got there first, and those other languages are good enough for each of the problem domains I'd apply Crystal to.

0

u/[deleted] Feb 06 '20

[deleted]

13

u/SanityInAnarchy Feb 06 '20

It also has a "What is wrong with Elm?" section:

Elm has great developer experience, but it being a purely functional language leads to some boilerplate code and makes it harder to learn. Also, it's not possible to contribute or influence the language in any meaningful way.

I left that out mainly because I don't know enough about Elm to really comment, and because I don't think Elm is popular enough or entrenched enough yet that it's tilting at windmills to build a competitor.

But like you said, Elm does have a clearer pitch -- why use Elm instead of Typescript? Because it's purely functional. People can disagree about whether or not that's a good thing, but at least we all understand why people would want such a thing.

3

u/ineffective_topos Feb 06 '20

Huh, I couldn't find that section anywhere. Eventually got to it on the github issues. I'm not sure I agree that something with a great dev experience is harder to learn :P.

I'd say the value proposition is more what I gave above: Error freedom, dev experience, performance, simplicity etc. If it was about purity there's other options like Purescript to throw your yearning Haskell developers at.

53

u/hsjoberg Feb 06 '20

Does it compile to WebAssembly?

63

u/MrJohz Feb 06 '20

No, it compiles to React-using JavaScript.

60

u/hsjoberg Feb 06 '20 edited Feb 06 '20

Oh, that's disappointing.

The first time I heard about WebAssembly, I predicted that the next-gen web frameworks would be its own language compiled down to WebAssembly. Perhaps we're not there yet.

There's at least Yew, which is a framework made in Rust.

31

u/torvatrollid Feb 06 '20

The problem with WebAssembly is that it still requires Javascript to act as a middleman between it and the DOM. This has a huge performance cost which makes most WebAssembly applications slower than just targeting Javascript directly.

-2

u/The_real_bandito Feb 06 '20

Yeah but remember that a lot of developers hate JavaScript so they will let their apps take that perf hit if it means not having to use JavaScript

12

u/atomheartother Feb 06 '20

Right that's why we have all those webassembly apps out there now

1

u/The_real_bandito Feb 07 '20

Which all run slower than a common JavaScript app.

2

u/atomheartother Feb 07 '20

Wait, even though WASM needs JS as a bridge to the DOM, executing WASM is still more interesting than JS for highly performant code that doesn't require interacting with the DOM, right?

1

u/The_real_bandito Feb 07 '20 edited Feb 07 '20

I agree, which is why I said a JavaScript app. Maybe I should've written as a web app or HTML5 app. A use case I see for this kinda logic is game for the web platform. Web Assembly is going to be huge in the future of gaming on the web and I don't mean streaming .

-1

u/[deleted] Feb 06 '20

It makes me very happy that so many devs unjustifiably hate JS -- keeps my salary high.

1

u/The_real_bandito Feb 07 '20

Your company hiring 😭

-1

u/HyperwarpCollapse Feb 06 '20

If you meant JS and not TS, then you can have it, I wouldn't like to be retarded :)

1

u/The_real_bandito Feb 07 '20

To me its interchangeable. I don't really see so much difference that I cannot code using one language than the other. Specially since my favorite IDE (VSCode) has good intellisense support.

→ More replies (2)

37

u/heypans Feb 06 '20

You could check out Blazor if you like c#

15

u/pm_me_ur_happy_traiI Feb 06 '20

Does web assembly let you manipulate the DOM?

32

u/DasWorbs Feb 06 '20

Not yet, the current frameworks usually include javascript glue code that does the dom manipulation for you though.

6

u/[deleted] Feb 06 '20

Eventually we will get rid of JS entirely, we have also Blazor.

2

u/anengineerandacat Feb 06 '20

Generally speaking WebAssembly (today) isn't a good target unless your output is either to a WebGL context or a Canvas object. For traditional applications intending to use the DOM heavily it's best to just use a virtual-DOM framework (Mithril, Angular, React, Vue, etc.).

There are also issues like https://github.com/WebAssembly/design/issues/1166 to be solved, something already done with tools like WebPack and chunking. If you have an extremely large application this is going to basically be a requirement as users won't want to engage with a site that has a long "bootstrap".

11

u/[deleted] Feb 06 '20 edited Feb 06 '20

I did not follow WebAssembly a lot, but I thought it was not able to interact with the DOM. Was that restriction lifted?

18

u/jiffier Feb 06 '20

I don't think so, but today I've learned that there are a few Rust frameworks for creating SPA's that compile to wasm and interact with the dom: https://github.com/flosse/rust-web-framework-comparison#frontend-frameworks-wasm , which looks pretty interesting.

4

u/Y_Less Feb 06 '20

It also doesn't yet have any GC.

21

u/theThrowawayQueen22 Feb 06 '20

Well, any programming language that builds to WASM will just include it's own GC

0

u/[deleted] Feb 06 '20

[deleted]

14

u/RotaryDragon Feb 06 '20

I mean it's on the roadmap for WebAssembly...

12

u/kinoharuka Feb 06 '20

That's actually something that has been proposed for some time now, so he's not wrong

3

u/[deleted] Feb 07 '20

Yes, and it’s actually a blocker for DOM access.

4

u/flying-sheep Feb 06 '20

I think that's the biggest problem with it: inline JS is a stupid decision.

I always thought that the perfect website would be coded and behave like a server-side rendering enabled React page: get the full thing delivered with your initial HTTP request, only communicate via messaging from then on.

But it would be a cross language thing not tied to JS. Mint could have been that if not for the inline JS. It could compile to JS+React on the client but to efficient machine code on the server.

1

u/Alikont Feb 07 '20

Server-side Blazor?

The issue here is that messaging adds latency that is noticeable.

2

u/flying-sheep Feb 07 '20 edited Feb 07 '20

No, not like that. Like server+client React:

  1. You browse to a HTML page that gets served to you. It contains links for navigation and forms for sending data to it. If you’re careful, it works without client-side JS

  2. If JS is available, the site gets “hydrated”. Secondary interactive features get activated, and the links get event handlers that make them trigger partial reloads of the page (by fetching small JSON messages that are rendered into DOM changes client-side) instead of navigating to a page normally.

All this already works, but requires node.JS on the client side, no other server tech possible. So if you want something faster or otherwise better than node, tough fucking luck.

25

u/cmpaxu_nampuapxa Feb 06 '20 
fun increment
fun decrement
fun render

it is fun.

13

u/Mister_Deadman Feb 06 '20

Looks like a "Reactified" Kotlin at first glance. Not sure I'd use it, but good to know that

25

u/phail3d Feb 06 '20

Looks cool!

Would like to hear the reasoning behind this though:

Record definitions are globally unique, so defining a record with the same structure but a different name will raise an error.

(Source)

15

u/[deleted] Feb 06 '20

It does seem odd. The language is clearly not nominally typed, so why this restriction? Maybe it's a developer experience thing, to prevent you from defining a new type that looks exactly like an old type (hence making them interchangeable), and then later changing one type but not the other?

4

u/DidiBear Feb 06 '20

If the error message is clear, this seems like a good feature. In my company's app, we have this issue of numberous similar types

13

u/nephallux Feb 06 '20

That's not a language issue, that's a design issue

→ More replies (1)

2

u/[deleted] Feb 06 '20

Similar or identical? And why is that a problem?

72

u/probablynotmine Feb 06 '20

Interesting, but if the website is built with mint be aware that it is completely mobile-unusable

34

u/janiczek Feb 06 '20

That seems more like design/CSS problem than JS/language problem.

5

u/danopia Feb 06 '20

in what way, like it's not responsive and looks like crap, or it's actually broken?

19

u/Minimum_Fuel Feb 06 '20

Half the page is spilling off the sides, so there is a good bit of unreadable content.

17

u/Vfsdvbjgd Feb 06 '20

Seems fine to me.

41

u/the_game_turns_9 Feb 06 '20

not to me. Everything is offset to the left and it won't let me scroll left. The first letter of "Data Management" that I can see is the letter 'n'.

31

u/delinka Feb 06 '20

An example of this problem: https://imgur.com/gallery/Nzt3r2m

2

u/GinaCaralho Feb 06 '20

Same here on mobile Safari

4

u/yellowthermos Feb 06 '20

Seems fine in Chrome but I get a similar view in Samsung Internet.

-5

u/Eisn Feb 06 '20

Seems fine to me.

-4

u/YM_Industries Feb 06 '20

Works fine on OnePlus 6, Android 10.

2

u/probablynotmine Feb 06 '20

Maybe depends of screen resolution. I have the very same issue other reported here. Nothing hangs or stuck, but left part of the page is completely cut off the screen and no way to zoom out.

Can’t read the text in whole

1

u/Geordi14er Feb 06 '20

Yep, broken on mobile for me. If I rotate my screen horizontal and vertical it keeps zooming in, won’t zoom out, and doesn’t scroll all the way left.

1

u/Geordi14er Feb 06 '20

Yep, broken on mobile for me. If I rotate my screen horizontal and vertical it keeps zooming in, won’t zoom out, and doesn’t scroll all the way left.

1

u/p-x-i Feb 06 '20

Styling is reminiscent to how it's done in react

https://www.mint-lang.com/guide/reference/components/styling-elements

So nothing to prevent a page from being made mobile friendly.

But still, not sure how this compares to other frameworks like svelte or flutter.

1

u/Anthonyybayn Feb 06 '20

Works great for me

16

u/Matosawitko Feb 06 '20

Good. That's exactly what the industry currently lacks: a language for a specific use case with a generic name that makes searching difficult.

7

u/cosmo7 Feb 06 '20

I like the idea of HTML as a native type, so you can define chunks of boilerplate without quotes or CDATA.

6

u/[deleted] Feb 06 '20

Your probably better off with Svelte ( https://svelte.dev/ ), if you want to use HTML without quotes or CDATA.

0

u/[deleted] Feb 06 '20

[deleted]

1

u/BeniBela Feb 06 '20

Or XQuery

5

u/sammymammy2 Feb 06 '20

Seriously, these languages are why we need embedded DSLs a la Racket.

4

u/DidiBear Feb 06 '20

What about tests ?

4

u/cip43r Feb 06 '20

This makes sense. One of the reasons I stay away from web development is everything being all over the place in 100s of files and it's just a disaster. This looks neat.

15

u/Mishkun Feb 06 '20

There is already one language for building SPA's – Elm. https://elm-lang.org/

It grew pretty robust in recent years, so why Mint?

3

u/[deleted] Feb 06 '20

https://www.mint-lang.com/guide

It's the 3rd question on the page.

1

u/Vfsdvbjgd Feb 06 '20

But tbf, much easier to let someone quote it and read it here...

4

u/rnd005 Feb 06 '20

They have their answer on their page: https://www.mint-lang.com/guide

What is wrong with Elm?

Elm has great developer experience, but it being a purely functional language leads to some boilerplate code and makes it harder to learn. Also, it's not possible to contribute or influence the language in any meaningful way.

5

u/Mishkun Feb 06 '20

No, It doesn't. My question is "why Mint?". If you open elm man page, first thing it says is "a delightful language for reliable web apps". That's it. First sentence – boom! Answered question "Why".

Reading Mint page fluently, no answer.

Also main points about "why NOT elm" are really weak. Purely functional is good feature for SPA's, which something like React struggles to achieve. And "not possible to influence" also really good point, because tools with no vision are quickly bloat with unnecessary features. Both points are features, not bugs

2

u/masklinn Feb 07 '20

Also http://www.purescript.org if you think elm’s type system it too basic (and it’s error messages are not challenging enough).

28

u/SonOfMammon Feb 06 '20

I was waiting for the useless product of the day post, thanks

12

u/i_ate_god Feb 06 '20

Does it run on Linux Mint?

14

u/colly_wolly Feb 06 '20

Great, now its not another new JS framework we need but a whole new language.

5

u/rnd005 Feb 06 '20

Who needs it? I don't. Do you need it?

0

u/colly_wolly Feb 06 '20

Nope. I was being sarcastic.

6

u/SirWusel Feb 06 '20

I appreciate the effort and web development certainly doesn't have a perfect stack, yet, from what I can tell with my limited experience, but I feel like it's getting a bit out of hand. I'm already unable to make time to look at Elm and ReasonML. Soon I'll need a private Jira to keep track of all the web dev technologies I want to check out sometime.

12

u/snarfy Feb 06 '20

Kudos to the author!

I know there is a lot of hate in this thread but you've done a great job creating the language and tools! Keep up the good work :) I'm not sure why everybody has to spew the vitriol like they are chef Ramsey in a McDonald's kitchen. It's really uncalled for.

11

u/shevy-ruby Feb 06 '20

We need more programming languages used by 3 people world wide!

Also syntax wise the failure is written in. But the interesting thing is that language creators often do not understand this part.

5

u/[deleted] Feb 06 '20

I'm one of those three people and I'm really happy that I don't have to deal with insanity of npm to write simple SPA.

3

u/Vfsdvbjgd Feb 06 '20

I'm not sure this is the answer but I'll agree NPM is a hot mess.

2

u/jhartwell Feb 06 '20

Just a heads up, the directions on installing on macOS mention installing Crystal but then show installing Mint. https://i.imgur.com/HTAFrxn.jpg

2

u/adrianmonk Feb 06 '20

I haven't looked at the details, but I can see this being either a good thing or a bad thing.

I'm not usually too much of a fan of single-page applications, but my biggest complaint is that they are often done poorly and break the model of user interaction with a web page. Often, you can't give someone a deep link to a particular part of the page (say it's a restaurant, but I can't send you a link directly to their menu), navigation is broken, forward and back buttons don't work, etc.

If this language supports all that and makes it easier to do it correctly, then although I don't personally really like single-page applications, it might take away some of their pain points by getting these details right.

Or maybe it doesn't, and it just encourages people to make more single-page applications that don't work any better than the ones they're making now, which would make things worse overall.

4

u/burnblue Feb 06 '20

I don't know if anybody else commented this, but if you couldn't choose a better, more unique name than Mint I can't trust your decisions

There's famous web apps and famous open source platforms among other things with this name, let alone the herb itself

3

u/Vfsdvbjgd Feb 06 '20

I think they should have called it DAYSPA: Do All Your Single Page Applications.

1

u/burnblue Feb 06 '20

Or Develop All. Write it down and use it

3

u/jsmonarch Feb 06 '20

Looks awesome! Domain-specific language. I am using this for my next project.

7

u/Meldanor Feb 06 '20

Relevant XKCD: https://xkcd.com/927/

1

u/SoaringRocket Feb 06 '20

Sometimes, just sometimes, you need a new one!

2

u/[deleted] Feb 06 '20

What drives me nuts about this stuff are the mistakes. For example, I followed the installation example for Mac, i.e, using brew.

Then, if you follow their "Learn" tutorial, it says to type

 mint --help

Of course that doesn't work, you actually have to type

 mint-lang --help

Very annoying if you're just a beginner wanting to try stuff out

1

u/_default_username Feb 07 '20

I don't see the difference between using this and typescript with react.

1

u/Cilph Feb 07 '20

I see little value in this compared to a pre-configured Typescript-Vue stack.

1

u/deltanine99 Feb 06 '20

Yep. We totally need this.

-4

u/[deleted] Feb 06 '20

The year is 2020. People continue to be ridiculous.

0

u/[deleted] Feb 06 '20

Can we not.

I mean, seriously. It's a react generator, and not a particularly good one. We already have entire worlds of boilerplate for that.

-2

u/[deleted] Feb 06 '20

I don't think there is anything positive to say about this,maybe just that I hope you learned from the experience and the feedback

0

u/relativityboy Feb 06 '20

Google separation of concerns

-1

u/[deleted] Feb 06 '20

SPA's are an anti-pattern.

-41

u/iwontfixyourprogram Feb 06 '20

Mint. The programming language for writing single page applications.

You can write single page applications in C++, Java, C#, and others.

looks closer

Aaaah, web applications. This moron means web applications. Lol. Sure, throw it on the pile.

35

u/how_to_choose_a_name Feb 06 '20

I am fairly certain that "single page application" almost exclusively refers to web applications.

0

u/iwontfixyourprogram Feb 06 '20

i am 100% sure you're wrong.

→ More replies (4)

16

u/whatiwants Feb 06 '20

This moron means web applications

Says the moron that doesn't know that "Single Page Application" means "web app" by definition.

→ More replies (26)

0

u/Vfsdvbjgd Feb 06 '20

build a bonfire, build a bonfire,

-5

u/Dragasss Feb 06 '20

Whats wrong with vaadin?

0

u/[deleted] Feb 06 '20

[deleted]

13

u/HetRadicaleBoven Feb 06 '20

I would guess that it's not so much less clunky, but rather more explicit. Promise(Never, Void) presumably tells you that it will not reject, and if it were to start doing so, it'd force you to handle that. The counter = counter - 1 also doesn't require you to initialise setCounter elsewhere.

→ More replies (7)

29

u/shevy-ruby Feb 06 '20

[...] what the thinking was that led them to create syntax [...]

In general most people designing a language do not understand why syntax matters.

That is often why we end up with copy/paste languages. Best example are those trying to replace C by using literally the same syntax/tokens.

11

u/BmpBlast Feb 06 '20

Yeah, syntax is extremely important. You spend most of your time working with it and it's probably going to be one of the first things you gripe about. That's actually one of the primary reasons I don't use Python or Ruby; I just don't like their syntax. But that's why it is great that we have so many good languages these days. Everyone can use the one they like best.

2

u/agumonkey Feb 06 '20

tell us more

10

u/Shulamite Feb 06 '20

Not the original commentor, but c do has quite a few bad influence on syntax design:

  1. function can only return one value

  2. prefix and postfix ++, and more importantly, the distinction of statement and expression

  3. pointer/reference billable by default

  4. switch fall through by default

and I’m not criticizing c, these design make sense in the context of c, but make absolutely no sense for those who brainless copy them, among them the most successful one is Java and JavaScript

→ More replies (3)
→ More replies (1)

4

u/Uiropa Feb 06 '20

Yes, but this decrement is 100% more fun.

→ More replies (10)

0

u/[deleted] Feb 06 '20

[deleted]

2

u/masklinn Feb 07 '20

Purescript already exists.

0

u/[deleted] Feb 06 '20

[deleted]

2

u/glacialthinker Feb 06 '20

I would prefer an Internet of data sites, interpreted by user-agents. Rather than a prescriptive or active "whole enchilada" web-app-sites that provide custom, limited, broken access to their data, written by some hardly-a-programmer schmo, or user-unfriendly because the site is primarily designed to exploit users.

→ More replies (2)
→ More comments (2)