[garkin]

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]

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]

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

[chrisseaton]

> 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?

[jasim]

The type system is a lot more expressive than the ones found in Java/C#/C++, thanks to Algebraic Data Types.

Yaron Minsky (Jane Street, largest OCaml user) coined the term "make invalid states unrepresentable" to explain how ADTs help in enlisting the help of the compiler to help us express our intent correctly, and Richard Feldman (NoRedInk, largest Elm user) has given an absolute gem of a talk that dives into that idea with relatable, concrete examples.

It is titled "Making Impossible States Impossible" and should clarify this concept nicely. https://www.youtube.com/watch?v=IcgmSRJHu_8

[joshmarlow]

I've done a lot of work in Python and a fair amount of ocaml and rust.

I find that in Python - probably any dynamic language - a lot of the tests I write are just to make sure the pieces fit together. It's too easy to write well tested units that don't work together because of a misplaced argument or something at the interface. That type of testing is largely not needed with static typing.

Also, when I create a data structure in Python my mental model of what it means and how it relates to other parts of the program can be kind of fuzzy. Which means the pieces may not fit like I think they do because I missed a detail.

But a strong static type system forces me to clarify my thinking much earlier in the coding process than in a dynamic language. It encourages me to encode more of my mental model into the code and that allows the compiler to double check me.

It's kind of like spell check but for design.

[owl57]

I believe this claim to have two more narrow meanings:

1) If it compiles, you won't get a "undefined is not a function".

2) If it worked, you changed something and looked at all the places compiler told you to look at, all the code it didn't tell you to look at is very likely to continue to work corrrectly.

(1) is a very convenient feature and easy to advertise, but (2) is what makes people jump around and tell that everyone should use ML: it allows to be not afraid of changing something in the first place.

[owl57]

Data point. I just converted a small app to Elm 0.19. So, that's a real 0.x: breaking API changes all across the standard library. I just repeatedly ran the compiler and jumped to the next error. About an hour for my 1 KLOC app (and Elm code is pretty sparse), seems rather tedious. But! Now it works again, and I believe it to be working just as good as before. Of course there could be some new bugs, but I would rather expect them in the substantially changed parts of the Elm runtime than in my app where I didn't look at anything compiler didn't tell me to look at.

I have even less experience with OCaml, but my gut feeling is that it should be about the same in this respect unless you let mutable state run wild.

[kimsk112]

There is a phrase from Yaron Minsky about OCaml, “make illegal states unrepresentable”, which summarize this.

It's more about programming declaratively, functional, as well as strong types which allow you to be very expressive. My experience with F# is similar, if you can get you code compiled, it almost always just works as you expect. But this doesn't mean that you can avoid writing tests though.

This is a good read about it, https://fsharpforfunandprofit.com/series/designing-with-type... by Scott Wlaschin.

[monsieurbanana]

In my experience non-logic bugs vastly outnumber logic ones.

"Modern" dev is not about writing algorithms, it's about sewing together many different frameworks/libraries/technologies.

I'm probably biased as most of my experience is in webdev, but other domains seem to have the same issues (probably not to the same extend).

[jimmy1]

Out of curiosity, what are you considering modern?

The trend I see growing is towards microframeworks, smaller libraries, less dependencies (or if you have some, a small opinionated set of them), are more doing it yourself -- I think this phenomena, more simply put and was championed by go -- is to "just write code"

I am enjoying "just writing code" far more than my days as a library and framework glue person, and it is a lot easier to have other devs ramp up, as an added bonus. "Here, read this simple code to understand what's going on and then add your code" versus "here, study these docs, learn this framework, install all these dependencies then learn our coding style within the framework to understand what's going on, then add your code"

Gary Bernhardt kind of captures my sentiment these days with regards to massive libraries and frameworks these days in this thread nicely: https://twitter.com/garybernhardt/status/1037101314939875328

[srean]

I think this something that needs to be experienced firsthand a few times for this to sink in. It something like the backpropagation update of a neural network: no matter how long you stare at it, it wont be clear, but if you derive it yourself it becomes super clear.

I can say that this effect seems very real. I think the reason goes beyond those shallow type mismatch errors I often make. Part of the reason, I think is, the correct program becomes clearer to write compared to the erroneous programs you could have written if you use the type system. In other words types can make some of the erroneous versions cumbersome, or at time, impossible to write -- but good luck mud wrestling with the compiler till its convinced.

I will strongly encourage that you try it and dont be discouraged. This really needs to be experienced first hand to be convinced.

[kod]

The more meaning you can encode in the type system, the more the compiler can help you. It won't help you catch a + b... unless you e.g. declared a to be of type meters, and b inches.

[pjmlp]

Certainly regarding your example.

However in languages with rich type systems you can do Type Driven Development, which reduces the area space for many kind of errors.

Basically a simplified version of dependent typing, where one makes use of the type system to represent valid states and transitions between them.

For example, one can use ADTs to represent file states, with the file operations only compiling if the file handle is in the open state.

[edwintorok]

I think that statement is better viewed in lights of refactoring or changing existing code. If the code worked/compiled before, and I made a change that still compiles, I can be reasonably confident it didn't break something else accidentally (assuming the program was reasonably well designed to begin with). It makes reviewing pull-requests much easier.

Doing so in other programming languages always makes me nervous, in C an innocuous change could introduce some memory corruption bug because you broke an implicit invariant of the code, in Python it could raise a type error when called in an unexpected way. To review a pull-request you have to look usually at the entire file (or sometimes the entire project), and even then you can't be sure.

As for the logic bugs: that is what tests are for.

[arwhatever]

The compiler does not catch your logic bugs. But stronger, more expressive type systems catch syntax bugs and structural errors like you wouldn't believe. It's not an all or nothing.

I have spent an embarrassing amount of time troubleshooting a < that should have been a > (in F#) where it actually resulted in a very subtle defect. I'm not aware of a type system that works have prevented this and yet,I do strongly agree with the assertion that in more strongly/statically typed language, "compiling successfully = very likely to run correctly."

[camgunz]

It kind of applies to those languages. It more applies to languages like SPARK or Eiffel. But yeah like other posters have said, it's more about avoiding runtime errors.

[dmitriid]

> 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.

[b_t_s]

> type-related errors account for ~10% of bugs.

This sounds implausible to me unless they're only counting bugs that have slipped through QA and have later been fixed in production. In my experience the compiler catches maybe 95% of my errors I write. Most of those would be caught by my unit tests or my manual testing, and a few more would be caught by the QA team, but it's much nicer and faster to get notified about them immediately.

[neillyons]

> 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.

[jasone]

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).

[xfer]

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.

[adultSwim]

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

[nicoburns]

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.

[microtonal]

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

Though I am pretty confident that Rust will get there in a few years.

[claytonjy]

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.

[microtonal]

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.

[steveklabnik]

We do have people interested, but it's not a ton so far.

One big reason that numerics aren't the best in Rust right now is the lack of integer generics. Some people are waiting for that before bothering to write libraries, as they'd change the libraries so much anyways.

[lmm]

> I wouldn't recommend anything other than JavaScript/TypeScript for frontend stuff though.

My assumption was that anything else would be painful, but I tried some ScalaJS after one too many frustrations with TypeScript and was pleasantly surprised at how easy it all was.

[Rotareti]

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.

[bribri]

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