6 ms·

Standard datatypes and generics (including hash tables, dictionaries, vectors, sets, sequences, streams, etc.): http://docs.racket-lang.org/reference/data.html

Standard datatypes and generics (including hash tables, dictionaries, vectors, sets, sequences, streams, etc.): http://docs.racket-lang.org/reference/data.html http://docs.racket-lang.org/reference/data.html Additional datatypes (including imperative queues, growable vectors, orders and ordered dictionaries, splay trees, skip lists, interval maps, binary heaps, integer sets, bit vectors, etc.): http://docs.racket-lang.org/data/index.html http://docs.racket-lang.org/data/index.html

chongli 13y ago
Are all of those standard datatypes thread-safe? If not, they are not what the parent was asking for. Clojure's maps, sets and vectors are all thread-safe due to being immutable. They're all built-in to the standard library and have extremely slick syntactic sugar. Sure, you could implement all of this in Racket, I'm not saying you couldn't; the advantage with Clojure is that these things are standard and that everybody else's libraries make use of this stuff. This is probably the biggest advantage with starting any new programming language: you get a chance to redo the standard library (and tie it into some syntactic sugar) without worrying about compatibility.
- klibertp 13y ago
  > Are all of those standard datatypes thread-safe? Some of them have both mutable and immutable versions (lists, hashes) where immutability is the default, some are purely functional (Okasaki's data structures implementation https://pkg.racket-lang.org/info/pfds https://pkg.racket-lang.org/info/pfds), and some are mutable by default (the "data" package). Most of the stdlib is immutable by default or plain immutable. There is no "slick" syntactic sugar for these by default, but Racket being as good in "language creation" department as it is, there are 3rd party implementations (https://github.com/greghendershott/rackjure https://github.com/greghendershott/rackjure). > the advantage with Clojure is that these things are standard and that everybody else's libraries make use of this stuff For the most part it is true for Racket, too. Where it differs is syntactic sugar and more complex data structures; I think some of this will change in racket2 (which is being planned if I understand correctly). > you get a chance to redo the standard library (and tie it into some syntactic sugar) without worrying about compatibility. That's why every "racket" program starts with a #lang specifier. Racket, in reality, is many different languages at once; because of this design and matching implementation, there is absolutely no problem with redoing stdlib and syntax completely - you can write Racket that is lazy, that is FRP, that is Algol(try it, it's fun!) that is typed or is logic oriented (http://en.wikipedia.org/wiki/Datalog http://en.wikipedia.org/wiki/Datalog) already. And you can mix modules written in them freely and conveniently (provide in one and require form in the other module are all it takes in practice). This alone makes Racket so much more flexible than any other language. What Racket lacks now to implement everything Clojure (and other languages) offers as one of the Racket languages are only man-hours of development team. Other, less complicated features from other languages are being ported all the time, for example generator function in a Python style (with yield) implementation is in a stdlib since a long time, so I believe assimilating proven concepts from other languages is both possible and a "Racket way".
  - chongli 13y ago
    Yeah, it really sounds like Racket is the most flexible programming language out there due to its metalinguistic abstraction capability. The question is: what is the secret to attracting developers to join the community? Clojure seems to really benefit from the rather iconic personality of Rich Hickey; this is in common with other communities and their leaders. The other thing I wonder is if there is such a thing as too flexible? Rich deliberately resisted adding user-definable reader macros because he wanted Clojure to have a consistent, identifiable syntax. Whether that benefits the language's adoption or not, I have no idea. I have to say I am hopeful that more people are exposed to Lisp languages on all fronts and that it cross-polinates all of the communities. We all have much to learn from one another and a great deal of potential for innovation. Despite how old Lisp is it still seems like we've barely scratched the surface of its potential.
    - graue 13y ago
      Though I can't speak from personal experience, I do get the impression that many past Lisps suffered from too much flexibility, in the sense that no one could agree what object system to use, what libraries to use, etc. It seems that Clojure is doing much better that regard, which could partially explain its success.
      - klibertp 13y ago
        > what object system to use, what libraries to use, etc. But this is easily solved by just having a standard library with preferred versions of these things. Many Lisps in the past, and especially Scheme, officially defined very little besides the core language. This is changing, I hear that the next, 7th revision of Scheme standard is going to have two parts, one for the core, and another for the batteries which should be included. But! Racket comes with it's own selection of libraries in stdlib, which is richer than any other Scheme implementation. So it's not that different from Clojure in this regard. Racket has reader macros, but it is necessary for it to have them, considering that part of it's focus is to be able to build new languages easily. I haven't seen them used outside of defining these new languages, so I doubt it is a common problem for new users. There are few things where Clojure and Racket differ. One is the runtime system used - Racket has it's own virtual machine implementation with the JIT while Clojure uses those from Java. This means that a) Clojure devs don't have to spend time on a VM and can focus on the language and b) interop with Java is very strong point of Clojure. Racket on the other hand has a very nice FFI story for C, which makes writing bindings to C libraries very easy. Clojure is being developed with concurrency in mind and every aspect of a language reflects this. Racket includes support for concurrency as one of many features and so the defaults are not always suited for it and there are things Racket doesn't have. The reason for this is that the Racket developers don't have enough time to bring native threads to VM and rewrite some of the language and library and maintain normal development at the same time. (But there is racket2 planned, which may be a language with most of the Clojure features in it) And of course Clojure is being much better marketed. Clojure has a few simple selling points and they are being advertised everywhere; Racket is really very complex thing with many man-decades of research behind it and even where it is being advertised, it looks like a typical "academic" thing. So these are the reasons I think made Clojure more popular than Racket. But I really believe that, in the long run, Clojure's popularity will help Racket, too - it's much smaller jump for people to make from Clojure to Racket than from almost any language to Racket directly. So I really believe that Racket will become successful some time in the future. Meanwhile, the only thing I can do, is to comment on every Lisp article with reference to Racket and continue hacking in it happily :)

