BuckleScript 8.1: new syntax option

#81

Well there are companies that are heavily relying on the fact that most code can be used for both native and frontend and especially that types are preserved. This isn’t a dream for a distant future, this is happening right now. BS becoming its own language with yet another syntax to support makes this kind of thing harder and it makes it complicated to consider BS a viable option for the future.

Plenty of efforts to make native and bs work well together, plenty of tooling that is adjusted to push for compatibility. And then out of nowhere we get another incompatibility, priority given to problematic tooling, random comments ignoring the work of many people.

#82

The new syntax looks great (less parens, yay!) and I really like the focus on better error messages (old versions of refmt were producing really bad errors messages, I think it’s fixed in the current one which is sadly not in BuckleScript).

What I’m really worrying about is the overall direction. There’s no clear statement on what’s the roadmap and instead a lot of hints mentioned around about BuckleScript becoming less OCaml and more an its own language. That’s both frustrating to me (I’d expect an opposite where BS and upstream converge eventually as I really value OCaml platform, but surely I don’t understand all the details) and puzzling — I feel like creating a new syntax is a challenging task (think of all tools, docs, editor integrations) but another language is even more so.

The ideal case in my mind is the following — we have a high performance, correct and with good FFI compiler from OCaml/Reason to JavaScript. We have it right now, it’s BuckleScript (I’m sure there are lots of things to improve but it’s working very well already). What I’m afraid of is that at some point in the future we will lose that. I want at least to understand what we will gain instead.

#83

Edit: too much noise. I’ll repost this properly in a new thread this week.

#84

Sorry you’re right. I was speaking solely about my use case. The companies who’re using both BuckleScript and native OCaml together are currently some of the heaviest users of the language and I feel have contributed much to it’s present adoption by way of code as well as by being success stories and building confidence in the ecosystem. For example I use the BuckleScript compatibility work you’ve done for atdgen for data interchange. Thanks.

On the other side, there are a large number of potential new users who would never use OCaml on native, or like me, would like to, but can’t afford to yet. Most of these users are moving to statically typed JS anyway, and it would be sad if that was to become a TypeScript monoculture. I think the new syntax and the JS-oriented direction of BuckleScript can present a very viable alternative to TypeScript here. I’m also not very surprised by BuckleScript’s direction because even though it wasn’t said explicitly, things like fast-pipe, Belt, Js object syntax, and work on improving generated data-structures interop etc. all pointed to that direction.

This is a difficult trade-off and I don’t think there are any good answers either way.

#85

I definitely echo a lot of the sentiment here. Went to bed excited about the new syntax changes but confused about the additional file extensions, thinking possibly due to managing a transistion to the new syntax, but not chuffed to find it all developed in the dark. But then wake up to find the real story:

Bucklescript definitely does look like it’s forking from Ocaml and this explains bob’s comments on discord recently about Bucklescript becoming it’s own language and the one above about rebranding Bucklescript.

The thing is how can we realistically build anything with the new Bucklescript (name to be confirmed) at the moment? It looks like from comments above that the Ocaml syntax will be dropped and the old Reason syntax will be dropped at one point or the other. (whether that be mid term or something else). And we have no idea what’s happening next.

The lack of leadership and communication is wokalski mentioning is pretty staggering. It’s seems clear from the above that although bob is consulted he doesn’t seem to be driving the direction, which is fine, but will the new owner or group please step forward.

It’s one thing to bet on a language like Ocaml which is fully developed in the open with commercial and non commercial backing which has a new syntax to help it’s popularity and injection of resources from FB.
To something that was once based on Ocaml but owned and developed by FB behind closed doors, with no clear roadmap and no clue of its commercial importance to FB and how long it might last.
FB has definitely earned a lot of open source credit through React , but this isn’t a library, it’s a language and that is a lot higher level of investment for people to come on board with.

Anyway I’m not trying to create a sense of drama but there are obviously higher risks to using a language tied to a single commercial entity than one that isn’t so steps to help us manage that risk, some greater transparency and some sort of roadmap, would be a great help here.
As mentioned on discord many of us just want to build great stuff and ship product but with the current limbo land created by this release it’s almost impossible to justify that commercial risk.

#86

I absolutely agree with your points.

What I would also add is that both BuckleScript and Reason are maintained largely by facebook / facebook employees.
So what worries me, is that one day or another one of them will be dropped to invest more into the other.

#87

I don’t understand why the two sides have to be opposed. I don’t see anyone complaining about a better/lighter syntax. The new reasonml website is basically 100% targeted at javascript users, and we sponsor it.

The question is more about why breaking again rather than getting Def to work on the reason parser? And what are the things that are so problematic they require a definitive fork of the language?

The syntax doesn’t matter too much to me. It evolves, great. But we need to have a better understanding of the direction taken by bucklescript and reasonml to be able to evaluate our usage. When I read “Indeed, I need check with Maxim what’s the rational behind this.” I wonder if there is actually a proper direction or if we are still at experimental stage. And who is actually making decisions?

I am not even complaining. It’s just that we need more information to provide a feedback that goes over “I like it it’s lighter”. Does it impact code sharing? Does it impact compatibility? How long do we have to port tools to the new syntax?

#88

That question is not for me then? It needs more internal context here than I’m privy to.

#89

Def doesn’t work at Facebook anymore and had a different task at Facebook altogether. Last I heard he was working on something completely different… I did enjoy working with him the brief moments when our projects crossed though. He’s a great person.

Since this concern is overcoming the actual feature itself, I’m gonna take the time to write up my thoughts on this matter this week. For all such concerns I’d ask you to please hold it back for the upcoming thread. Sorry for the frustration this caused.

#90

Some clarification on the leadership:

