5/27/2018 19:46:19

Austria, Vienna

Yes

JavaScript, PHP, Ruby, Elixir

Elixir, Elm

Nice people, good learning experience

Obscure compiler messages

Using array.map instead of list

Map

No

5/27/2018 19:52:54

Austria, Vienna

Yes

C++, Flow, Java, Rust

Reason, Wolfram Language (Mathematica)

nice people, nice please, nice programming, Timo

sometimes we felt a bit stuck

writing bindings with abstract types

Option 1

yes! 1. often the editor would not reflect the current compiler state, still displaying errors that were not real; 2. refmt sometimes didn't work for unknown reasons

at least one where we forgot parentheses around an Array.map function call in JSX (to create children)

how to use abstract types (how to create them and how to access fields)

less error-prone editor integration

real-world data fetching; maybe to write Reason for the server

5/27/2018 19:53:18

Austria, Vienna

Yes

flow

reason

Jan, Timo, nice people, getting knowledge in writing bindings

vienna 26 degrees celcius

abstract types, how to properly configure bindings

Option 1

rfmt didn't work all the time, out of sync

Array.map function call where only writing an additional function to create markers worked instead of using the functionality directly in JSX. Probably not proper use of brackets

how abstract types are used properly

bindings in general, ecosystem(editor errors sometimes confusing), error handling with jsx code

how to properly fetch data with Reason

5/27/2018 19:54:44

Austria, Vienna

Yes

Java, Fortran, C, C++, Kotlin

The community aspect, I loved that results became visible for everyone on the map and that much of the groundwork like POSTing and GETting has been done for you.

Regarding the toolchain, sometimes you get tripped up by the UNKNOWN SYNTAX ERROR, but otherwise it's been ok.

Array vs List, always using Array when interacting with JavaScript is not explicitly mentioned in the docs. I think it's mentioned, but in between the lines.

I probably missed something, but the shadowing part of type name vs parameter name tripped us up in the beginning and it wasn't perfectly clear why that's the case.

Writing bindings, shadowing.

Nope, has been quite lovely this time around!

UNKNOWN SYNTAX ERROR

In the concrete case where the response body string => JSON => Reason records conversion is taking place. I know it's in the Fetcher, but after ReasonConf I thought I'd always have to use `Json.Decode` or `location##username` etc.

I guess part of it was that the Fetcher was supposed to be a blackbox anyway and from the type definition it was clear that we already get records.

Another thing was https://reasonml.github.io/reason-react/docs/en/element-type-is-invalid.html which is documented, but it also tripped us up. I'm not sure if the tooling can improve this, but it would be nice.

More bindings for popular libraries publicly available and community maintained. But this is a community effort anyway. But since we spent a lot of time writing bindings, this would be the best thing to have.

Typed server code. Maybe form validation. Nothing where I have to write a UI myself :D

That's also a big plus for this dojo, the styles were already defined.

5/27/2018 19:56:48

Austria, Vienna

Yes

Scala, Java

Scala

Learning in practice, meeting people already using Reason for projects

Manually having to write bindings! ;-)

Writing bindings... ;-)

merlin configured by default --> "reason.diagnostics.tools": ["bsb"]

Error: 955: <UNKNOWN SYNTAX ERROR>

Developer experience: having to pass unit () at the end of a function with optional labelled parameters

An webapp!

5/27/2018 23:08:53

Belgium, Brussels

Yes

Java, C, C++

the autocomplete, the reducerComponent, no need for imports <3, the fact that the language has refmt <3 (no need to engage in big fights about who has the better style :D)

That for some reason in my mind reason is close to javascript when it's really not.

Writting the binding for the react-simple-maps was a big pain for me as beginner.

Also the doc for someone that is not used to read functionnal programming documentation, it is not very easy.

The ~ is not the best on a non US keyboard.

ReactDOMRe.Style.make(~width="100%", ~maxWidth="980px", ~margin="0 auto", ())) that kind of code is painful to write, I wish the compiler could add the last param () automatically.

[0, 20] vs [|(0), (20)|] as javascript developer I would have prefered if the first one was the array and not the list :D

Bindings javascript -> reason

no

yes, the <UNKNOWN SYNTAX ERROR>

60 ┆ <Markers>

61 ┆ <Marker

62 ┆ marker=marker