chongli 13y ago

Are all of those standard datatypes thread-safe? If not, they are not what the parent was asking for. Clojure's maps, sets and vectors are all thread-safe due to being immutable. They're all built-in to the standard library and have extremely slick syntactic sugar. Sure, you could implement all of this in Racket, I'm not saying you couldn't; the advantage with Clojure is that these things are standard and that everybody else's libraries make use of this stuff. This is probably the biggest advantage with starting any new programming language: you get a chance to redo the standard library (and tie it into some syntactic sugar) without worrying about compatibility.

klibertp 13y ago
> Are all of those standard datatypes thread-safe? Some of them have both mutable and immutable versions (lists, hashes) where immutability is the default, some are purely functional (Okasaki's data structures implementation https://pkg.racket-lang.org/info/pfds https://pkg.racket-lang.org/info/pfds), and some are mutable by default (the "data" package). Most of the stdlib is immutable by default or plain immutable. There is no "slick" syntactic sugar for these by default, but Racket being as good in "language creation" department as it is, there are 3rd party implementations (https://github.com/greghendershott/rackjure https://github.com/greghendershott/rackjure). > the advantage with Clojure is that these things are standard and that everybody else's libraries make use of this stuff For the most part it is true for Racket, too. Where it differs is syntactic sugar and more complex data structures; I think some of this will change in racket2 (which is being planned if I understand correctly). > you get a chance to redo the standard library (and tie it into some syntactic sugar) without worrying about compatibility. That's why every "racket" program starts with a #lang specifier. Racket, in reality, is many different languages at once; because of this design and matching implementation, there is absolutely no problem with redoing stdlib and syntax completely - you can write Racket that is lazy, that is FRP, that is Algol(try it, it's fun!) that is typed or is logic oriented (http://en.wikipedia.org/wiki/Datalog http://en.wikipedia.org/wiki/Datalog) already. And you can mix modules written in them freely and conveniently (provide in one and require form in the other module are all it takes in practice). This alone makes Racket so much more flexible than any other language. What Racket lacks now to implement everything Clojure (and other languages) offers as one of the Racket languages are only man-hours of development team. Other, less complicated features from other languages are being ported all the time, for example generator function in a Python style (with yield) implementation is in a stdlib since a long time, so I believe assimilating proven concepts from other languages is both possible and a "Racket way".
- chongli 13y ago
  Yeah, it really sounds like Racket is the most flexible programming language out there due to its metalinguistic abstraction capability. The question is: what is the secret to attracting developers to join the community? Clojure seems to really benefit from the rather iconic personality of Rich Hickey; this is in common with other communities and their leaders. The other thing I wonder is if there is such a thing as too flexible? Rich deliberately resisted adding user-definable reader macros because he wanted Clojure to have a consistent, identifiable syntax. Whether that benefits the language's adoption or not, I have no idea. I have to say I am hopeful that more people are exposed to Lisp languages on all fronts and that it cross-polinates all of the communities. We all have much to learn from one another and a great deal of potential for innovation. Despite how old Lisp is it still seems like we've barely scratched the surface of its potential.
  - graue 13y ago
    Though I can't speak from personal experience, I do get the impression that many past Lisps suffered from too much flexibility, in the sense that no one could agree what object system to use, what libraries to use, etc. It seems that Clojure is doing much better that regard, which could partially explain its success.
    - klibertp 13y ago
      > what object system to use, what libraries to use, etc. But this is easily solved by just having a standard library with preferred versions of these things. Many Lisps in the past, and especially Scheme, officially defined very little besides the core language. This is changing, I hear that the next, 7th revision of Scheme standard is going to have two parts, one for the core, and another for the batteries which should be included. But! Racket comes with it's own selection of libraries in stdlib, which is richer than any other Scheme implementation. So it's not that different from Clojure in this regard. Racket has reader macros, but it is necessary for it to have them, considering that part of it's focus is to be able to build new languages easily. I haven't seen them used outside of defining these new languages, so I doubt it is a common problem for new users. There are few things where Clojure and Racket differ. One is the runtime system used - Racket has it's own virtual machine implementation with the JIT while Clojure uses those from Java. This means that a) Clojure devs don't have to spend time on a VM and can focus on the language and b) interop with Java is very strong point of Clojure. Racket on the other hand has a very nice FFI story for C, which makes writing bindings to C libraries very easy. Clojure is being developed with concurrency in mind and every aspect of a language reflects this. Racket includes support for concurrency as one of many features and so the defaults are not always suited for it and there are things Racket doesn't have. The reason for this is that the Racket developers don't have enough time to bring native threads to VM and rewrite some of the language and library and maintain normal development at the same time. (But there is racket2 planned, which may be a language with most of the Clojure features in it) And of course Clojure is being much better marketed. Clojure has a few simple selling points and they are being advertised everywhere; Racket is really very complex thing with many man-decades of research behind it and even where it is being advertised, it looks like a typical "academic" thing. So these are the reasons I think made Clojure more popular than Racket. But I really believe that, in the long run, Clojure's popularity will help Racket, too - it's much smaller jump for people to make from Clojure to Racket than from almost any language to Racket directly. So I really believe that Racket will become successful some time in the future. Meanwhile, the only thing I can do, is to comment on every Lisp article with reference to Racket and continue hacking in it happily :)