8 ms·

I tried ReasonML an year ago. It was very amusing to play with Variants, Pattern Matching and Units. If programm compiles - it almost always just works. It

by garkin 8y ago

I tried ReasonML an year ago. It was __very__ amusing to play with Variants, Pattern Matching and Units. If programm compiles - it almost always just works. It's an indispensable tool to play around and get more ideas how to write a better programs. And it was disastrous in __everything__ else. Installation and compiler bugs. Terrible tooling. Terrible code packaging. Terrible Javascript interop. Painfully archaic syntax. Sometimes extremely esoteric compiler errors. After a week i thrown out all the code and rewritten it using Typescript. Won't ever use new languages on projects with deadlines, no matter how sweet evangilists talks are.

PascalW 8y ago
I would encourage you to try it again. There were some big changes in ReasonML in the last year. I've picked up ReasonML about 3 months ago and experienced almost none of the issues you described. It's still a little rough around the edges compared to for example Elm, but the tooling, packaging, Javascript interop etc are really good IMO.
- jasim 8y ago
  We have built a design-to-code tool (Sketch to clean HTML & CSS) in Reason[1], and it has been the best experience ever in my 10 years of programming. We even used Reason for writing ObjectiveC/Cocoa through CocoaScript (a Javascript-to-ObjC bridge), thanks to Reason/BuckleScript's excellent Javascript interop. The language and compiler is rock solid - it has to be because it has been worked on for over 40 years from the days of ML. For the last three years a team of people including Hongbo Zhang, Jordan Walke, Cheng Lou and others have been actively working on Javascript tooling for OCaml, and it is an absolute pleasure to use today. [1] Protoship Codegen - https://youtu.be/hdww16KK8S8 https://youtu.be/hdww16KK8S8
chrisseaton 8y ago
> If programm compiles - it almost always just works. I can never understand this claim when people make it about languages like Haskell and ReasonML. How is the compiler catching your logic bugs? If you write 'a + b' and you should have written 'a - b' the compiler isn't going to catch that in either of those languages. It'll compile but it won't work. Do you never make these kind of logic bugs?
- dmitriid 8y ago
  > How is the compiler catching your logic bugs? It doesn't, and I agree with your sentiment. IIRC, type-related errors account for ~10% of bugs. If (and only if) types are tied into your tooling ecosystem (for example, an IDEs that uses that info to full extent to aid in code completion, refactoring, code analysis etc.), they are very useful.
  - neillyons 8y ago
    > It doesn't, and I agree with your sentiment. IIRC, type-related errors account for ~10% of bugs. I never thought of that, but that is a really valid point. I guess that is why Ruby/Python are so popular as most of the problems programmers run into in production aren't type problems.
    - xfer 8y ago
      That is not why these languages are popular. Types are your design document in languages with expressive type system. So by design you can make it hard to make logical errors.
    - jasone 8y ago
      Type correctness is pure power, or a waste of time, depending on... perspective! I can't help thinking back to the highly illustrative example of my first enhancement to Facebook's production website as a "bootcamper" in 2009. I was tasked with adding proper honorifics for Japanese speakers (it's complicated in the general case, but I was just getting as far as "San"). I wrote some straightforward PHP code to implement this feature, but of course it broke in production for some nontrivial percentage of requests. Why? Because the string I was adding the honorific to wasn't always a string. WTF? What is the proper course of action when strings aren't strings? Well, in this case the answer was a run-time type-check guard on the code I had added. Keith Adams, my esteemed colleague, likened this to "dogs and cats living together", perhaps revealing a fondness for simpler days when Ghostbusters trod the streets. Keith may not have gone as far as lauding OCaml's type system in those dark early days, but I will do so now (and perhaps he would too).
  - 8y ago
adultSwim 8y ago
Python programs are easy to start but ML programs are easy to finish.
nicoburns 8y ago
You might want to try Rust. It has a lot of the ML niceties but with a modern syntax and pretty good tooling. I wouldn't recommend anything other than JavaScript/TypeScript for frontend stuff though.
- danieldk 8y ago
  I am writing Rust more or less daily for my research code (in machine learning & natural language processing), but be prepared to implement a lot of functionality yourself or bind C libraries. The numerical computing/machine learning ecosystem is still very young/small on Rust. http://www.arewelearningyet.com http://www.arewelearningyet.com Though I am pretty confident that Rust will get there in a few years.
  - claytonjy 8y ago
    have you talked/written about this in a longer form anywhere? I'd love to read how you got into this if so. There's plenty of Rust-talk here on HN, and plenty of numerical/ML talk, but they seems like very non-overlapping user groups. Particularly curious why you chose Rust over Julia or even Go, given that (to an outsider) both seem to have a lot more people excited to do ML with them.
    - danieldk 8y ago
      I currently don't really have time currently to write this up in a blog post or article. As the state of the field is, it is often handy to be able to bind to C or C++ libraries (such as liblinear, Tensorflow, etc.). I used to use Go when Rust 1.0 was not out yet. I was generally happy with Go. My primary gripes were: (1) C calls are relatively expensive, which is ok for long-running functions (e.g. run a Tensorflow session), but now nice for calling C code in a tight loop. (2) Go gives no control over memory alignment, while C++ machine learning libraries generally prefer alignment on a certain boundary. IIRC Go aligns slices on a 16-byte boundary and Eigen (which is used on Tensorflow) wants arrays that are aligned on a 32-bit boundary. I don't know if this is still true, but Tensorflow used to make a copy of an array that was incorrectly aligned. So, you had to resort to doing allocation in C and then using the SliceHeader hack to give the array somewhat of a native Go interface. But since the backing memory is allocated in C-land and Go does not have general destructors (only defer), you have to rely on finalizers to do deallocation (which provide no guarantee when they are called) and/or relying on the user to explicitly call a resource deallocation method. Of course, that does not really gel well with slices. (3) Rust + LLVM optimizes far better than the Go compiler. This is not a secret. Parametric polymorphism provides much more opportunities for inlining than dynamic dispatch and LLVM inlines and optimizes aggressively. I spent a lot of time compiling compiled Rust and compiled Go assembly and the differences are quite shocking. That said, the Go people have been working on better inlining as of recently and with the possibility of generic in Go 2.0, things will probably get better. That said, I think that in larger teams, Go may still be the better choice. It is easier to pick up. It is harder to make code that is 'too clever'. It has good packages, such as gonum, which provides a lot of linear algebra functionality and functionality for plotting. Tensorflow has direct support for Go, including for building computation graphs, etc. I would love to try Julia! But I did not progress much beyond the first few steps of the tutorial ;). I think I would like it much for quick exploration in the vain of Python + numpy.
