Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reason ML toolchain

khoanguyen.me

Post reply on HN
Print view View original

71–80 of 103 posts

Re: Reason ML toolchain

#71

Post by bsansouci »

aaron-lebo wrote: post #69
m0meni wrote: post #4

I've been following ReasonML pretty closely because, to me, it looks like the most promising compile-to-js language (functional, static types, but practical), and moreover, it can really bring a whole new set of people to the OCaml ecosystem, improving the tooling there. Idealistically, Reason is the language that lets you target any platform by either compiling to JS or native code. That said, I recently tried rewri…

One place you can see this in action is that [ ] are lists and [| |] are arrays. JS favors arrays, OCaml lists, so you either write dsls with [| |] (ugly), or you import a module and convert from lists to arrays and your bundle size goes up 80 KB (don't recall if minified or not). I was surprised to see Reason continue with this syntax. The idiomatic approach for either side is suboptimal unless I'm missing something…

What DSLs are you referring to here?

One reason to favor lists over arrays has been that they are immutable. Most of my personal JS array usages have been as dynamically sized arrays, because I’ll use .push all over the place. That usecase is the primary reason to use lists instead: it’s much faster to prepend and destructure on lists.

Re: Reason ML toolchain

#72

Post by bsansouci »

m0meni wrote: post #4

I've been following ReasonML pretty closely because, to me, it looks like the most promising compile-to-js language (functional, static types, but practical), and moreover, it can really bring a whole new set of people to the OCaml ecosystem, improving the tooling there. Idealistically, Reason is the language that lets you target any platform by either compiling to JS or native code. That said, I recently tried rewri…

I’d love to hear about better interop APIs. I think if there’s any way to make Bucklescript bindings easier, that would be tremendous.

In my experience, the crux of the difficulty actually comes from the JS APIs themselves working in a very JS-way, to be nice. Lots of DOM APIs rely on the dynamically typed nature of JS, making it super hard (probably impossible) to make statically typed bindings to.

Re: Reason ML toolchain

#73

Post by aaron-lebo »

bsansouci wrote: post #71
aaron-lebo wrote: post #69

Earlier quoted context omitted.

One place you can see this in action is that [ ] are lists and [| |] are arrays. JS favors arrays, OCaml lists, so you either write dsls with [| |] (ugly), or you import a module and convert from lists to arrays and your bundle size goes up 80 KB (don't recall if minified or not). I was surprised to see Reason continue with this syntax. The idiomatic approach for either side is suboptimal unless I'm missing something…

What DSLs are you referring to here? One reason to favor lists over arrays has been that they are immutable. Most of my personal JS array usages have been as dynamically sized arrays, because I’ll use .push all over the place. That usecase is the primary reason to use lists instead: it’s much faster to prepend and destructure on lists.

Something like Elm's Html module:

    div [ id "test" ] [ text "stuff" ]
vs

    div [| id "test" |] [| text "stuff" |]
If the JS library expects an array (not uncommon), that gets ugly quickly.

Re: Reason ML toolchain

#74

Post by aaron-lebo »

hazza1 wrote: post #67
splintercell wrote: post #53

Earlier quoted context omitted.

I have the same concern, what is the performance of these frameworks in comparison to Elm? Elm is super fast compared to React and Angular [1], but what about these frameworks? 1. https://www.codementor.io/rudolfolah/elm-vs-react-developmen...

Framework performance should rarely be an issue in normal use, by super fast you're talking about milliseconds of difference to toggle hundreds of todo item.

It's worth being aware that the Haskell approach (and quite a few of these functional langs) add a lot of size to your bundle.

Hello world in that Haskell library was 1 MB last time it was posted.

Re: Reason ML toolchain

#75

Post by ch4s3 »

anthonybullard wrote: post #62
ch4s3 wrote: post #57

Earlier quoted context omitted.

Yeah, bundle size isn't a real deal breaker, but it does make it a bit harder to roll into an existing project in small chunks. My main issue is the interop portion.

I'd like to hear about your pain points with interop. I'll more than likely be talking to Evan soon and I can discuss with him. Also, he's pretty responsive in general. The community is pretty eager to help with these sorts of pain points - join the Slack.

I think my biggest issue was the lack of any escape hatch for the development process. When you're trying to interop with JS and have to reason through the types that should be associated with the return value it can be a real slog if the JS returns a deeply nested object. I like that BuckleScript/ReasonML allows you to experiment with raw JS while figuring out the types.

Re: Reason ML toolchain

#76

Post by bjz_ »

frou_dh wrote: post #56
ch4s3 wrote: post #46

Earlier quoted context omitted.

My biggest gripes with Elm are cumbersome JS interop, and the fact that the output for a hello world when gzipped and minified is still 43kb.

As I understand it, the upcoming Elm 0.19 compiler will do dead code elimination for the output bundle.

Ah, that's great to hear!

Re: Reason ML toolchain

#77

Post by anthonybullard »

ch4s3 wrote: post #75
anthonybullard wrote: post #62

Earlier quoted context omitted.

I'd like to hear about your pain points with interop. I'll more than likely be talking to Evan soon and I can discuss with him. Also, he's pretty responsive in general. The community is pretty eager to help with these sorts of pain points - join the Slack.

I think my biggest issue was the lack of any escape hatch for the development process. When you're trying to interop with JS and have to reason through the types that should be associated with the return value it can be a real slog if the JS returns a deeply nested object. I like that BuckleScript/ReasonML allows you to experiment with raw JS while figuring out the types.

One thing to remember is that you only need to decode the fields that you need access to in elm. You don't have to reason about the whole data structure of it's not used in your program. But I feel you, in JavaScript you can just kind of wing it. But I think there a lot of value in the more deliberate approach. And for your work you are awarded with zero runtime exceptions - which is a pretty amazing guarantee which I've seen be largely born out in practice

Re: Reason ML toolchain

#78

Post by nv-vn »

kbenson wrote: post #49
nv-vn wrote: post #36

Earlier quoted context omitted.

Pure Reason exists, but you can just use `refmt` to convert any OCaml code to Reason (which isn't even necessary, since they both get compiled to the same thing and are stored in the same syntax tree).

What I was commenting on was the statement that being able to use Ocaml packages is a necessity , and specifically as a rebuttal to my saying being able to use them is a feature. The implication I get from that is that pure ReasonML to JS without Ocaml packages is not possible, which is why I asked. There of course may be some difference on what people consider an Ocaml package, but I would consider anything ReasonML…

Sorry, to clarify I mean that by design OCaml = Reason. The only way it would not be possible to link the two would be with artificial restrictions. Though they are very different looking, they share the exact same semantics, type system, module system, compiler pipeline, etc. Past parsing, the two languages become the same. I used necessity to mean that for ReasonML to exist, it must be possible (rather than that all Reason programs must necessarily import native OCaml code).

Re: Reason ML toolchain

#79

Post by nv-vn »

weberc2 wrote: post #43
nv-vn wrote: post #27

Earlier quoted context omitted.

Reason targets JS programmers. OCaml's toolchain is great honestly, it just seems like ~85% of Reason users are more focused on the JS parts of the language, so what happens is the new users from Reason don't really do much to contribute to the native toolchain (though any libraries they write can mostly be used with the native toolchain, which is really nice!). The other thing is, most of the compiler programmers ca…

> So in reality, it's a little bit crazy to expect the Reason users to be the ones rapidly changing the toolchain. That's too bad, because all of the marketing (at least around the time I initially looked into it) was something like "OCaml for humans". The JS bit was mentioned as a footnote, but then when I looked at it, JS was the primary target. I was half hoping that Reason would fix some problems that keep me (an…

I think it stands to fix the fragmented ecosystem by shear force. The masses will decide what will become the de facto standard. For now, it seems like jbuilder will be the winner.

Re: Reason ML toolchain

#80

Post by mlevental »

thangngoc89 wrote: post #25
mlevental wrote: post #16

started from quickstart and now we're here: ``` let message = "hello"; print_endline message; /* Prints "hello" */ ``` output $ bsb -make-world -w >>>> Start compiling Rebuilding since just get started ninja: Entering directory `lib/bs' [1/2] Building src/demo.mlast FAILED: src/demo.mlast /usr/local/lib/node_modules/bs-platform/lib/bsc.exe -pp "/usr/local/lib/node_modules/bs-platform/lib/refmt3.exe --print binary" -w…

`print_endline message` is version 2 syntax. Could you point me to the exact location so I can send a PR to fix it?

looks like you found it already. somewhere else it said also that compiled js is at lib/js. that's not true anymore (as i'm sure you know it's now at src/name.bs.js)
Post reply on HN