63 ┆ style={{

64 ┆ default: ReactDOMRe.Style.make(~fill="#FF5722", ()),

This has type:

{. "coordinates": array(float), "markerOffset": int, "name": string}

But somewhere wanted:

MyProjectName.Marker.markerT (defined as MyProjectName.Marker.markerT)

Could not find what was wrong on that one

interop, it was not easy to find how to write

[@bs.module "react-simple-maps"]

external geographies: ReasonReact.reactClass = "Geographies";

As a react developer I would say the availability of interop for most mainstream library. I have the general feeling that TypeScript is more popular than flow just because they have a huge typings community.

A complex ui with animations if possible

5/27/2018 23:21:18

France, Paris

Yes

Haskell, Flow.js

Haskell, Elixir

Being led, getting help on encountered issues, meeting (nice) people, getting started on ReasonML

I didn't dislike it, but some problems were a bit frustrating in the rush

In bindings

VSCode is not always up to date with Merlin, thus showing errors that are non-existent.

When we use a component, we don't see the props it's waiting for.

In-editor messages are far less clear than those showing up in the terminal.

Reduce the amount of apis, make them more consistent. Ease the binding process

Video games would be fun

5/28/2018 9:13:53

France, Paris

Yes

Flow, Typescript, Java, C#, Swift

JS?

Gave me a very clear view about the state of Reason right now

Found it a bit too much like a mysterious puzzle, since I never knew what to look up

Bindings with the React library

editor plugin sometimes came out of sync so had to close and reopen files

unknown syntax error when doing things which aren't possible in reason (forgotten semicolons, using braces instead of brackets)

didn't really use the documentation, bindings doc is a little light https://reasonml.github.io/reason-react/docs/en/interop.html could have some more complex examples and links to how to used published ones

stdlib using more JS stdlib would be cool; Array.mapi and mapWithIndex, map could be a single fn with an optional I right?

something usable from JS as a third party (without any knowledge of Reason in the JS bits)

5/27/2018 19:34:46

Netherlands, Amsterdam

Yes

Typescript

Being able to have people around and ask questions

The format could've been a little bit more specific in terms of hints. There's a few 'gotchas' which were very hard to find out. (like shadowing type names)

creating the bindings for the external library

Just some vague error messages sometimes. When shadowing, or a syntax error

The error message when a type with @bs-derive annotation has the same name as it's parent property

There are some language features, like the different pipe operators '|>' vs '|.'

I think error messaging around syntax errors will be very important, as people coming from other languages might not know all the intricacies.

I would like to go closer to real world applications. Like a backend (node server), react native app, etc.

5/27/2018 21:11:51

Slovakia, Bratislava

Yes

JS

Very helpful mentors! Opportunity to learn something new

I think there should be requirement for each participant in a dojo to spend at least 15minutes studying Reason/BS docs before attending. I think it's very frustrating (not talking about myself, but my teammates) for people hopping into the dojo not having previously read at least about basic Reason types and BS annotations.

Writing bindings, specifically getting to understand what do [@bs.deriving abstract] annotations produce

Not something noteworthy

I dont remember any

Event participation prerequisities - as I said, I would like participants to have at least read about Reason types and BS annotations at least a little before attending.

To make writing bindings more straighforward

Unikernels, Backend stuff

5/27/2018 20:47:08

Sweden, Göteborg

Yes

Reason, Elm

Reason, Elm, Elixir

It was a fun project and it was fun to try to spread reason to others

I feel like we should not have worked as much with interop because we didn't sell the nice parts of reason to the newcomers.

Issues with bindings, bs.abstract shadowing gotchas

Not really

We had a issue where we had ReasonReact.Update({ users }) and that gave us weird errors that were hard to debug

The shadowing when using bs.deriving and maybe some examples of bindings to components that are more complex

I think we just need more finished bindings/libraries at this moment

5/27/2018 19:33:51

Sweden, Stockholm

Yes

Elm, java, c#, typescript, php, flowtypes

Elm,

Welcoming community

A little bit difficult problem to solve for people with little/no reason experience. Maybe have a problem next time that focus more on core principles in ml type languages.

Working with the interlop functionality

Nope

Field of record errors

Recolds

5/27/2018 19:40:34

Sweden, Stockholm

Yes

TypeScript, Haskell

Haskell

Meeting people with a common interest and solving problems with them. People!

The editor installation path took a bit long.

Modelling the data received from the API and learning about bs-fetch interop and learning about type systems.

Editor plugins seems to be a bit hard to setup with a previous ocaml installation on the computer.

The hardest ones are the tiny ones, missing a comma in a react component, missing semi colon etc. “Error on line 1 0:0”.

We did not read much documentation. The editor tools themselves helped us a lot, being able to go to the definition of most modules was really helpful.

Precious ocaml and opal installations not conflicting with the reason-cli installation, this seemed to be our biggest blocker and lot of people resorted to the legacy reason plugins.

The type system! I think “making illegal states unrepresentable” is a great thing to showcase, especially for fetching data.

5/28/2018 9:59:04

Sweden, Stockholm

Yes

Pascal, C, C++, Java, C#, Golang, Haskell, OCaml, Elm

Clojure, Haskell, OCaml, Elm

The dojo task was interesting because it had a couple of different subtasks so that you could choose one and jump in the deep end.

Not having any particular JS or React experience (besides what I've gathered from reading off the web and staying up to date), it was frustrating that the tasks were more about React than about Reason itself.

Figuring out how to interop Reason and React

Option 1

No, they worked surprisingly well.

Yes, the message about undefined field (because you had forgotten to open the containing module) was not too obvious. To my surprise we didn't get any error message at all when we tried to do List.map instead of Array.map. It actually worked, but produced the wrong result.

I can't really tell yet. I feel like the documentation overall is quite good, but plenty of knowledge of React seems to be expected. That's fine of course as long as there's a big label somewhere warning the reader so that they know that they need to check other sources too.

As with any fairly new language it was difficult to find answers to questions that were not discussed in the documentation. Surely the situation will improve over time.

Backend stuff!

5/28/2018 12:45:40

Russia, Moscow

Yes

TypeScript

More strict types

Not usable with React

Write bindings to React

No

I get sometimes Unknown Error

native

Types, more friendly like TypeScript

Native

5/28/2018 13:07:00

Russia, St.Petersburg

Yes

F#

F#

New FP language, nice people

Format of the event - better it was simple workshop.

No one told about language.

Interop with JS

Option 1

No

Only in VSCode

No

Base features of the language

5/28/2018 13:11:33

Russia, St.Petersburg

Yes

OCaml, C++, C#, Haxe

OCaml

I got the task which should be done in limied time and that fact prevents procrastinating

Task is not very interesting, it doesn't describe that Reason is better that anything else. A lot of type annotations for simple task discourage from using typed languages.

Binding to these 4 components from simple-react-maps.

It will be great to add a quickfix that changes syntax from structure access `identifier.Modulename.field` to lens-like `Modulename.field identifier`

Reason manual seems to be lagging behind Bucklescript one

Bucklescript is strictly better than ReasonML :)

Something that demonstrates that types matter

5/28/2018 13:36:46

Russia, Moscow

Yes

The most useful part was connecting existing React components with Reason

It took a lot of time to get first results

On typing props and debugging the app in browser

The most annoying thing was errors in JSX code. Mostly errors messages was very informative and useful but not in case with JSX

1) Errors in JSX

2) Unbound contructor (or something like that)

