Hacker News Reader

Comment by scns | Hacker News Reader

With Bucklescript/Reason you get typesafety, immutability, performance and small codesize:

>Now we compare the runtime performance:

   BuckleScript Immutable Map: 1186ms
   Facebook Immutable Map: 3415ms

We also compare code Size:

    BuckleScript (Prod mode): 899 Bytes
    Facebook Immutable: 55.3K Bytes

source:

https://github.com/BuckleScript/bucklescript/wiki/Why-buckle...

View on HN

This all sounds great but I cringe a bit at yet another layer of abstraction in an already insane JS tooling ecosystem.

It seems like half of the time you’re just using the escape hatch to plain JS to stitch all of this stuff together, no?

Try elm. The elm abstraction is probably the only one where you literally will never ever touch javascript or raw html.

It is the least leaky abstraction I have ever encountered, which is amazing given the fact that it is also blazingly faster than every other framework from React to Vue. Elm is a way higher level abstraction then jsx or Vue yet you don't need to understand the lower level details to produce more efficient applications.

The most leaky abstraction I have ever encountered is probably SQL. Optimizing SQL involves understanding what it compiles into; Elm there is no such understanding required.

The comparison is quite unfair. Elm manages a system of 1k nodes accessed by one user while sql manages a system of 1m records accessed by 1k users (i am counting browsers) soo... yeah, leaky. You never ever have to optimize anything in sql when you have tables with 1k rows. It’s the scale of things that forces you to optimize.

elm is a high level abstraction that's faster then simpler lower level abstractions like jsx or vue. That's why it's a really good abstraction.

SQL is a leaky abstraction not because of scale. Scale is a requirement and the chosen abstraction for scale is actually not the wisest choice. SQL is an expression based language used to execute algorithms like binary search that are inherently imperative. Thus it is a bad abstraction and the scale of the requirements magnifies this. The need for the EXPLAIN ANALYZE key words exemplifies this flaw. A good abstraction for databases would be a language that explicitly declares the algorithm used for the query. This would make users able to explicitly optimize the query without needing to cross the barriers of abstraction. Like googles V8 implementation of javascript, ubiquity and tons of resources invested into creating an incredibly efficient implementation of an interpreter have made SQL and javascript the best choice for their respective fields even though they wouldn't have been the best design choice if people were given the choice to start over.

Rust is a better design then C++ but again ubiquity, early adoption and random forces have made languages with questionable design choices the dominant paradigm.

I like elm but:

- JS Interop is harder in elm.

- Inferno and some others are a lot faster than elm.

The JS interop is basically a leak in the abstraction. It in itself is a flaw and I'm claiming that elm is such a good abstraction that you don't need to access or touch the holes in the abstraction.

Never heard of inferno... I'll check it out.

This is the opposite of my experience with Elm. Tried it for a while. Getting the time or a random number takes a tutorial to learn how to do because those things aren't purely functional.

Then I wanted a fast lookup table, turns out all dictionary lookups in Elm are nlogn because it's backed by an immutable tree structure.

So, I disagree with you and went back to JavaScript.

Although I disagree with you, I never stated one was better then the other. All I said was that elm was the least leaky abstraction I've ever encountered. Your frustration with IO proves my point. There is a practical logic around why it was done that way, but the practicality won't be apparent until you create a huge 10 million LOC monolithic SPA with elm and compare it to the same type of app written in javascript.

> All I said was that elm was the least leaky abstraction I've ever encountered. Your frustration with IO proves my point.

Doesn't that prove my point, that there's an impedance mismatch of Elm trying to present a purely-functional world on top of a very side-effect-full environment of the browser+DOM etc.?

> but the practicality won't be apparent until you create a huge 10 million LOC monolithic SPA with elm

It sounds like you're arguing that for apps smaller than "absurdly large", plain JavaScript can be better.

Calling bs on anyone having anything approaching 10 million LOC in Elm. You're just making things up.

Edit: for reference, the Linux kernel has about 20 million LOC (according to Wikipedia), so you're talking about half a Linux kernel written in Elm. Absurd.

>Doesn't that prove my point, that there's an impedance mismatch of Elm trying to present a purely-functional world on top of a very side-effect-full environment of the browser+DOM etc.?

Your reply doesn't even address my point. That's all I'm saying. All I said is that I disagree with you.

>It sounds like you're arguing that for apps smaller than "absurdly large", plain JavaScript can be better.

>Calling bs on anyone having anything approaching 10 million LOC in Elm. You're just making things up.

>Edit: for reference, the Linux kernel has about 20 million LOC (according to Wikipedia), so you're talking about half a Linux kernel written in Elm. Absurd.

Don't ever call what I say absurd or BS that's plain offensive and against the principles here on HN. If you want me to continue replying to you, I'll need an apology otherwise I will ignore you.

Does BuckleScript do any runtime type checking? If not, you have the same problem the moment you call out into any pure JS library - your type annotations say what you expect, but JS code can merrily give you something else.

That just means the type annotations are incorrect, and how would runtime type checking solve that?

It wouldn't solve that, but it would prevent the code from running with data that is incorrect according to type annotations. Think of it as a runtime assert that is automatically generated from the compile-time type annotation.

(Unfortunately, the JS runtime object model does not allow for such runtime type checks to be performed with reasonable performance.)

I have to admit, as much as I enjoy working with TypeScript— this same problem is always on my mind. I find myself continually writing the same tests for type safety that I would in JS. I have to remind myself that, yes the types are safe while writing, but still not quite at runtime. It can lead to pretty fundamental flaws if you’re not careful.

I’m still amazed by how much faster transpiling from Reason is compared to TypeScript or JavaScript is via Babel.

Thank Bucklescript.

OCaml as a language is so close to a sweet spot between performance and ergonomics in my experience. I'm not sure if the Bucklescript compiler is generally running on Node or natively, but that could also be a big variable at play here.

Afaik it's native. The `bs-platform` node package contains native binaries.

regarding records specifically:

https://medium.com/@javierwchavarri/performance-of-records-i...

Reply on news.ycombinator.com