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

Type-safe GraphQL with OCaml

andreas.github.io

Post reply on HN
Print view View original

51–60 of 102 posts

Re: Type-safe GraphQL with OCaml

#51

Post by baddox »

kbenson wrote: post #45
kcorbitt wrote: post #4

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…

> The first is modular implicits: it feels so kludgy to have to type `a + b` for integers, `a +. b` for floats and `a ^ b` for string concatenation. I know it sounds like a small thing, but it makes the language feel inelegant, and aesthetics are important. That's interesting, as being forced to use the same operator for addition and for concatenation (and what's more with the result of mixed types if allowed often d…

Couldn’t the type system still allow using the + operator, but requiring the values on both sides to have the same type? You could do more magic like having int + float return a float, but I’d even prefer typing “int.toFloat + float” than “int +. float”.

Re: Type-safe GraphQL with OCaml

#52

Post by fny »

kbenson wrote: post #45
kcorbitt wrote: post #4

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…

> The first is modular implicits: it feels so kludgy to have to type `a + b` for integers, `a +. b` for floats and `a ^ b` for string concatenation. I know it sounds like a small thing, but it makes the language feel inelegant, and aesthetics are important. That's interesting, as being forced to use the same operator for addition and for concatenation (and what's more with the result of mixed types if allowed often d…

Isn't it also the case that floating point addition may not necessarily be commutative? I'd imagine there would need to be some standard to enforce it as such.

Re: Type-safe GraphQL with OCaml

#53

Post by bjz_ »

kcorbitt wrote: post #4

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…

> The second is a good concurrency story, ideally one that is compatible with JS-style async/await keywords for easy interop

Algebraic effects are also in the works which will help with stuff like async/await, but works over arbitrary effects (not just async). Like monads but nicely composable without the ickiness of MTL. Alas it's still unclear what the ETA is. :( Something I'm really looking forward to!

https://www.reddit.com/r/ocaml/comments/63hgid/tracking_mult...

Re: Type-safe GraphQL with OCaml

#54

Post by kbenson »

baddox wrote: post #51
kbenson wrote: post #45

Earlier quoted context omitted.

> The first is modular implicits: it feels so kludgy to have to type `a + b` for integers, `a +. b` for floats and `a ^ b` for string concatenation. I know it sounds like a small thing, but it makes the language feel inelegant, and aesthetics are important. That's interesting, as being forced to use the same operator for addition and for concatenation (and what's more with the result of mixed types if allowed often d…

Couldn’t the type system still allow using the + operator, but requiring the values on both sides to have the same type? You could do more magic like having int + float return a float, but I’d even prefer typing “int.toFloat + float” than “int +. float”.

Yeah, that's what I was referring to by explicitly converting one operand so they are like types. I too would prefer this in a language that takes typing of this sort seriously.

Re: Type-safe GraphQL with OCaml

#55

Post by jordwalke »

lilactown wrote: post #35
bad_user wrote: post #34

Earlier quoted context omitted.

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…

You're right in that ReasonML syntax is a bit of a moving target, but I think it's part of the initial pains of their effort to provide an approachable port into the ML world. The syntax should stabilize eventually. The maintainers are aware of the churn they are creating, and have deemed it worth it. That being said, I have a bunch of old projects written in Reason 2 (which still work; the tooling has preserved perf…

We provide tools to automate the upgrade between any two reason versions. It’s actually pretty trivial to keep up with changes due to refmt.

Re: Type-safe GraphQL with OCaml

#56

Post by johntran »

z3t4 wrote: post #38

Having spent my entire career, 15+ years, in "weakly typed" or whatever you call it, languages, such as basic, vbScript and JavaScript I don't get this type hype. In "unsafe" languages that have overflows I get it will help to make it less unsafe, but in high level languages such as JavaScript why do you even need static (not sure I'm using the right vocabulary) typing !? Such as HypeScript, err I mean TypeScipt. Is…

https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...

TL;DR: both Flow and TypeScript are pretty good, and conservatively either of them can prevent about 15% of the bugs that end up in committed code.

Re: Type-safe GraphQL with OCaml

#57

Post by jabot »

fny wrote: post #52
kbenson wrote: post #45