bribri 8y ago
I'm loving reason so far and like it a lot more than typescript.
Rotareti 8y ago
I just finished a ReasonReact project which I started about 3 month ago and I found the experience quite nice (working with VSCode). ReasonML is still in an early stage, but I prefer it over JS/TS for React frontends. The language is a great fit for React. The only thing that I was missing was the amount of Q&A that I'm used to from JS/TS.

I tried ReasonML an year ago. It was __very__ amusing to play with Variants, Pattern Matching and Units. If programm compiles - it almost always just works. It

by garkin 8y ago

PascalW 8y ago

I would encourage you to try it again. There were some big changes in ReasonML in the last year. I've picked up ReasonML about 3 months ago and experienced almost none of the issues you described. It's still a little rough around the edges compared to for example Elm, but the tooling, packaging, Javascript interop etc are really good IMO.

jasim 8y ago
We have built a design-to-code tool (Sketch to clean HTML & CSS) in Reason[1], and it has been the best experience ever in my 10 years of programming. We even used Reason for writing ObjectiveC/Cocoa through CocoaScript (a Javascript-to-ObjC bridge), thanks to Reason/BuckleScript's excellent Javascript interop. The language and compiler is rock solid - it has to be because it has been worked on for over 40 years from the days of ML. For the last three years a team of people including Hongbo Zhang, Jordan Walke, Cheng Lou and others have been actively working on Javascript tooling for OCaml, and it is an absolute pleasure to use today. [1] Protoship Codegen - https://youtu.be/hdww16KK8S8 https://youtu.be/hdww16KK8S8

chrisseaton 8y ago

> If programm compiles - it almost always just works. I can never understand this claim when people make it about languages like Haskell and ReasonML. How is the compiler catching your logic bugs? If you write 'a + b' and you should have written 'a - b' the compiler isn't going to catch that in either of those languages. It'll compile but it won't work. Do you never make these kind of logic bugs?

