11–20 of 154 posts
Does Racket support "real" multithreading yet? I remember looking at their documentation a few years ago and it only had support for a green-threading thing, which (along with the first-class hashmaps) steered me towards Clojure.
Does Racket support "real" multithreading yet? I remember looking at their documentation a few years ago and it only had support for a green-threading thing, which (along with the first-class hashmaps) steered me towards Clojure.
Does Racket support "real" multithreading yet? I remember looking at their documentation a few years ago and it only had support for a green-threading thing, which (along with the first-class hashmaps) steered me towards Clojure.
Earlier quoted context omitted.
Given the Racket2 possible massive syntax changes it seems that using JavaScript was a better choice for a commercial project. That being said I very much prefer Racket to JavaScript for personal/hobby projects.
I think it would have been fine based on https://groups.google.com/forum/m/#!msg/racket-users/HiC7z3A... > No matter how Racket evolves, the community is committed > to preserving what we have achieved: today's `#lang racket` > programs will run in the future, and today's > `#lang racket` modules can be used in future Racket programs.
Does Racket support "real" multithreading yet? I remember looking at their documentation a few years ago and it only had support for a green-threading thing, which (along with the first-class hashmaps) steered me towards Clojure.
I really like Racket, but the potential breaking massive syntax change in Racket2 makes me really uncomfortable in using or recommending Racket to other people, at least until the situation is clarified.
> * Make the language constructs more generic
> In many ways, the current Racket language and libraries encourage the use of concrete data structures instead of abstract datatypes.
Matt Flatt goes on to mention that map only works with list types, for example (you need to use hash-map to work with hash tables, vector-map for vectors, et c.). This makes refactoring a bit of a pain and feels like a legacy holdover that shouldn't exist in a modern programming language.
I really like Racket, but the potential breaking massive syntax change in Racket2 makes me really uncomfortable in using or recommending Racket to other people, at least until the situation is clarified.
There's even more community support for parentheses than I would've guessed. For various objective and subjective reasons I won't regurgitate here.
Some of the work in non-parens syntaxes (especially the Honu paper) are very interesting, and deserve more prominent exposure, and to be well-supported, so that people can try and adopt them with confidence. I'll be interested to see how people use them.
But there's no need to alienate half the community by declaring any of the non-parens approaches the default or normative, especially when Racket already famously has all the meta to support all of them, well.
I suppose it might even turn out that `#lang racket2` ends up looking almost exactly like `#lang racket`, just with tweaks to names and semantics, and that any non-parens syntaxes are separate and layered. And they all interoperate. Which Racket supports well.
My guess is, probably after everyone gets back from well-deserved vacations, this will to start to clarify, probably in September.
Does Racket support "real" multithreading yet? I remember looking at their documentation a few years ago and it only had support for a green-threading thing, which (along with the first-class hashmaps) steered me towards Clojure.
Yes, Racket support using multiple cores/OS threads. There are two mechanisms -- shared memory parallelism that is limited in what operations the threads can execute in parallel (called futures in Racket) and shared-nothing parallelism with message passing, more like Erlang (called places in Racket). Most real work using parallelism in Racket uses places.
Racket supports multiple threads of evaluation. Threads run concurrently, in the sense that one thread can preempt another without its cooperation, but threads currently all run on the same processor (i.e., the same underlying operating system process and thread).
[1] https://docs.racket-lang.org/reference/eval-model.html#%28pa...
Carmack is a huge fan of Racket. He was going to use it as the scripting language for VR until the Oculus execs made him use JavaScript instead (boooooo) https://twitter.com/id_aa_carmack/status/807797812700348416
Given the Racket2 possible massive syntax changes it seems that using JavaScript was a better choice for a commercial project. That being said I very much prefer Racket to JavaScript for personal/hobby projects.
But really there are lots of other, better reasons to use JS over Racket for a major commercial project, which may or may not be actually a good call, but a new proposed syntax is not one of them.
Carmack is a huge fan of Racket. He was going to use it as the scripting language for VR until the Oculus execs made him use JavaScript instead (boooooo) https://twitter.com/id_aa_carmack/status/807797812700348416
A former employer was led by huge Clojure fans, who requested that the backend be Clojure, and highly encouraged me to use ClojureScript and something like Reagent for the front-end, which I recently noticed that they finished after my departure. But the more I think about it, the more I can't think of a single feature of ClojureScript that's inherently better than JavaScript, whereas s-expressions are inherently hostile and also have no real-world benefits. JavaScript has destructuring, closures, a flexible module system, object/array spread, basically every syntactical feature Clojure has, but without the s-expressions.
The commonly touted benefit of s-expressions is homoiconicity (code is data), which lets the developer customize the language via macros without needing to wait on the compiler/interpreter authors. But we have this exact same benefit in JavaScript with compilers like Babel. Maybe it's pushed onto another layer of development, but it's in no way less legitimate or useful. The slight benefit you get by being able to do this transformation at runtime is negated by the inconvenience of s-expressions. (Although at first glance, it seems like we could use a better Babel API that lets us transform our code more conveniently. But I think they're working on that?)
The main other benefit I commonly see from people using Clojure or ClojureScript is live development. I saw technomancy made some blog posts about how he used Fennel (a Lisp that compiles to Lua) to do live-coding stuff in Love2d. I was impressed, until I realized that none of these features were specific to Lisp. So I borrowed the same underlying concept he utilized, and started to make a really cool Love2d live development thing just like he had, but in pure Lua.
Now I have the ability to press Cmd-E in VS Code while editing some Lua file, and if I have any code selected, it'll be sent to the live Lovd2d game that's running, to be eval'd, and if there's no selection, the whole current file will be sent. It's the coolest setup ever, almost identical to the awesome setup I had with CIDER + Clojure + Emacs, but without Emacs or s-expressions.