Elmjustu is unmatched for elm work, highly recommended!!
It’s not upgraded to 0.19 though, nor do they plan to.
EDIT: Also, does it support presence yet? Last I checked it didn’t but its been a while now.
1 Like
I just think it is strange that you need to import a new package just because the official packages don’t deal with a standard library type (and it isn’t exactly uncommon to send dates over JSON).
That is what I used, but now you have to use an unofficial package manager, and who knows how long it will be supported.
Of course there are solutions to this, but now you still have to maintain this. If you change your type, you have to remember to fix your encoders/decoders. If I could just call something in my actual elm code to do this, there would be nearly nothing for me to do when I inevitably change something.
From my understanding, as of 0.19 the elm compiler won’t load effect modules or kernels that aren’t on the whitelist, regardless of how they are acquired, so I’m not sure you can do that now?
Does that mean you can’t even write an effect module in your own code for use within your own project?
I’m unsure if that only prevents them loading from dependencies or from the project code too, test it? 
EDIT: Also, most effect managers won’t be that useful without native parts, of which Elm 0.19 as I recall does not allow ‘any’ untrusted native (now called kernel) code, at least without manually injecting javascript in the final output. ^.^;
EDIT2: Also interesting read: Elm 0.19 Broke Us 💔 - DEV Community
1 Like
Okay, last post. For real, I swear!
I just wanted to address the “Elm Community” thread of this post.
My experience has been the exact opposite of many folks here.
What I’ve experienced is that there are many posts on the Elm discuss that are not by people who actually have a production problem that is causing them difficulties, but rather by comp sci folks who are postulating “theoretical” problems.
These folks appear to have a heavy math/CS background, and deep experience in languages such as Haskell/OCaml/PureScript.
These are often very long rants about how Elm “should” do this, or “should” do that–mostly things from ML language that were on purpose left out to a) simplify the language and b) because Elm is not a general purpose language, but rather a language designed to write epic UIs that compile to JS.
This is a classic example of such a rant:
http://reasonablypolymorphic.com/blog/elm-is-wrong/
The core team typically replies with a question like “What problem are you trying to solve?”, and the typical answer is another long, theoretical rant about how Elm should do this and should do that with a bunch of type/set theory thrown in for good measure.
I’ve yet to see a post like “I am trying to do X and I can’t accomplish it.” It’s more like “I am trying to X and I don’t want to use Ports”, and the answer is “You should use Ports”. Then everyone gets mad because they don’t want to use Ports, etc.
I personally love Elm because it “just works”, and it has been fairly easily able to work around any minor functional limitations of the language (as described above for example).
I get it. No language is perfect: yes, you have to update JSON Encoders/Decoders when they change (which I love! It forces you not to have data errors!), yes you end up writing more code than other languages (because you can’t have an if/then without an else, you have to account for every possible return result, etc.), yes, there are some edge-conditions you’ll need to work around, yes you can’t just stick a random bit of JS in the code.
But at the end of the day, the payoff is amazing code that is super easy to follow. The reason you write more code is that you to have to account for everything. In Elm, there is no such thing as “prototyping”. All code is production code! In Elixir, the compiler will allow me to have a case statement that doesn’t account for all possible return results, and as a result, will only crash in production (or test) with real data. In Elm, it just won’t compile. (Again, I love Elixir!)
For what we are doing (complex UIs with lots of dynamic data that gets loaded and unloaded asynchronously), it’s amazing.
And to me, the crazy part that seems to be overlooked on many of these forums is just how bullet-proof a shipping Elm App is! I mean, we have literally never had a single glitch with our production Elm code! That is just unbelievable. I use tons of third-party interfaces of major, well-funded web companies, and they frequently glitch, forcing a full page reload to get things back in sync.
Maybe for folks from Haskell, that’s not a big deal. But coming from the land of typical JS frameworks, that is a HUGE deal!
I had read that post @OvermindDL1 linked as well. And that same author also posted this:
To balance out the above, I feel compelled to say. I really appreciate the improvements 0.19 has made and all the effort that went into it. Elm remains the best front-end dev experience known to me. Especially when it comes to maintenance and refactoring. Elm has forever impacted the way I go about development (not just the front end). And I’m not shy about saying so in various dev communities.
What can you do. He’s grumpy. They took away his custom operators. I get it. But I find the logic for it very compelling and straightforward:
and likewise for the removal of native modules:
What I still come back to is that Elm 0.18 works as is for us as is, and better than anything else I’ve ever used (as I mentioned, we had a super senior dev look at other ML solutions).
I’m sometime in the next 6-12 months, we are going to have to spend a week or two jumping through some hoops to get the some of the functionality we need in 0.19. But I am confident we’ll make it work because I ultimately believe the Elm community is all about solving problems well, as I would be confident that the same thing would happen with the Elxiir community. If not, I’ll let y’all know! 
The crazy thing is that Elm 0.18 is so good, it’s hard for me to get super motivated to upgrade. Maybe faster compile times??? Slightly smaller code bundles? That’s about it.
2 Likes
Just to be clear, the difference in lines of code written between f.e. OCaml/Reason/Haskell and Elm isn’t that the former are less rigorous in terms of exhaustiveness checks, etc., because they’re not. The difference comes from a lack of tools for abstraction. Exhaustiveness checks and rigor is simply par for the course. We’re not talking about “How does Elm compare to JavaScript?” here.
You’re probably very used to trying to sell Elm to people who don’t know about these so I can see why you’re repeating these things, but once again: The thread is about how Elm compares to Reason (and by extension OCaml).
2 Likes
Sorry, this post is long, but I just wanted to post my experience as beginner to
these languages / frameworks.
I’ve been trying to find a front-end solution to Phoenix for a long time now
that isn’t Javascript.
I’ve tried learning Elm 0.16 with Signals (seemed powerful, but confusing at the same time)
Elm 0.17 and 0.18
I’ve done many tutorials and even did some small little programs with each.
- I’m still a beginner when it comes to functional, only started to learn
from Elixir. And before that Ruby. So like someone mentioned, I wasn’t so
used to open ended functions with not “end” or curly brace, etc… But I’ve
seen it before in Python and I quickly got overit and I came to like it (most of
the time). - A lot of the functional concepts translated quickly over to Elm, but in
Elm there were new things to learn. The type system, currying/partial application,
type unions, etc. I’m still struggling with the type system sometimes, like when
I read the docs and I’m not sure how to use certain functions. - I really like that once I could get it to compile, there were no language
errors. (Obviously, still logic errors). I love how the type system worked
compared to my nightmares with them in C++ / Java back in college days.
It wasn’t overly heavy and it was easy to use mostly, but still sometimes
frustrating since I’m still new to the concepts. - After I learned the TEA, it seemed so awesome. I really like it since it
makes things easier to reason about. That’s also how I got into React/Redux and
made it easy for me. (I’ve since then used React/Redux at work) - I still dislike React/Redux has so much unnecessary boilerplate compared
to Elm it sucks. Javascript still sucks, even ES6, while much nicer, its
still Javascript. I also hate JSX and love the way Elm does HTML. That is
one place that I fell in love with Elm. It makes it so clean, easy to reason
about and quick to type and edit. - I love the ecosystem, building things is so easy, until you get more advanced.
(Gosh I hate webpack, but been looking into Rollup and Parcel lately)
The documentation is pretty good, but sometimes still more explanation or examples
maybe needed to show how to use certain functions.
Here are my feelings of why I don’t like Elm:
- I don’t like the verbosity of connecting to JS libraries, seems to me a lot of
code to interact - I’m still finding it confusing how to do parent-child relationships between different
modules so that I don’t have to put everything on one page. Seen several models and they
have all been really not ideal and took the simplicity out of using this language/framework.
Or that there seems to be a lot of boilerplate or duplication when doing so. - I’m scared by how resistant to change the Elm community is and how it goes out of
way to restrict some things. The creator Evan and some of the community
members seem really harsh when suggestions are brought up that don’t align
with their vision. Not to me, but to others. - I bumped into many various places where there aren’t libraries available
and the standard library doesn’t cover it yet. - Css solutions seems to be coming along, but in the meantime, just using
an external stylesheet is OK. - I couldn’t find good libraries to connect with Phoenix through channels,
most of them didn’t support Presence. (I’m not sure if they do yet) - Slow to come out with changes, not necessarily bad, but there are still many things
to support/cover.
So I looked into OCaml/Reason/Bucklescript because some people mentioned it as an
alternative. At first, I was confused, but realized that Reason why just a Javascript
looking syntax on OCaml and that Bucklescript was one of 2 major compilers of Ocaml to
Javascript. And since Bucklescript seemed to be more popular right now then js_of_oocaml
and that if there are problems, I can look into the JS output.
I also looked into it because of Bucklescript-TEA library, because I wanted that same
goodness without some of the things I didn’t like about Elm.
I hate Javascript, so um, looking at the syntax of Reason and OCaml I decided to
go with OCaml because of
- Someone mentioned that Reason has problems with partial application / currying
and I don’t want to lose that. - OCaml looks kinda of like Elm, and I already kinda knew Elm.
- There should be more books and material and people to help learn OCaml.
So here’s been my experience so far with OCaml/Bucklescript:
I’ve been trying to learn from several books:
- At first I look into Real World OCaml (The dev/beta version), it was pretty cool
until maybe I got to modules. The book is still being fleshed out, so there
are many things they skip over and I just got confused. I also haven’t dealt
with “interfaces” since Java, so the “mli” stuff was a bit scary/confusing. Also
I hated that it didn’t have any exercises, so I didn’t feel like I was really
learning. - I bought the OCaml from the very beginning and MoreOCaml books which I really
liked. Maybe 1/3 of the way through MoreOCaml. I really like the excersices
and the hints/solutions provided. I only find that it is a slog to get through
though since some of it is really math heavy (well, for me anyways). While I
appreciate learning all these things, it really slows down getting up to speed
on just the language itself. - So I don’t really know all there is know about the langugage yet. Things like
functors, etc… haven’t gotten to it yet. - Also I got impatient and wanted to start learning Bucklescript and Bucklescript-TEA
I’m upset that the documentation on Bucklescript is lacking a proper tutorial.
It goes into certain things but very disconnected and I’m jumping all over the place.
It’s fine for someone who knows more about these things, but I prefer a more guided
tutorial.
I just started to learn through the Bucklescript-TEA chess tutorial. That was
great until it just suddenly got too confusing. Not appropriate for a beginner.
I think personally I got pretty far because I already knew Elm somewhat, but I’m
still having trouble. I see that Bucklescript-TEA wants to put out some docs
and that would be great, but it isn’t there yet.
Here are my thoughts on the OCaml/Bucklescript ecosystem so far:
- It’s seems more powerful than the Elm.
- Documentation is worse. I hate how the standard docs look and its just all
listed with no search feature. (I know I can use browser search) The font and
everything else there looks so dated. - There are no good beginner guides to Bucklescript. Also intermediate guides
would be great too, in particular with Bucklescript-TEA. - The community seems much nicer. There seems to be a more collaborative feeling
to making a better library. - I find that OCaml syntax is bit verbose compared to Elm, but I’m getting used
to it. I don’t like the “begin-end” hacks (or seems to be most of time). The
semi-colon usage. The nested lets seem so noisy. - But I feel less restricted than Elm for some reason. It just seems like I have
more flexibility so far. - Not crazy that the standard library is so sparse and somewhat outdated. I don’t
like that there is Core and Batteries and etc… - Bucklescript is still on an old version of OCaml. 4.02 vs 4.07 now
- The import system seems more powerful and less verbose than Elm, which I like so far.
- Still have the same concerns as with Elm on figuring out the module system
and the parent-child relationships with the TEA architecture. - I think it has potential, but I’m worried that everything seems to be going
the Reason way and as a beginner I’m worried already that I can’t find resources to
learn. And that it fragments the system. - I just a video of what is to come for OCaml (well from last year) and it seems exciting.
Elm rarely ever talks about whats next. Can’t wait for “bob” (codename), their version of
Rust’s all in one cli system that will join everything and make it easy for beginners.
Also just to see the progress of updating the whole language in the last few years. - I hate that OCaml, at least the latest version is hard to install on Windows.
So I decided to use WSL and was pleasantly suprised to see it works. I didn’t
know it came so far. Thinking about using it for everything now. Still, they
should have a compiled Windows version for the latest and greatest versions. - I like it so far, but I’m worried that I have to go back and read Elm books
just so I know how to use Bucklescript-TEA. - I wish there were more beginner friendly tutorials out there for OCaml as well.
Anyways, this is getting too long. But I think I’m going to stick with OCaml
for now, it is teaching new things and I like learning new things.
14 Likes
Great post… a lot of very good thoughts here. Due in part to a lot of Elm interest in the Elixir community I originally experimented with it (and looked at Bucklescript-TEA) before going with ReasonReact. Thought I’d answer some questions then share some points I considered when deciding myself as a beginner a few months ago
Are you looking at the very dated looking older versions of the documentation? The new site (including search features) is at: https://bucklescript.github.io.
For Bucklescript (either OCaml or Reason variants) the new “official” stdlib is Belt. You can find the docs here: https://bucklescript.github.io/bucklescript/api/ for Belt, JS, Node, and Dom. That said, the docs aren’t very well organized yet (certainly compared to the AWESOME docs of the Elixir ecosystem) so I just google around to find them more easily… e.g. “bucklescript Belt.Array”.
There are a lot of PRs upgrading BS’s OCaml version… I think it’s mostly done but not released at this point.
Yep, and with Elm 0.19 I think you can’t even use the most widely used Elixir-Elm channel library since it embeds some JS code… this kind of thing was key to deciding to go with Reason vs. Elm for me… it’s more pragmatic, you can interop with JS much easier, and it’s developed much more “in the open” as you say.
Yep… I decided a few months ago because of the small community and spotty documentation to just “go with the flow” of the bulk of the BS ecosystem and learn ReactJS, ReasonML, then ReasonReact then build my webapp around them (and Elixir of course)… and I’m very happy versus doing it all in JS. The JSX doesn’t bother me much as it “feels” like html with camelCase attributes.
For me it came down to:
- Way more learning resources/videos online for ReasonML and ReasonReact at least in the Bucklescript ecosystem (not talking about the larger native OCaml ecosystem)
- Finding common patterns through Github code searching is easier since there are many more projects (e.g.
filename:bsconfig.json reason-apolloto find library use orlanguage:reason Js.Promise.then_to find code patterns) to study. I do this literally every day. That said you can search for Reason code then convert it to OCaml (there is a chrome plugin making it easy). - More people on discord or discourse (https://reasonml.chat) using the same dialect who are friendly and love to help.
- The ability to leverage the vast React ecosystem and bind to components fairly easily.
All of this said I fully understand your desire to stay with OCaml (elmish) syntax and BS-TEA… it will work great for you I just think it’s more niche so a bit harder to get learning resources.
3 Likes
mli’s in OCaml are like h files in C/C++, however they are optional. They are really useful for making libraries, but if making apps, honestly, don’t bother with them unless you really want to control your API bounds in detail.
Not heard of that book! I’ll add it to my ever growing list. ^.^;
Functors are something you don’t really need to care about until you do, which happens when you suddenly have a case of where you want to do module transformation, which is again, mostly library work, like making a module StringMap = Map.Make(String.t) is a function that ‘transforms’ the generic Map module to be specialized and type safe on strings.
Some features of OCaml that really did hurt me lacking in Elm (as in code growth and unable to represent some things without using additional thunks) were things like an external interface FFI that is not ports (sometimes you just ‘have’ to), GADT’s (another thing where you don’t think about until you need it, then you really really need it, and happens in application code fairly often for me), and PPX’s are just absolutely awesome, among many other more minor differences (like compiling speed).
You should tell the author about that so he can fix it.
I made a mini-clicker game thing on my blog about using bucklescript-tea, tried to keep it simple and just showing how to build up an application a bit (at least how I do it).
For bucklescript just use OCaml’s guides, the bucklescript specific things is mostly specialty javascript interaction. As for bucklescript-tea, I’ve mostly deferred that to Elm as Elm’s guides work 95% of the way there for bucklscript-tea too, but I am planning more in-depth things whenever I get around to making my tea extensions in bucklescript-tea.
Yeah this bugs me too. JSOO does not have this issue, I’ve honestly been thinking of dropping explicit bucklescript support from bucklescript-tea because of this. I’d still ‘support’ it but you may lose out on the occasional feature if you do.
Eh, I’ve seen so many ways people do it, do whatever works for you and is maintainable for you.
Thankfully ocaml and reasonml translate automatically, that’s even done in bucklescript-tea’s repo so you can see it in both ways, done automatically via git commit scripts to keep everything in perfect sync.
This is one area that reason’s ecosystem is better in for sure (remember that you can use ocaml syntax with reason’s tools too!), but there is a big push in the OCaml ecosystem to buff up Windows support and that has been massively boosted lately. The next version will work even better and when the new build system Dune finishes then that should fix up most of the rest of the issues along with opam.
Eh, the big thing about bucklescript-tea is just the API it uses, an init-update-view structure with commands and subscriptions for sending and receiving events. I probably should make a detailed blog post about it considering how much bigger it’s getting lately…
Hear hear! If you like learning new styles and things might I recommend looking at Racket and Forth? Both are awesome languages and unique in their own ways. Forth alone is like a puzzle of easily readable code with a push/pop stack interface, one of my personal favs, and Racket is a modern scheme-like language, so it can ‘become’ about anything.
Bucklscript really should have just been a full PPX instead of a compiler fork to manually add in it’s hooks… ^.^;
Just don’t forget that ocaml/reasonml translate directly and automatically, so any resources for one works for the other, ditto with PPX’s and all too. You can even use the React PPX to get that special html-flavoured soup in OCaml too, not just ReasonML.
Great post… a lot of very good thoughts here.
Thanks. I was just kind of laying out my thoughts here since I feel like it I’m in the process of learning them and I have direct experience with many of the things being discussed.
Are you looking at the very dated looking older versions of the documentation? The new site (including search features) is at: https://bucklescript.github.io .
Yes, I was referring the OCaml standard library docs. I wanted to mention that, but too many things, post is long enough. They really need to overhaul that. The Bucklescript site is not bad.
the new “official” stdlib is Belt
I didn’t know about that, thanks. The docs are better (at least visually) but could still be improved.
The JSX doesn’t bother me much as it “feels” like html with camelCase attributes.
In rails projects, I use “slim”, but when I went to React with JSX, I felt I went backwards. Regular html is so verbose, not necessarily needed all of those opening and closing brackets, etc… I feel that Elm / Bucklescript-tea’s HTML library is so much cleaner and it doesn’t feel unnatural to add variables and other code to it, like JSX can feel. I feel less context switching. Haven’t seen how it looks in ReasonReact though. Anyways, I think this is just personal preference of course.
- The ability to leverage the vast React ecosystem and bind to components fairly easily.
I haven’t gotten to the Javascript FFI yet, but I heard its great (or at least a lot easier than Elm), and there are a lot of components already in JS land that I can just hookup to.
All of this said I fully understand your desire to stay with OCaml (elmish) syntax and BS-TEA… it will work great for you I just think it’s more niche so a bit harder to get learning resources.
Yes, I’m happy that more people are looking to typed functional languages, so I’m happy that Reason is working for for you as well. I’m going to stick with OCaml, since I don’t really like JS syntax and I’m already familiar and like Elm syntax.
1 Like
When you are in regular OCaml maybe - however in a browser environment I think you’re against the wall because Functors seem to be a cornerstone of clean interop interfaces. I seem to recall running into them all over the place in:
1 Like
You will ‘use’ them a lot sure, but you won’t be writing many if any in your application.
mli's in OCaml are likehfiles in C/C++, however they are optional. They are really useful for making libraries, but if making apps, honestly, don’t bother with them unless you really want to control your API bounds in detail.
Yea, I thought they were somewhat similar too from what I can remember. I haven’t touch C/C++ in a looong time.
Not heard of that book! I’ll add it to my ever growing list. ^.^;
Yea, its pretty good. I like how they keep building on things one after another. And explaining things in a more laymens terms, but sometimes it annoyed me too, because I already knew the concept. But no book is perfect and for different audiences. The book was tailored to college students who may not know OCaml yet, and in the first one, to non-programmers too. So I think it fits its target audience.
Functors are something you don’t really need to care about until you do
Good, because I think I need to prioritize my time. I need time to practice things instead of just trying to learn everything.
Some features of OCaml that really did hurt me lacking in Elm (as in code growth and unable to represent some things without using additional thunks) were things like an external interface FFI that is not ports (sometimes you just ‘have’ to), GADT’s (another thing where you don’t think about until you need it, then you really really need it, and happens in application code fairly often for me), and PPX’s are just absolutely awesome, among many other more minor differences (like compiling speed).
Yes I’m excited to learn the FFI soon.
Also, want to check out these GADTs.
You should tell the author about that so he can fix it.
May do that, but I’m not sure I’m the right audience… Maybe? He keeps on saying, oh you should just figure it out on your own. So maybe for people who are better at functional languages or OCaml already.
I made a mini-clicker game thing on my blog about using bucklescript-tea, tried to keep it simple and just showing how to build up an application a bit (at least how I do it).
I’m planning to check out yours as well. Its on my list.
For bucklescript just use OCaml’s guides, the bucklescript specific things is mostly specialty javascript interaction.
I’m seeing that to be the case so far. But its still early, I haven’t gotten around to investigating everything yet.
As for bucklescript-tea, I’ve mostly deferred that to Elm as Elm’s guides work 95% of the way there for bucklscript-tea too,
While this works for people who came from Elm and are good at it. I think we need some beginner guides to help spur people to come into the ecosystem and this library. And people are lazy, the like to be spoon-fed. Also, I’m curious how well it translates to 0.19 version of Elm?
I am planning more in-depth things whenever I get around to making my tea extensions in bucklescript-tea.
Please do.
I’ve honestly been thinking of dropping explicit bucklescript support from bucklescript-tea because of this.
I’m ok with that, as long as I get to keep using OCaml and TEA.
Thankfully ocaml and reasonml translate automatically,
I’ve seen some of those translations on Reason’s site and frankly the OCaml looks really bad. Many extra parenthesis not needed and can just make it more confusing to try to learn from this.
that’s even done in bucklescript-tea’s repo so you can see it in both ways, done automatically via git commit scripts to keep everything in perfect sync.
I just saw the thread on it, that is pretty cool.
there is a big push in the OCaml ecosystem to buff up Windows support and that has been massively boosted lately. The next version will work even better and when the new build system Dune finishes then that should fix up most of the rest of the issues along with opam.
Yep, I’m excited for those things.
Eh, the big thing about bucklescript-tea is just the API it uses, an init-update-view structure with commands and subscriptions for sending and receiving events. I probably should make a detailed blog post about it considering how much bigger it’s getting lately…
That would be great.
might I recommend looking at Racket and Forth?
I’ve heard of Racket before. Maybe when I get some time, I’ll look into these. Thanks for the suggestions.
Thanks for the feedback/response.
1 Like
Yep, true… just a little harder since you have to go through the translation step. I find the chrome plugin makes it easier when you are just browsing around… but really I think it’s a smart idea to go through RWO and/or OCaml from Very Beginning books even if you are writing Reason syntax so it’s easier to mentally parse OCaml code without having to translate it.
This is one thing that bothers me a little about OCaml vs Elixir… I wish we could use something like letp to define private functions instead of having to define/maintain a separate .mli or .rei file.
Haha, I’ve seen you say this before… is there a GH example repo showing how to integrate the React/JSX PPX in an OCaml project? Surely just adding "reason": { "react-jsx": 2 } to bsconfig.json is not enough. Would be interesting to see it!
Agreed… I think we are very spoiled by the incredible docs (and this great forum) in the Elixir ecosystem. That said doc updates make great PRs the maintainers would appreciate so they should gradually get better as the community grows.
Sounds great… after you get the hang of it I’m sure it will work very well and give you an Elm-like experience without the downsides you mentioned earlier.
1 Like
I consider one of the big wins of using OCaml that you can put a statically checked interface on top of JS that can effectively make it impossible to misuse something. I would agree that in our code base we don’t strictly need it, but I wouldn’t like working with it as much as I do otherwise. Having a statically checked interface on top of something like LocalStorage, enforcing encoding/decoding at compile-time means less worries when you’re trying to use it.
1 Like
Sending input is always good though!
Mine I may not have focused enough on tea (I really don’t see the tea pattern being a big thing honestly) and focused more on the ‘programming with ocaml’ bit honestly.
Still quite well, minimal name changes, and Elm mostly just keeps removing stuff at this point. ^.^;
It would also add server-side rendering, like via generating it for phoenix via a fast port. ^.^
Yeah I agree there, reasonml changes precedence in some odd ways so it adds more parenthesis that what would normally be done.
The chrome plugin is frankly awesome, that’s how I mostly learned reasonml, was seeing how it translated from OCaml. ^.^
The common’ish pattern in OCaml is to define a submodule inside your module, then just expose what you need out of it at the end, it’s basically like including the mli at the bottom of the ml, except you need even less types (let blah = INNER.blah for example).
It almost is that easy actually. Heck, just convert a react reason program to ocaml and see how it works. ^.^
Yeah, the new form of languages like Elixir and Rust and so forth have such fantastic documentation. Coming back from the old perl and C++ and such days really makes this feel like a golden age, lol.
Yeah this is a big BIG reason I use OCaml on the browser. If you type things properly, then you near reach that point of ‘if it compiles then it works’.
Mine I may not have focused enough on tea (I really don’t see the tea pattern being a big thing honestly) and focused more on the ‘programming with ocaml’ bit honestly.
The tea pattern is best I seen (not that I’ve really searched much), but I guess its the whole ecosystem that I like too. I’m still interested in reading your tutorial.
Still quite well, minimal name changes, and Elm mostly just keeps removing stuff at this point. ^.^;
Great to hear.
It would also add server-side rendering, like via generating it for phoenix via a fast port. ^.^
That sounds interesting.
Also I would like to add some more thoughts on the OCaml / Bucklescript system that I just thought about as well:
- I really like how fast the compiler is, it makes development so much more fun. Faster than Elm or Elixir or most compiled languages I know.
- At first the errors were really bad with standard compiler. Or rather, it was frustrating trying to read line numbers and then chars over to figure out what it was talking about.
- I used “utop” and that was a great tool. I really like it as a repl, much more powerful than what I’ve seen before and I like that I can make multi-line functions without having to worry about using a key-combo or adding a line marker to do so. It also underlines exactly where the error is so I can debug it easily. I just don’t like having to end things with “;;” though, but I guess I get used to it.
- After I started with Bucklescript though, I found this flag “bsc-flags”: [ “-bs-super-errors” ] and it gave me Elm style errors. That was so great. Its made it more fun again, what I missed coming from Elm.
1 Like
I’m actually more of a fan of observer bindings personally, though it’s less convenient.
The BetterErrors library helps with that, bucklescript and reason both include it natively.
Yeah it needed ‘something’ to denote “End of block of code, please execute it all to this point now” so they chose that a long long time ago.
Ah yep, that’s it. BetterErrors is a standard ocaml library thing, you can plug it into a normal ocaml project, like say via Dune or whatever.
BetterErrors is a standard ocaml library thing,
Cool, I didn’t know that. Thanks.
like say via Dune or whatever.
I’ve been using Dune, since it seems to replace JBuilder. but I’m not sure what’s different yet. I see that some of syntax has been cleaned up though on the dependency file, which is nice.
1 Like