dmitriid 8y ago
> How is the compiler catching your logic bugs? It doesn't, and I agree with your sentiment. IIRC, type-related errors account for ~10% of bugs. If (and only if) types are tied into your tooling ecosystem (for example, an IDEs that uses that info to full extent to aid in code completion, refactoring, code analysis etc.), they are very useful.
- neillyons 8y ago
  > It doesn't, and I agree with your sentiment. IIRC, type-related errors account for ~10% of bugs. I never thought of that, but that is a really valid point. I guess that is why Ruby/Python are so popular as most of the problems programmers run into in production aren't type problems.
  - xfer 8y ago
    That is not why these languages are popular. Types are your design document in languages with expressive type system. So by design you can make it hard to make logical errors.
  - jasone 8y ago
    Type correctness is pure power, or a waste of time, depending on... perspective! I can't help thinking back to the highly illustrative example of my first enhancement to Facebook's production website as a "bootcamper" in 2009. I was tasked with adding proper honorifics for Japanese speakers (it's complicated in the general case, but I was just getting as far as "San"). I wrote some straightforward PHP code to implement this feature, but of course it broke in production for some nontrivial percentage of requests. Why? Because the string I was adding the honorific to wasn't always a string. WTF? What is the proper course of action when strings aren't strings? Well, in this case the answer was a run-time type-check guard on the code I had added. Keith Adams, my esteemed colleague, likened this to "dogs and cats living together", perhaps revealing a fondness for simpler days when Ghostbusters trod the streets. Keith may not have gone as far as lauding OCaml's type system in those dark early days, but I will do so now (and perhaps he would too).
- 8y ago

adultSwim 8y ago

Python programs are easy to start but ML programs are easy to finish.

nicoburns 8y ago

You might want to try Rust. It has a lot of the ML niceties but with a modern syntax and pretty good tooling. I wouldn't recommend anything other than JavaScript/TypeScript for frontend stuff though.

danieldk 8y ago
I am writing Rust more or less daily for my research code (in machine learning & natural language processing), but be prepared to implement a lot of functionality yourself or bind C libraries. The numerical computing/machine learning ecosystem is still very young/small on Rust. http://www.arewelearningyet.com http://www.arewelearningyet.com Though I am pretty confident that Rust will get there in a few years.
- claytonjy 8y ago
  have you talked/written about this in a longer form anywhere? I'd love to read how you got into this if so. There's plenty of Rust-talk here on HN, and plenty of numerical/ML talk, but they seems like very non-overlapping user groups. Particularly curious why you chose Rust over Julia or even Go, given that (to an outsider) both seem to have a lot more people excited to do ML with them.
  - danieldk 8y ago
    I currently don't really have time currently to write this up in a blog post or article. As the state of the field is, it is often handy to be able to bind to C or C++ libraries (such as liblinear, Tensorflow, etc.). I used to use Go when Rust 1.0 was not out yet. I was generally happy with Go. My primary gripes were: (1) C calls are relatively expensive, which is ok for long-running functions (e.g. run a Tensorflow session), but now nice for calling C code in a tight loop. (2) Go gives no control over memory alignment, while C++ machine learning libraries generally prefer alignment on a certain boundary. IIRC Go aligns slices on a 16-byte boundary and Eigen (which is used on Tensorflow) wants arrays that are aligned on a 32-bit boundary. I don't know if this is still true, but Tensorflow used to make a copy of an array that was incorrectly aligned. So, you had to resort to doing allocation in C and then using the SliceHeader hack to give the array somewhat of a native Go interface. But since the backing memory is allocated in C-land and Go does not have general destructors (only defer), you have to rely on finalizers to do deallocation (which provide no guarantee when they are called) and/or relying on the user to explicitly call a resource deallocation method. Of course, that does not really gel well with slices. (3) Rust + LLVM optimizes far better than the Go compiler. This is not a secret. Parametric polymorphism provides much more opportunities for inlining than dynamic dispatch and LLVM inlines and optimizes aggressively. I spent a lot of time compiling compiled Rust and compiled Go assembly and the differences are quite shocking. That said, the Go people have been working on better inlining as of recently and with the possibility of generic in Go 2.0, things will probably get better. That said, I think that in larger teams, Go may still be the better choice. It is easier to pick up. It is harder to make code that is 'too clever'. It has good packages, such as gonum, which provides a lot of linear algebra functionality and functionality for plotting. Tensorflow has direct support for Go, including for building computation graphs, etc. I would love to try Julia! But I did not progress much beyond the first few steps of the tutorial ;). I think I would like it much for quick exploration in the vain of Python + numpy.

bribri 8y ago

I'm loving reason so far and like it a lot more than typescript.

Rotareti 8y ago

I just finished a ReasonReact project which I started about 3 month ago and I found the experience quite nice (working with VSCode). ReasonML is still in an early stage, but I prefer it over JS/TS for React frontends. The language is a great fit for React. The only thing that I was missing was the amount of Q&A that I'm used to from JS/TS.