141–150 of 190 posts
Using Facebook's software supports Facebook. I think the industry should move away from that instead of adopting more of their technology. Programmers should start considering these things. Alternatives: Elm, Purescript, etc. Edit: I recommend stopping and thinking a bit about ethics of technology choices before reactively downvoting.
Earlier quoted context omitted.
I like F# and believe the author has done an amazing job evolving a functional language on the dot net platform but there are simply too many design choices in F# geared around C# compatibility and limitations of CLR being an object oriented language that when you switch to a different compilation target, these language aspects begin to look like bizarre warts. Things like limitations on statically resolved type para…
If ocaml gets multicore finished before 20XX, do you think that f# developers who came from outside dotnet could be coaxed to ocaml? Also, to just jump in what your comment was actually about, I think the prospect of writing f# is generally a more friendly experience for those using it for the web. Or especially those using azure. Getting started with f# with ionide and vscode is literally the most pleasant onboardin…
I do think that upcoming multicore support in OCaml is very exciting. I am more optimistic that it will attract people from Golang and C++. F# developers coming from outside dotnet is just too small a cohort.
> Getting started with f# with ionide and vscode is literally the most pleasant onboarding I've experienced since ruby.
Yeah, Ionide is really amazing. However merlin has also worked pretty well for me so far, and the emacs integration is a big plus for me. YMMV.
Also my comment was more around frontend use cases (compile to JS). I wouldn't be surprised if F# shines wrt Azure integration and within the dotnet ecosystem.
> You do web development primarily? I've been eyeballing TS lately, you think that's probsbly a better choice for more professional work until reasonml gets bigger pants to wear?
Yes, mostly node and frontend. In my area, professional work in reasonml is almost non-existent, but I do expect this to change in future.
As an developer coming from Ruby myself, glad to see more people from dynamic languages finding FP and type systems interesting.
Earlier quoted context omitted.
If ocaml gets multicore finished before 20XX, do you think that f# developers who came from outside dotnet could be coaxed to ocaml? Also, to just jump in what your comment was actually about, I think the prospect of writing f# is generally a more friendly experience for those using it for the web. Or especially those using azure. Getting started with f# with ionide and vscode is literally the most pleasant onboardin…
> If ocaml gets multicore finished before 20XX, do you think that f# developers who came from outside dotnet could be coaxed to ocaml? Pfft. Run reasonml/ocaml on node, one event loop pr core, and use message passing for synchronisation / distributing work ;-) I'm only half-joking.
Honest question: why would someone use this instead of React? From my point of view, React solved a real problem. JS before React (at least old-skool, with jQuery & co.) was simply unmaintainable. It was often easier to thow old projects away and start anew than to maintain what inevitably became a tangled mess of callbacks and global variables. Not because of incompetency of developers (at least I hope so ;) but bec…
Facebook rewrote Messenger in Reason. Before they had hundreds of bugreports in a year. Afterwards? Less then ten.
Earlier quoted context omitted.
It's covered in the article: "When using ReasonML, we don't need Redux anymore. ReactReason stateless components already come with the concept of a build in reducer, which is meant to take care of the problems Redux used to address."
Reducers are only one (and IMO the least important) part of using Redux with React; the other part is `connect`, which lets you pass global state directly into a deeply nested component without passing it all the way down the tree via props. Unless I'm mistaken, ReactReason doesn't offer an alternative to that.
Earlier quoted context omitted.
Typescript, Redux, and Immutable.js work together as a pretty compelling stack, but they involve a fair bit of boilerplate compared to Elm or ReasonML. Elm provides type safety, immutable data structures, and state management in a very compact but readable way. In fact, Redux was strongly inspired by Elm's state management. All of these stacks are perfectly acceptable choices, so it comes down to a matter of personal…
> compared to Elm or ReasonML PureScript deserves a mention in this list as well. More full-featured and general purpose than Elm, cleaner design than ReasonML. Prolly the smallest community of the 3.
With Elm the situation is very different. All your code is pure. The runtime hides the state management and the only way to interact with JS is via message passing. The end result is code that is extremely easy to follow, maintain and debug. Moreover, as Elm style and tooling discourages using lambda-style callbacks with opaque state, all state is very explicit and often just by looking at the state data structures, one often can grasp what the code is doing. It is almost like code follows from the data structures.
Earlier quoted context omitted.
> If ocaml gets multicore finished before 20XX, do you think that f# developers who came from outside dotnet could be coaxed to ocaml? Pfft. Run reasonml/ocaml on node, one event loop pr core, and use message passing for synchronisation / distributing work ;-) I'm only half-joking.
Tangentially relevant: There is a serious and ambitious PR implemeting proper (web-worker style) threading support in Node.js core. https://github.com/nodejs/node/pull/20876
Earlier quoted context omitted.
If ocaml gets multicore finished before 20XX, do you think that f# developers who came from outside dotnet could be coaxed to ocaml? Also, to just jump in what your comment was actually about, I think the prospect of writing f# is generally a more friendly experience for those using it for the web. Or especially those using azure. Getting started with f# with ionide and vscode is literally the most pleasant onboardin…
> If ocaml gets multicore finished before 20XX, do you think that f# developers who came from outside dotnet could be coaxed to ocaml? I do think that upcoming multicore support in OCaml is very exciting. I am more optimistic that it will attract people from Golang and C++. F# developers coming from outside dotnet is just too small a cohort. > Getting started with f# with ionide and vscode is literally the most pleas…
Anyways, thanks!
I think ReasonML would see much faster adoption if they provided a stand-alone binary, or at least a pre-installed environment, which could be downloaded and installed as a whole. ReasonML has a lot that makes it attractive to people that aren't already entirely invested in the JS/Node ecosystem, but doing the whole dance to make sure Node is installed correctly, and then using npm or yarn to install bucklescript and…