I am mostly in charge of things after parsing. I am not very interested in the syntax itself but I see some technical merits from the new parser:

  • It is hand written which gives us flexibility to improve the error message

  • It has zero dependencies, so it is really easy to embed into bucklescript itself and delivers better performance. The integration of refmt used to be a headache that I gave up and called it from an external processor and the sync up relies on community contribution – with the new parser I would be happy to do the sync up work.

#91

In the spirit of sharing community reaction, I would like to write my opinion on this.

I don’t have strong feelings about new syntax changes, if anything, let’s keep them coming (just maybe in a more planned way and on a predictable schedule).

What really worries me though is that this syntax experimentation feels out of place.
I would rather prefer being ‘annoyed’ by parens and semicolons, but have a better async story.

Or see bucklescript move towards better integration with the rest of the ecosystem: esy support for packaging and use of native ppxs, potentially switching to dune for builds, etc. Until vscode-ocaml-platform came around, I didn’t try bringing esy into bs projects. But now I see a million possible ways to have a great native tooling and infra story smoothly integrated with frontend/edge.

So my take is let’s bring bucklescript and ocaml native closer, not the other way. As others pointed out, bucklescript becoming a niche language with insular governance and incompatible with the larger ecosystem brings a risk of people reviewing their technology stack for future projects.

#92

The new syntax is great! But as others pointed out, is it possible to
avoid incompatibility the new syntax and its tooling has introduced?

I understand Bucklescript leadership has always battled conflicting requirements.
Balancing the JS/web community’s requirements with a language as old
as OCaml is not easy. But I do want to add here that there are folks
trying to bridge them.

From what I understand, authors of OCaml tooling want to accommodate Reason
community. Dune supports Reason syntax out of the box. Maintainers of
vscode-ocaml-platform were welcoming when I tried adding bucklescript
support to the plugin. But with the new direction, I find it hard to
initiate such reconciling efforts (for instance, without a merlin
plugin for the new syntax, ocamllsp wont work).

I really want to urge Buclescript leadership to reconsider this divide.

Apologies for making another post less about the syntax and more about
the broader direction. The care and pain you’ve taken to improve the
experience (for instance dissuading DSLs hard to reason about,
avoiding unnecessary currying with fun) is really appreciated. I
want to acknowledge this as well as the challenges in reconciling
conflicting voices/feedback - some of us have been going through this
as well :slight_smile: I think broader unification efforts will be really
rewarding.

#93

I won’t have time to read the whole discussion until tomorrow, so apologies for posting this out of context, but for now I would just like to say

This seems like it will fork the community pretty hard. “tasteful” is just asking for bikeshedding.

It will block those of us who make extensive use of custom infix operators from upgrading, unless the plan is for bucklescript to permanently support both reason and “bucklescript reason” which will be so confusing I don’t even know where to begin.

#94

@spyder one last reply before I go: these decisions can be remediated.

#95

I try to share my early thoughts about this change:

syntax:

  • :+1: Removal of semicolon: I like this, but leaving them optional may result incosistent codestyle among community, maybe completely remove them?

  • :+1: Less parentheses, less noisy code

  • :+1: Type arguments from from ('a) to <'a> : To be honest I may perefer parens personally since <T> is java-ish but it’s also more similar to ts / flow 's type arguments and also make distinction from function application. this change makes sense to me.

  • :+1: Interpolated strings: This is like scala’s string interpolation, I like it, more clear syntax.

  • :+1: Polymorphic variants: I have to play around with them. currently it lgtm.

  • :-1: Arrays and Lists: I Don’t like Arrays to be first class containers. Wrote more on this topic

  • :+1: Exception Handling: Nice change, more js friendly. I think it’s even more like ocaml’s try e with p

  • :-1: No custom infix: This is a language feature I really like. they are libraries out there using this to make easier / readble DSLs. I know and agree it can be abused and make codebases cryptic (just like single letter function names can, should compiler stop you from declaring them?) but this should be considered in project / problem / team context. a compiler option for enable/disable custom infix would be nice

  • :+1: Object access and implicit Js.t: no comment

  • :+1: New multiline strings: no comment

  • Currently I have no certain idea about other syntax changes, I may write about them later

The error messages as other folks said are super nice!

To be honest I don’t like this change to result in a new language/syntax option for bucklescript or ocaml platform in long term. I like to discuss about each part of the change, normalize them and make them compatible with reason/refmt 4 if possible. I think this approach has some benefits including but not limited to:

  • Sharing code between native / js. as being discussed some teams using this as well as some libraries like graphql ppx
  • Maintaining current ecosystem and help it grow, rather than creating a new ecosystem (Imagine this case: What should i google when I face a problem especially as a newcomer? reasonml, reasonscript.)
  • Separation may result in making bucklescript more javascript-ish (For example making array, a mutable data structure, first class container). I don’t want bucklescript to be just a better typescript

Thank you for all the effort :heart: :rocket:

P.S: It would be nice to have individual topic for each change to discuss like list and polymorphic variants topics

#96

How to use FCM in the new syntax?

It’s syntax error:

module type X = {let x: int}

let fn = (~x: (module X)) => {
  let (module X) = x
  X.x
};
#97

Reddit mentioned they are out…

#98

wat :anguished: why?.. This is literally the only way to pass module to a function. Dynamic imports, component as props. How to deal with it w/o FCM?

#99

Let’s wait for confirmation. I would be surprised if FCM are really being dropped by Res syntax.

#100

Jordan’s comment on discord “The BS syntax … trims out many of the advanced ocaml language features.” suggests that it might be correct.
Do FCM’s compile terribly to js, is that why they may be out?

I’m slightly worried we may be getting a lot less of a functional language than I first appreciated, no infix operators, arrays by default, the reckless currying comment, etc… hopefully that isn’t the case.