I still don't know how to type callbacks :)

JSX error messages, more examples of real world apps

I want to know how to build "big" apps using only local components' state

5/28/2018 14:07:12

Czech Republic, Prague

Yes

C++, Java

OCaml, Haskell

The atmosphere, the idea, the task (heavy bindings, realistic task, not just inspirational)

Writing bindings to JS properly

Option 1

well, setting up vim configuration + esy was not trivial, but I recognise that's not the recommended way :)

no

More examples of bindings, specifically for React components

Make it easier to configure local environments, perhaps with esy?

I liked the Jared's workshop on the ReasonConf. Maybe some Reprocessing-based game or visualisation

5/28/2018 16:30:46

Russia, St.Petersburg

Yes

TypeScript, Java, C, C++, OCaml, Swift

Clojure

Exercise with interop

Too little basic concepts

Working with external component (installing, writing external declarations, trying to understand syntax for React components)

No

5/28/2018 17:35:34

Sweden, Stockholm

Yes

Java, C++, C, Elm

Elm

Welcoming, suitable for noobs, fun!

nobody who came had enough reason experience to guide the others

Syntax we weren't used to; Problems with "unexpected syntax errors" everywhere for stuff like missing semi colons; setting up editor for vim users

Option 1

VS code: most of the time auto completion/hints just didn't work. Merlin: Unexpected Syntax Error for missing semicolons and colons... Really??

Unexpected Syntax Error; Unbound constructors; Hard to google error messages :'(

Some documentation was outdated; there wasn't really any time to more than skim the existing documentation; hard to find other sources e.g. in blog posts or on stack overflow at this point

The name is problematic as it makes googling for solutions really hard; Unexpected Syntax Errors should just burn in hell

Format could be more workshop-y, with some people who actually know their reason. Really liked the example though, as it included both some frontend and some data fetching!