Hmm? What language is quirky FP/OOP? NIM is pretty OOP and not very FP from what I’ve seen, Rust is interface based FP (no OOP), OCaml is interface based FP (has OOP style objects but not traditionally OOP as most know it) as well?
Well if you want Lisp go for Racket, it already has everything too. ^.^
Sorry we hijacked your thread.
@OvermindDL1 or @AstonJ Could you split our irrelevant posts into a separate one and delete this comment?
I liked the tutorial of Racket but I’m not really sure what niche is it supposed to fill – except maybe excelling in making Deals?
OMG, just noticed this awful autocorrect! I meant “DSLs”, damn it!
Lol! Happens to us all (way waaaay too much!). ^.^
Racket is a LISP(scheme), which is a style of language made for making languages, but that means that with little code you can make something perfectly optimized, both for programming efficiency and performance both, just for the specific task that you want, and it has everything from types to web servers and far far more. It’s IDE (DrRacket, it comes with racket) is top notch!
I was quite impressed by the quick tutorial of Racket, really. I loved it. I was even more impressed that the author of Beautiful Racket dog-fed himself and made a language for writing web books.
And I absolutely adore the idea of a language for making DSLs!
That being said, maybe I am spoiled by Elixir but if there’s no good parallelism story, I don’t know… 
Gotta say though, I liked Racket and OCaml quite a lot after I tried doing some basic algorithms with them. Just not sure where to place them both in terms of use-cases.
I’m actually quite curious what you find lacking in the racket ecosystem here? Racket itself supports the necessary basic concurrency and parallelism primitives, and there are quite a lot of libraries out there that build on them, including even an actor model library (which I don’t know if there is an OTP-like library built on that or not but it would certainly be feasible) and quite a lot more. 
I guess that’s exactly it. If I love a language then I immediately get sad it doesn’t have OTP. 
Would you recommend Racket’s parallel / concurrency story for parallel computing?
(And while we’re at it, would you recommend OCaml for the same? I gotta say I am not very impressed by LWT, looks like glorified pthreads at least from a cursory glance – hope I am wrong, I’ll dive deeper Soon™)
I relate there. ^.^;
I wouldn’t see why it wouldn’t work well for that, it is fully parallel and concurrent.
Not really. And LWT is very nice but it is only for concurrency, it is not for parallel. OCaml in general is fine if you need concurrency but, like python, it’s fairly poor at parallel. However the in-dev Multicore Compiler (being brought piecemeal into mainline as each piece gets fully vetted, you can add it to opam via opam remote add multicore https://github.com/ocamllabs/multicore-opam.git && opam switch 4.06.1+multicore then can install the remote as normal) fixes the parallel issue and you can actually implement an entire erlang/elixir-style OTP concurrency and parallel system on OCaml then (it’s built an an algebraic effect system so you can pretty well build any style of concurrency and parallel handling that you can think of), but this is not vetted into the mainline ocaml in full yet so I wouldn’t write anything production level in it, but it’s certainly super fun to play around with (especially the algebraic effects stuff!).
Yeah, but some of us want it written for them! 
I guess I’ll wait. So currently there’s no way to even simulate Task.async_stream if you go out of your way to create separate thread per CPU core?
If it’s mostly I/O bound it should work fine. Multiple threads work fine in OCaml as it is, just with the GIL then OCaml code can only run on one thread at a given instant (same as in Python, this restriction is gone in the multicore ocaml branch). Rust and Racket should work just fine immediately as they are fully concurrent and parallel both while being very fast. Though if you want long-running servers then the BEAM is better (more simple to code) or Rust with Actix is great (more complex to code but ‘safer’ while still having an OTP-like setup).
Amazing. And here I thought I could use several trully parallel OCaml threads if I want to. 
Well then, currently Racket wins. Although I have to say, it’s really hard not to use OCaml’s really easy syntax…
Lol, that’s why I compare OCaml’s parallel story to Python so much, because they are identical in that way (just ocaml executes code a lot faster). ^.^
OCaml really does feel like a ‘better python’ to me, until multicore ocaml fully lands at which point it will finally elevate to a more useful level, closer to the realm of native languages.
Give Typed Racket a try, it’s not quite as powerful as OCaml’s inference system but it’s still quite good.
Is this another spun-off version of the language?
Hmm? No? Typed Racket is part of racket, it’s a type layer on top of dynamic racket, it’s usually one of the first things taught about racket because it’s better to program in since it catches a lot of bugs. ^.^
Oh wow, so we actually do have a statically typed LISP? Didn’t know!
As for multicore OCaml allowing OTP-like systems, yeah… we’ll need another 20 years for that though.
There’s a few out there that I’ve ran across yeah. ^.^
Are there LISPs that compile to native code, like OCaml does?
Quite a few in quite a few lisp’y languages. In one with staged running it can be as trivial as writing a macro that takes in the rest of the program code, expands the macro’s, then translates the lowered primitives to machine code. I’m unsure if racket has one, I’ve not looked, but I expect it would, though I know racket can package up the bytecode and runtime into standalone binaries regardless (raco exe or something like that), but there have been a lot of others over time that compile down to machine code. The default running mode of most lisps (especially as most aren’t staged compilers) is a bytecode level though, because the code can actually change and mutate itself at run-time in most (non-staged) lisps.
© Copyright Elixir Forum | Terms | Privacy & Cookies
