5 ms·

With Bucklescript/Reason you get typesafety, immutability, performance and small codesize: >Now we compare the runtime performance: BuckleScript Immutable

by scns 8y ago

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-bucklescript-matters-for-Javascript-platform https://github.com/BuckleScript/bucklescript/wiki/Why-buckle...

tybit 8y ago
I’m still amazed by how much faster transpiling from Reason is compared to TypeScript or JavaScript is via Babel.
- Scarbutt 8y ago
  Thank Bucklescript.
- nv-vn 8y ago
  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.
  - PascalW 8y ago
    Afaik it's native. The `bs-platform` node package contains native binaries.
scns 8y ago
regarding records specifically: https://medium.com/@javierwchavarri/performance-of-records-in-bucklescript-ecf6566fff5c https://medium.com/@javierwchavarri/performance-of-records-i...
incadenza 8y ago
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?
- crimsonalucard 8y ago
  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.
  - kbd 8y ago
    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.
    - crimsonalucard 8y ago
      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.
      - kbd 8y ago
int_19h 8y ago
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.
- baddox 8y ago
  That just means the type annotations are incorrect, and how would runtime type checking solve that?
  - int_19h 8y ago
    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.)
- 52-6F-62 8y ago
  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.

by scns 8y ago

tybit 8y ago

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

Scarbutt 8y ago
Thank Bucklescript.
nv-vn 8y ago
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.
- PascalW 8y ago
  Afaik it's native. The `bs-platform` node package contains native binaries.

scns 8y ago

regarding records specifically: https://medium.com/@javierwchavarri/performance-of-records-in-bucklescript-ecf6566fff5c https://medium.com/@javierwchavarri/performance-of-records-i...

incadenza 8y ago

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?

crimsonalucard 8y ago
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.
- kbd 8y ago
  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.
  - crimsonalucard 8y ago
    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.
    - kbd 8y ago

int_19h 8y ago

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.

baddox 8y ago
That just means the type annotations are incorrect, and how would runtime type checking solve that?
- int_19h 8y ago
  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.)
52-6F-62 8y ago
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.