Earlier quoted context omitted.

> The first is modular implicits: it feels so kludgy to have to type `a + b` for integers, `a +. b` for floats and `a ^ b` for string concatenation. I know it sounds like a small thing, but it makes the language feel inelegant, and aesthetics are important. That's interesting, as being forced to use the same operator for addition and for concatenation (and what's more with the result of mixed types if allowed often d…

Isn't it also the case that floating point addition may not necessarily be commutative? I'd imagine there would need to be some standard to enforce it as such.

No, addition is still commutative (i.e. a + b == b + a)

Sadly, it is not associative (i.e. (a+b)+c != a+(b+c))

Imagine a being a large number, and b and c being so small that adding each single one to a will result in a, but adding their sum will result in just the smallest increment over a.

Re: Type-safe GraphQL with OCaml

#58

Post by hajile »

aaron-lebo wrote: post #2

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.

I wish SML were more popular. The syntax is much better and regular. I'll be done teaching you advanced SML language features before I could finish teaching the basics of ocaml.

SML also has a multithreaded implementation in polyml and a better compiler in mlton. The standard library is not big enough, but at least there aren't 4 like in ocaml (std, core, batteries, and container).

The only issue is that just a little more syntax would be nice, but the next gen group is working on that.

Re: Type-safe GraphQL with OCaml

#59

Post by kbenson »

jabot wrote: post #57
fny wrote: post #52

Earlier quoted context omitted.

Isn't it also the case that floating point addition may not necessarily be commutative? I'd imagine there would need to be some standard to enforce it as such.

No, addition is still commutative (i.e. a + b == b + a) Sadly, it is not associative (i.e. (a+b)+c != a+(b+c)) Imagine a being a large number, and b and c being so small that adding each single one to a will result in a, but adding their sum will result in just the smallest increment over a.

Actually, floating point addition isn't necessarily commutative[1][2], which is one of the problems of thinking of floating point as just a number. Although in this case, it's at least still addition, but the type of things being added have special conditions.

It's more like doing calculations on scientific notation, where there are special rules for how to keep the right number of significant figures/precision after operations. Like scientific notation, you would probably convert to one form or another (even if in your head) before doing the operation, and keep note of the possible loss of precision.

This is exactly the reason why adding floats to ints is something that people think should require an explicit conversion, so it's more obvious that's a point that may introduce loss of accuracy.

1: https://stackoverflow.com/questions/24442725/is-floating-poi...

2: https://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BinMath/a...

Re: Type-safe GraphQL with OCaml

#60

Post by jordwalke »

kornish wrote: post #41
Drup wrote: post #33

Earlier quoted context omitted.

Do you have concrete examples of things you are missing?

My biggest gripes are, in order: lack of library documentation, discoverability, maturity, and existence. Disclaimer: this is all anecdotal and the last time I dove into OCaml for side projects was about a year ago. 1. Documentation. Anecdotally, when you find a library that's not by Jane Street or top-20 starred on GitHub, the odds are low of finding a useful README or example code. God bless the developer if there…

This is some solid feedback, thanks for taking the time to write it up. I work on ReasonML, so a lot of this feedback describes problems we’d like to help the OCaml community solve. We are making progress on the popularity front by leveraging the JS ecosystem and it is proving to be an effective approach due to the size and openness of the JS community. Meanwhile the OCaml ecosystem (libraries, compilers, build systems(see jbuilder and its docs)) have been improving in the last two years so I would recommend checking it out sometime soon again.

I had a different experience with OCaml libraries. I’ve found some great gems in the OCaml ecosystem. For example, Menhir is an excellent parser generator used in Reason itself and it’s well documented and very powerful. I think many of these great pieces of the ecosystem stay hidden due to the exposure problem you mentioned, which comes back to popularity.

Another major missing piece of the library story was a way to build web apps using the most common web frameworks so we developed Reason React as part of the ReasonML project. https://reasonml.github.io/reason-react/ It’s definitely not a “bolted on” approach to React - it’s carefully thought out and in my opinion the API improves significantly upon React in ways that can only be done with language level type system features. Reason React is how I wish React always was.

Apologies for hijacking the GraphQL library thread to plug our project.

Post reply on HN