How to make best 30 min impression for Rescript?

1

As an experiment, I’d like to introduce and leave a fun, great first impression of Rescript this Friday.

My challenge is for them to race to setup rescript, make an http call to some public api, and perhaps do something with it - with a 30min limit.

I suspect only half or less may make it that far. This could be fun, but what do you think I should highlight to make Rescript really interesting? Maybe share some interesting stories? FB Messenger, DraftBit, pattern matching and variants, compiler speed.

2

If the limit is 30 minutes, I’d go for a simple todo list example. Having this kind of modeling gives a few clues as to where ReScript really shines, even from a newcomer perspective.

type item = {
  id: string,
  text: string,
  checked: bool,
};

type filter =
  | All
  | Checked
  | Todo;

type state = {
  todos: array(item),
  input: string,
  filter,
};
4 Likes
3

Yeah and also I would recommend not to have network requests.

Because network requests would need the conversion from JS object to ReScript types which might be confusing for a newcomer.

4 Likes
4

Yeah doing network requests is probably a little much for 30 min. If you really want to do this though, you should probably prepare a ready-to-use module that abstracts the hard parts in a clean interface.

Just for inspiration, here is a simple fetch example used in my rescript-promise library.

No matter what you do, keep it dead simple, and make sure to prepare snippets to copy / paste, so ppl don’t get stuck and frustrated.

3 Likes
5

@dangdennis also, from experience, please ask them to keep their output open.

Our most successful impressions were to convert an existing piece of code to ReScript, per this guide. Trying to sell shiny features too eagerly can backfire, especially against the right team that prioritize shipping stable product over using shiny languages.

The impression they should walk away is “this language’s nice, and can be adopted within my codebase without pushback”. It’s also worthwhile to emphasize that you can un-adopt ReScript if the team doesn’t like it, by removing the source code and prettifying the output and moving on. Low ramp-down cost is one of our killer selling points.

I personally don’t use standalone examples, beside for a quick intro.

4 Likes
6

Thank you!

Goal does seem unrealistic now.

Synthesized thoughts:

  1. Keep output open
  2. If I do want to ask them to make network requests, prepare a super easy API / module
  3. Have lots of handy snippets
  4. Have a complete, but acute model example to showcase

Seems like I may have to tailor the experience more by setting up the links and steps rather than letting them roam free

7

Tailor even more by converting an actually piece of code in their codebase =P

1 Like
8

I actually did something very similar to this, with a teammate who doesn’t know ReScript but does know TypeScript, in a one-day hackathon recently at my company. We now have a ReScript-Node service deployed and using it for an internal Slackbot. I’ve been meaning to write up my findings, but in short:

  • Try to pair program if possible to smooth roadblocks
  • If you do use any npm-published bindings, make sure the version you use matches the version you are looking at in GitHub for code and documentation
  • If ad-hoc bindings are needed, write them on the spot to smooth the way, as newcomers can’t be expected to know how to write bindings. But do show the general gist of what it’s doing
  • Try to demonstrate two killer features:
    1. Variants and exhaustive pattern matching are what bring the ‘wow’ factor
    2. Compile speed (blink and you miss it) should be emphasized

I think two hours is reasonable for this. Maybe three to give some buffer room.

3 Likes