31–40 of 102 posts
I wish OCaml had the libraries and community of Go or Rust, I think it'd be the most useful all-around language out there.
If ReasonML is able to form a real community, I have high hopes for its long-term prospects. Such an enjoyable language to use! I think their general approach of bootstrapping a community by lowering impedance with the JS ecosystem is a decent one. In case anyone on the OCaml team is reading this though, there are two language-level changes that I think could do wonders for wider adoption. The first is modular implic…
You might like to try Fable and F#. I’ve been looking at it since playing with Reason and Bucklescript, and so far I’ve found Fable much easier to use and more featureful. The syntax is essentially the same as OCaml, plus it’s whitespace aware. F# has implicit `+` for basic types (though it’s not quite modular implicits). It also has a really nice syntax for async computations, similar to `async/await`. JS interop is…
This is a problem because when type inference kicks in for plain functions, usage of that "+" will make the compiler assume "int".
But worse, "+" in C# is not a method, but a static method and the compiler basically does magic, because you don't have this behavior for plain static methods and you don't have a generic interface in the language for "+", there's no Number, no Monoid and static methods themselves in C# can't be polymorphic.
The whole notion of "static methods" is broken btw and have nothing to do with OOP. The only purpose of static methods is to enforce visibility rules and this made some sense in C++, where you could have functions living outside of classes, but even there the real problem is the lack of useful namespacing.
And F# inherited this behavior, F# inherited static methods, along with math operators described as static methods.
So in order to abstract over things that have "+", which is really needed in F# otherwise you can't express really basic things for an FP language like "List.sum", you have to (1) use inline functions, which aren't translated directly to .NET functions and (2) use a really awkward signature that instructs the type system that the type has a "+" static method that it can use, e.g...
> let sum x y = x + y;;
val sum : x:int -> y:int -> int
> let inline sum x y = x + y;;
val inline sum :
x: ^a -> y: ^b -> ^c
when ( ^a or ^b) : (static member ( + ) : ^a * ^b -> ^c)
This is close to how type classes work in other languages, however for the F# compiler this is magic that doesn't scale and making use of "static methods", a flawed concept, a signature that can't be encoded in .NET's type system and therefore the function is forced to be "inline".
Which is another problem, because in F# inline functions are more like macros, or in other words these "inline" functions are not values. As soon you try using one as a value, it gets materialized and you loose the type info. So it is very ephemeral.
Given this, frankly, I would rather have OCaml's operators. At least they are plain functions.
Earlier quoted context omitted.
What exactly are you talking about? OCaml has decent libraries for almost everything that you want to do. What exactly are you missing?
"decent" and "almost" are generous, and it's completely realistic to say that Go, Java, Python, and Ruby's ecosystems far outshine OCaml's. Love it as a language, but the ecosystem and community have a ways to go before even slightly widespread adoption.
Earlier quoted context omitted.
I really don't understand why they had to invent a brand new syntax.
The short answer is that Reason's syntax is simpler and more enjoyable to use. I simultaneously learned both OCaml and ReasonML syntaxes and find Reason to be much easier to work with. Perhaps people in Reason core will chime in with a more detailed answer. Here's some official information: https://reasonml.github.io/guide/ocaml/
And the differences are very superficial. What trips people is not the actual syntax, but the concepts learned, the rules of the type system, scoping rules, etc, which don't change.
I'm glad that ReasonML exists, but personally I would use OCaml instead of risking that my codebase gets stuck with an old release after only six months because the current version now has different opinions about how to express anonymous functions.
Earlier quoted context omitted.
The short answer is that Reason's syntax is simpler and more enjoyable to use. I simultaneously learned both OCaml and ReasonML syntaxes and find Reason to be much easier to work with. Perhaps people in Reason core will chime in with a more detailed answer. Here's some official information: https://reasonml.github.io/guide/ocaml/
OCaml's syntax on the other hand is stable, whereas it is my impression that ReasonML changes with the same frequency that JS libraries are changed. And the differences are very superficial. What trips people is not the actual syntax, but the concepts learned, the rules of the type system, scoping rules, etc, which don't change. I'm glad that ReasonML exists, but personally I would use OCaml instead of risking that m…
That being said, I have a bunch of old projects written in Reason 2 (which still work; the tooling has preserved perfect backwards compatibility[0]), and recently started a new project using the new Reason 3 syntax. It was easy enough to pick up the new syntax in about a day. I haven't done it yet, but my understanding is that it's completely automated[1].
Earlier quoted context omitted.
I think the problem isn't that + +. and ^ look different, it's that they are symbols. That's also what makes scala so unapproachable, you get stuff like ++> or =*= that doesn't make any sense. x + y makes sense to most people x ^ y not so much
Do you write Scala, or have you even looked at Scala code any time in the past few years? I'm curious where this habit of spreading FUD over Scala being operator heavy came from. Maybe it was back when it first started reaching the HN front-page or something? Scala is a super approachable language, without any (that I can think of) strange operators in the stdlib. You could make a case for Cats, I guess, but writing…
I never was a fan of the JVM stuff and Scala seemed like a reasonable alternative to Java, but I never got it.
Earlier quoted context omitted.
You might like to try Fable and F#. I’ve been looking at it since playing with Reason and Bucklescript, and so far I’ve found Fable much easier to use and more featureful. The syntax is essentially the same as OCaml, plus it’s whitespace aware. F# has implicit `+` for basic types (though it’s not quite modular implicits). It also has a really nice syntax for async computations, similar to `async/await`. JS interop is…
The "+" in F# is really awkward because it tries catering to both the ML type system it got and to the .NET type system underneath, inherited from C#. This is a problem because when type inference kicks in for plain functions, usage of that "+" will make the compiler assume "int". But worse, "+" in C# is not a method, but a static method and the compiler basically does magic, because you don't have this behavior for…
It is not much different from class messages in Smalltalk.
If ReasonML is able to form a real community, I have high hopes for its long-term prospects. Such an enjoyable language to use! I think their general approach of bootstrapping a community by lowering impedance with the JS ecosystem is a decent one. In case anyone on the OCaml team is reading this though, there are two language-level changes that I think could do wonders for wider adoption. The first is modular implic…
I'm a JS developer who tried to adopt Reason for a full stack side project in September. There is so much to love about the language and ecosystem. After about a week I decided to start over in TypeScript for a single reason: the awkward interop with promises compared to async/await, which is now available in evergreen browsers and Node 8 without compiling down. I'll definitely try again once this is ready.
I tried it with React-Native but found it a bit cumbersome to get it to interact with existing components in Reasons JSX