9 ms·

I'm curious why people don't prefer Chez Scheme to Racket if it is so fast and can make real binaries (I think anyway). Maybe because until recent it was propri

I'm curious why people don't prefer Chez Scheme to Racket if it is so fast and can make real binaries (I think anyway). Maybe because until recent it was proprietary. Racket is cool, but I already have Python which is similar from a performance perspective. Chez with the Racket ecosystem might be worth a switch.

catnaroek 10y ago
Raw performance isn't all there is to a programming language. Racket is so much more flexible and beautifully designed than Python.
- throwaway7645 10y ago
  Agreed, but if Python is your main weapon of choice, one will usually want to invest next in something really fast to bridge the gap. I wasn't aware Racket is that much faster....I'd like to see some benchmarks.
  - catnaroek 10y ago
    I tend to think of Racket as an alternative to Python, rather than a complement to it. C and Rust fit better the latter description. Racket is faster than CPython, but that isn't anywhere near the top of my list of reasons to use Racket instead of Python. When speed is a priority, Rust and MLton (Standard ML) are both much faster than Racket. But: (0) Racket is much more malleable than either Rust or SML. Rather than bash your head trying to model your problem domain in the existing language, you can redefine the language until it's the ideal tool for your problem domain. (1) Unlike other languages that also advertise malleability (Common Lisp, Smalltalk, etc.), Racket is malleable in principled ways, so you can define abstractions without figuratively stomping on abstractions defined by other people (which you might also be interested in using).
    - throwaway7645 10y ago
      How often are you doing something that needs to be turned into a DSL, or is this something that you do all the time once you grok it?
      - catnaroek 10y ago
        More often than I'd like to. In an ideal world, language designs would be perfect out of the box, and the right abstraction for expressing what I want to express would always be available without me having to do anything. Alas, in the real world, languages have limitations, and you can either metaprogram them away or put up with them. For example, a while back I was investigating a general framework for expressing various types of self-balancing search trees without tediously reimplementing the same ideas over and over: (0) A search tree is either a leaf or node. A node is a alternating sequence of subtrees and individual elements, beginning and ending with a subtree. (1) Rebalancing a tree preserves the sequence obtained from traversing it in-order. (2) In the specific case of binary search trees, there exist two kinds of rotations: 3-rotations (rebalancing the sequence “a,x,b,y,c”, where “a,b,c” range over subtrees and “x,y” range over individual elements) and 4-rotations (rebalancing the sequence “a,x,b,y,c,z,d”, where “a,b,c,d” range over subtrees and “x,y,z” range over individual elements). (3) It is very convenient to manipulate purely functional search trees using zippers, for more or less the same reasons it is very convenient to manipulate imperative search trees using iterators. Zipper types can be obtained from tree types using a generic procedure (given the recursive type “T = μR.F(R)”, find the derivative of “F(R)” with respect to “R”, then instantiate it at “T = R”)... if only you could express this procedure in the first place.
        throwaway7645 10y ago
        Thanks for the reply!
    - mkesper 10y ago
      If you redefine your whole language, how is your experience with understanding your code after say 6 months?
      - kd0amg 10y ago
        I've generally found, both with my own code and others' code, that `some-undocumented-special-form' is about as understandable as `some-undocumented-function' (and a similar equivalence for things that are documented).
      - catnaroek 10y ago
        That greatly depends on how principled (hence convenient) the mechanisms for redefining and/or extending the language are. Metaprogramming in Python has the annoying tendency to create a mess where the implementation details of different parts are tightly coupled to each other. But metaprogramming Racket, especially using syntax/parse, is very clean.
        throwaway7645 10y ago
        Interesting. I wish there as a Manning "Racket in Action" book. The problem with a lot of Lisp materials is that they show you the basic constructs and not how to best use them (like you talk about above).
        soegaard 10y ago
        Maybe "Beautiful Racket" ? http://beautifulracket.com/ http://beautifulracket.com/
        lispm 10y ago
        On Lisp. PAIP, Common Lisp Recipes, Practical Common Lisp, Lisp Style and Design, AMOP, Object-Oriented Programming in Common Lisp: A Programmer's Guide to CLOS, ... There are various Lisp books which go beyond the basic constructs.
    - lispm 10y ago
      > Unlike other languages that also advertise malleability (Common Lisp, Smalltalk, etc.), Racket is malleable in principled ways, so you can define abstractions without figuratively stomping on abstractions defined by other people (which you might also be interested in using). Just like the Common Lisp Object System Meta-object protocol, readtables, symbol packages, ...
      - catnaroek 10y ago
        I prefer defining things to tweaking them, so I don't find dynamic metaprogramming (CLOS) to be a good enough substitute for static metaprogramming (macros), and Racket's macro system is light years ahead of Common Lisp's. YMMV, of course.
        lispm 10y ago
        I don't think macros are a good way to implement or even extend object-oriented languages. So I don't think static macroprogramming is a good substitute for a meta-object system.
        catnaroek 10y ago
        Give me a compelling reason to design programs in an object-oriented way. Just to be clear, I don't find the ability to subvert existing definitions particularly attractive, because it undermines my ultimate goal to actually prove things about my programs. --- @lispm, I have reply here because I'm temporarily unable to make new posts. > A large share of contemporary software is written in an object-oriented way. Sure, but how does that contradict my original assertion that Racket's mechanisms for extending and redefining the language are more principled than either Common Lisp's or Smalltalk's? --- > Could it be that you just don't like/use/need/want the object-oriented ways to extend those languages and thus these mechanisms are not 'principled'? You're right that there's an aesthetic component: I don't have much taste for object-orientation. But this isn't just me being close-minded: I would take object-orientation far more seriously if someone could provide an interpretation of object-oriented programs as mathematical objects with nice properties. > How are Racket's mechanisms for extending and redefining the language more principled Racket's macro system is based on a theory of how to macro-expand in a capture-avoiding way, ruling out by construction errors that are very difficult to debug when doing similar things in Common Lisp. And macro systems are more principled than MOPs in that macros are purely static devices: you (re)define the language first, and you use it later. > Especially since Racket provides some of that, too -> Swindle. Object-orientation in Racket is completely opt-in. You don't have to use it if you don't want to, and, in fact, I just don't use it... > Is the CLOS MOP not principled? Why? ... OTOH, in Common Lisp it's far more pervasive. Everything is an object and has a class, and classes can be tampered with in arbitrary ways, precisely using the MOP. How can then you prove anything interesting about how instances of a class will behave under all circumstances? The essence of abstraction is to ignore implementation details, and concentrate on, well, abstract properties. A MOP achieves the opposite thing: it makes all implementation details available everywhere, complicating the problem of abstraction enforcement.
zem 10y ago
racket is just a pure pleasure to use as a language, more so than either scheme or python.
- timClicks 10y ago
  I thought Racket was a scheme implementation?
  - Johnny_Brahms 10y ago
    It was, but then diverged from r6rs and became it's own. One big things is that the cons cell is immutable by default (which means immutable lists), where scheme has set-car! and set-cdr! The racket team wrote a bit about it here: http://racket-lang.org/new-name.html http://racket-lang.org/new-name.html
  - steinuil 10y ago
    The Racket language does not follow any of the Reports, so it's technically not a standards-compliant Scheme. On the other hand, the Racket platform supports both R5RS and R6RS out of the box, and there's a library for R7RS support.
  - agumonkey 10y ago
    They're doing a lot of research, so their personal views on how to leverage lisp/scheme heritage shows. For instance, they go deep into eDSL.
  - soegaard 10y ago
    Scheme (as in the R5RS spec and earlier) is a very minimal language specification. This means that all practical Scheme implementation add features not present in the specification. In some areas the Scheme implementors agree - and in others: not so much. Racket has many features not covered by R6RS/R7RS. However due to the module and macro system that enables you create languages (that compiles to Racket modules), it is possible for Racket to provide a language compatible with Scheme. That is: Racket includes an implementation of Scheme.
codemac 10y ago
> and can make real binaries (I think anyway) No, it cannot currently. It makes boot files which still need to be launched with scheme / petite. The build + library/module system with chez is also pretty unusable. If you want to write scheme for a system where you deploy an entire OS, it's not too much to work around. If you're trying to write a 1-off binary, you should go with chicken.
- aseipp 10y ago
  There's a pull request that can effectively fix this, by finally exposing the Chez Scheme C library. Then you can finally write custom boot kernels. I pinged on it recently but nobody updated. I might try resubmitting it. I actually have a full demonstration of using Chez to build a full "Unix application" that works 'just as you would expect'. Comes with complete Chez support: profile-guided rebuilds, coverage support, C extensions, some basic test stuff, a custom C boot kernel, and utility for portable .tar.gz builds. It even correctly copies out the boot files for a reidstributable build. I could have extended this to "unpack the boot file out of my own elf executable" for a truly reusable binary but that seemed overkill. Also, if you keep the boot files, it then becomes possible to still drop into a Chez prompt and load your boot file from there for early debugging, which can be convenient and I didn't want to spend more time on that. But, uhhhh, you're right if you want a one off binary, Chicken or something is way better. I spent like a week working on that skeleton so I could start working on my application itself. And my Makefile to support all this is extremely intense. But it works pretty well now and is very reusable and generic. I'll get around to releasing it now I suppose!
  - sitkack 10y ago
    I have had ok luck with using Gambit for standalone executables
    - throwaway7645 10y ago
      How big is "hello world"
codemac 10y ago
> and can make real binaries (I think anyway) No, it cannot currently. It makes boot files which still need to be launched with scheme / petite. The build + library/module system with chez is also pretty unusable. If you want to write scheme for a system where you deploy an entire OS, it's not too much to work around. If you're trying to write a 1-off binary, you should go with chicken.
steinuil 10y ago
Speed is probably not your most pressing concern if you're using Scheme, I think. Moreover, Racket has the best ecosystem out of all the schemes, with lots of high quality and maintained libraries and a massive standard library, and it's not only a language, but also a platform for creating DSLs fully integrated with its IDE, DrRacket. Also, Racket can create standalone binaries (though they don't make programs any faster).
- peatmoss 10y ago
  And in terms of speed, Racket is generally quite a lot faster than Python. I remember the days when rhetorically people almost assumed that poor execution speed meant higher-level abstractions that translated to greater developer productivity. Slow execution practically became a fitness function (I'm looking at the commentary during the early days of Ruby and Rails here). But with Racket you've got high-level, comparable-to-Python abstraction combined with way better performance today, and even better performance tomorrow. Plus as a bonus, the typed story is good. EDIT: In summary, even if performance wasn't your objective, you're still punching well above comparably high-level languages like Python.
  - sevensor 10y ago
    > Plus as a bonus, the typed story is good. Seriously considering Typed Racket at this point. I like Python, but lately I've been bumping up against the limitations of its type system. (There's only so much you can say about a type in Python.)
  - nemoniac 10y ago
    > But with Racket you've got high-level, comparable-to-Python abstraction Racket's abstraction is indeed high level but in no way comparable to Python. Racket's homoiconicity and syntactic abstraction put it leagues above Python in that regards.
  - throwaway7645 10y ago
    How will it get even better besides occasional tweaks here and there?
lacampbell 10y ago
Is python really that similar from a performance perspective? The highly scientific benchmarks game cough seems to suggest Racket is usually an order of magnitude faster http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=python3&lang2=racket http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
- Johnny_Brahms 10y ago
  Racket is a lot faster. Python is generally slower than guile, which is a lot slower than racket. Racket is according to my unscientific benchmarks, unless the problem lends itself well to an imperative style, in the same ballpark as, but still slower than, C# on mono. Edit: pypy on the other hand is, if the project euler forums are a good source, on par with racket.
- igouy 10y ago
  Sooth that nasty cough. Show us your preferred alternative to the benchmarks game.
abecedarius 10y ago
Some of us do. (Racket is neat too.)
znpy 10y ago
In my own restricted view (I didn't play with may scheme implementations) Racket has some serious non-strictly-technical winning point that make it feasible for non-toy applications: * Well-written, comprehensive language and package documentation * Tooling * Included libraries (example: I didn't expect racket to have libraries for imap... but it's there, in the standard package) A nice development would be same-process parallelism. Afaik, at the moment you can have concurrent "threads" within the same process, but you need to spawn multiple racket vm processes to get parallelism (this is done "under the hood" by the racket vm, they call this things "Places").
e12e 10y ago
> I'm curious why people don't prefer Chez Scheme to Racket if it is so fast and can make real binaries (I think anyway). Just a FYI for those following along at home, racket comes with built-in support for bundling programs as executables - but as I understand it those are really archives with a vm and (byte?)code. I recently tried on Windows, and a "hello world" graphical app was a ~11mb - not bad IMNHO - but bigger than the equivalent Lazarus / free pascal app.
- shakna 10y ago
  Try it again against Chicken and Gambit, which actually produce native executables. There's a decent difference in size, and often in speed.
  - e12e 10y ago
    I will, if I find the time. Do they support graphical applications across Mac, Linux and Windows?
    - shakna 10y ago
      Chicken uses iup, which you can find in Racket as well. Gambit is... Spartan. You'd have to write some bindings yourself.
- throwaway7645 10y ago
  Yea, I'd expect it to be big, but 10 MB is still easily distributable, so not bad. How is the licensing though? Do you have to include the source (GPL) or is that only if you modify the source?
  - e12e 10y ago
    Racket is LGPL - but I'm not crystal clear on the implications for executables - according to the racket team (in this random reddit thread) - it looks like they see stand alone executables as being fine under their LGPL : https://www.reddit.com/r/scheme/comments/2bu321/not_that_i_dont_like_racket/ https://www.reddit.com/r/scheme/comments/2bu321/not_that_i_d... Shouldn't be too far off from gcc/glibc really.

catnaroek 10y ago

Raw performance isn't all there is to a programming language. Racket is so much more flexible and beautifully designed than Python.

throwaway7645 10y ago
Agreed, but if Python is your main weapon of choice, one will usually want to invest next in something really fast to bridge the gap. I wasn't aware Racket is that much faster....I'd like to see some benchmarks.
- catnaroek 10y ago
  I tend to think of Racket as an alternative to Python, rather than a complement to it. C and Rust fit better the latter description. Racket is faster than CPython, but that isn't anywhere near the top of my list of reasons to use Racket instead of Python. When speed is a priority, Rust and MLton (Standard ML) are both much faster than Racket. But: (0) Racket is much more malleable than either Rust or SML. Rather than bash your head trying to model your problem domain in the existing language, you can redefine the language until it's the ideal tool for your problem domain. (1) Unlike other languages that also advertise malleability (Common Lisp, Smalltalk, etc.), Racket is malleable in principled ways, so you can define abstractions without figuratively stomping on abstractions defined by other people (which you might also be interested in using).
  - throwaway7645 10y ago
    How often are you doing something that needs to be turned into a DSL, or is this something that you do all the time once you grok it?
    - catnaroek 10y ago
      More often than I'd like to. In an ideal world, language designs would be perfect out of the box, and the right abstraction for expressing what I want to express would always be available without me having to do anything. Alas, in the real world, languages have limitations, and you can either metaprogram them away or put up with them. For example, a while back I was investigating a general framework for expressing various types of self-balancing search trees without tediously reimplementing the same ideas over and over: (0) A search tree is either a leaf or node. A node is a alternating sequence of subtrees and individual elements, beginning and ending with a subtree. (1) Rebalancing a tree preserves the sequence obtained from traversing it in-order. (2) In the specific case of binary search trees, there exist two kinds of rotations: 3-rotations (rebalancing the sequence “a,x,b,y,c”, where “a,b,c” range over subtrees and “x,y” range over individual elements) and 4-rotations (rebalancing the sequence “a,x,b,y,c,z,d”, where “a,b,c,d” range over subtrees and “x,y,z” range over individual elements). (3) It is very convenient to manipulate purely functional search trees using zippers, for more or less the same reasons it is very convenient to manipulate imperative search trees using iterators. Zipper types can be obtained from tree types using a generic procedure (given the recursive type “T = μR.F(R)”, find the derivative of “F(R)” with respect to “R”, then instantiate it at “T = R”)... if only you could express this procedure in the first place.
      - throwaway7645 10y ago
        Thanks for the reply!
  - mkesper 10y ago
    If you redefine your whole language, how is your experience with understanding your code after say 6 months?
    - kd0amg 10y ago
      I've generally found, both with my own code and others' code, that `some-undocumented-special-form' is about as understandable as `some-undocumented-function' (and a similar equivalence for things that are documented).
    - catnaroek 10y ago
      That greatly depends on how principled (hence convenient) the mechanisms for redefining and/or extending the language are. Metaprogramming in Python has the annoying tendency to create a mess where the implementation details of different parts are tightly coupled to each other. But metaprogramming Racket, especially using syntax/parse, is very clean.
      - throwaway7645 10y ago
        Interesting. I wish there as a Manning "Racket in Action" book. The problem with a lot of Lisp materials is that they show you the basic constructs and not how to best use them (like you talk about above).
        soegaard 10y ago
        Maybe "Beautiful Racket" ? http://beautifulracket.com/ http://beautifulracket.com/
        lispm 10y ago
        On Lisp. PAIP, Common Lisp Recipes, Practical Common Lisp, Lisp Style and Design, AMOP, Object-Oriented Programming in Common Lisp: A Programmer's Guide to CLOS, ... There are various Lisp books which go beyond the basic constructs.
  - lispm 10y ago
    > Unlike other languages that also advertise malleability (Common Lisp, Smalltalk, etc.), Racket is malleable in principled ways, so you can define abstractions without figuratively stomping on abstractions defined by other people (which you might also be interested in using). Just like the Common Lisp Object System Meta-object protocol, readtables, symbol packages, ...
    - catnaroek 10y ago
      I prefer defining things to tweaking them, so I don't find dynamic metaprogramming (CLOS) to be a good enough substitute for static metaprogramming (macros), and Racket's macro system is light years ahead of Common Lisp's. YMMV, of course.
      - lispm 10y ago
        I don't think macros are a good way to implement or even extend object-oriented languages. So I don't think static macroprogramming is a good substitute for a meta-object system.
        catnaroek 10y ago
        Give me a compelling reason to design programs in an object-oriented way. Just to be clear, I don't find the ability to subvert existing definitions particularly attractive, because it undermines my ultimate goal to actually prove things about my programs. --- @lispm, I have reply here because I'm temporarily unable to make new posts. > A large share of contemporary software is written in an object-oriented way. Sure, but how does that contradict my original assertion that Racket's mechanisms for extending and redefining the language are more principled than either Common Lisp's or Smalltalk's? --- > Could it be that you just don't like/use/need/want the object-oriented ways to extend those languages and thus these mechanisms are not 'principled'? You're right that there's an aesthetic component: I don't have much taste for object-orientation. But this isn't just me being close-minded: I would take object-orientation far more seriously if someone could provide an interpretation of object-oriented programs as mathematical objects with nice properties. > How are Racket's mechanisms for extending and redefining the language more principled Racket's macro system is based on a theory of how to macro-expand in a capture-avoiding way, ruling out by construction errors that are very difficult to debug when doing similar things in Common Lisp. And macro systems are more principled than MOPs in that macros are purely static devices: you (re)define the language first, and you use it later. > Especially since Racket provides some of that, too -> Swindle. Object-orientation in Racket is completely opt-in. You don't have to use it if you don't want to, and, in fact, I just don't use it... > Is the CLOS MOP not principled? Why? ... OTOH, in Common Lisp it's far more pervasive. Everything is an object and has a class, and classes can be tampered with in arbitrary ways, precisely using the MOP. How can then you prove anything interesting about how instances of a class will behave under all circumstances? The essence of abstraction is to ignore implementation details, and concentrate on, well, abstract properties. A MOP achieves the opposite thing: it makes all implementation details available everywhere, complicating the problem of abstraction enforcement.

zem 10y ago

racket is just a pure pleasure to use as a language, more so than either scheme or python.

timClicks 10y ago
I thought Racket was a scheme implementation?
- Johnny_Brahms 10y ago
  It was, but then diverged from r6rs and became it's own. One big things is that the cons cell is immutable by default (which means immutable lists), where scheme has set-car! and set-cdr! The racket team wrote a bit about it here: http://racket-lang.org/new-name.html http://racket-lang.org/new-name.html
- steinuil 10y ago
  The Racket language does not follow any of the Reports, so it's technically not a standards-compliant Scheme. On the other hand, the Racket platform supports both R5RS and R6RS out of the box, and there's a library for R7RS support.
- agumonkey 10y ago
  They're doing a lot of research, so their personal views on how to leverage lisp/scheme heritage shows. For instance, they go deep into eDSL.
- soegaard 10y ago
  Scheme (as in the R5RS spec and earlier) is a very minimal language specification. This means that all practical Scheme implementation add features not present in the specification. In some areas the Scheme implementors agree - and in others: not so much. Racket has many features not covered by R6RS/R7RS. However due to the module and macro system that enables you create languages (that compiles to Racket modules), it is possible for Racket to provide a language compatible with Scheme. That is: Racket includes an implementation of Scheme.

codemac 10y ago

> and can make real binaries (I think anyway) No, it cannot currently. It makes boot files which still need to be launched with scheme / petite. The build + library/module system with chez is also pretty unusable. If you want to write scheme for a system where you deploy an entire OS, it's not too much to work around. If you're trying to write a 1-off binary, you should go with chicken.

aseipp 10y ago
There's a pull request that can effectively fix this, by finally exposing the Chez Scheme C library. Then you can finally write custom boot kernels. I pinged on it recently but nobody updated. I might try resubmitting it. I actually have a full demonstration of using Chez to build a full "Unix application" that works 'just as you would expect'. Comes with complete Chez support: profile-guided rebuilds, coverage support, C extensions, some basic test stuff, a custom C boot kernel, and utility for portable .tar.gz builds. It even correctly copies out the boot files for a reidstributable build. I could have extended this to "unpack the boot file out of my own elf executable" for a truly reusable binary but that seemed overkill. Also, if you keep the boot files, it then becomes possible to still drop into a Chez prompt and load your boot file from there for early debugging, which can be convenient and I didn't want to spend more time on that. But, uhhhh, you're right if you want a one off binary, Chicken or something is way better. I spent like a week working on that skeleton so I could start working on my application itself. And my Makefile to support all this is extremely intense. But it works pretty well now and is very reusable and generic. I'll get around to releasing it now I suppose!
- sitkack 10y ago
  I have had ok luck with using Gambit for standalone executables
  - throwaway7645 10y ago
    How big is "hello world"

codemac 10y ago

steinuil 10y ago

Speed is probably not your most pressing concern if you're using Scheme, I think. Moreover, Racket has the best ecosystem out of all the schemes, with lots of high quality and maintained libraries and a massive standard library, and it's not only a language, but also a platform for creating DSLs fully integrated with its IDE, DrRacket. Also, Racket can create standalone binaries (though they don't make programs any faster).

peatmoss 10y ago
And in terms of speed, Racket is generally quite a lot faster than Python. I remember the days when rhetorically people almost assumed that poor execution speed meant higher-level abstractions that translated to greater developer productivity. Slow execution practically became a fitness function (I'm looking at the commentary during the early days of Ruby and Rails here). But with Racket you've got high-level, comparable-to-Python abstraction combined with way better performance today, and even better performance tomorrow. Plus as a bonus, the typed story is good. EDIT: In summary, even if performance wasn't your objective, you're still punching well above comparably high-level languages like Python.
- sevensor 10y ago
  > Plus as a bonus, the typed story is good. Seriously considering Typed Racket at this point. I like Python, but lately I've been bumping up against the limitations of its type system. (There's only so much you can say about a type in Python.)
- nemoniac 10y ago
  > But with Racket you've got high-level, comparable-to-Python abstraction Racket's abstraction is indeed high level but in no way comparable to Python. Racket's homoiconicity and syntactic abstraction put it leagues above Python in that regards.
- throwaway7645 10y ago
  How will it get even better besides occasional tweaks here and there?

lacampbell 10y ago

Is python really that similar from a performance perspective? The highly scientific benchmarks game cough seems to suggest Racket is usually an order of magnitude faster http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=python3&lang2=racket http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

Johnny_Brahms 10y ago
Racket is a lot faster. Python is generally slower than guile, which is a lot slower than racket. Racket is according to my unscientific benchmarks, unless the problem lends itself well to an imperative style, in the same ballpark as, but still slower than, C# on mono. Edit: pypy on the other hand is, if the project euler forums are a good source, on par with racket.
igouy 10y ago
Sooth that nasty cough. Show us your preferred alternative to the benchmarks game.

abecedarius 10y ago

Some of us do. (Racket is neat too.)

znpy 10y ago

In my own restricted view (I didn't play with may scheme implementations) Racket has some serious non-strictly-technical winning point that make it feasible for non-toy applications: * Well-written, comprehensive language and package documentation * Tooling * Included libraries (example: I didn't expect racket to have libraries for imap... but it's there, in the standard package) A nice development would be same-process parallelism. Afaik, at the moment you can have concurrent "threads" within the same process, but you need to spawn multiple racket vm processes to get parallelism (this is done "under the hood" by the racket vm, they call this things "Places").

e12e 10y ago

> I'm curious why people don't prefer Chez Scheme to Racket if it is so fast and can make real binaries (I think anyway). Just a FYI for those following along at home, racket comes with built-in support for bundling programs as executables - but as I understand it those are really archives with a vm and (byte?)code. I recently tried on Windows, and a "hello world" graphical app was a ~11mb - not bad IMNHO - but bigger than the equivalent Lazarus / free pascal app.

shakna 10y ago
Try it again against Chicken and Gambit, which actually produce native executables. There's a decent difference in size, and often in speed.
- e12e 10y ago
  I will, if I find the time. Do they support graphical applications across Mac, Linux and Windows?
  - shakna 10y ago
    Chicken uses iup, which you can find in Racket as well. Gambit is... Spartan. You'd have to write some bindings yourself.
throwaway7645 10y ago
Yea, I'd expect it to be big, but 10 MB is still easily distributable, so not bad. How is the licensing though? Do you have to include the source (GPL) or is that only if you modify the source?
- e12e 10y ago
  Racket is LGPL - but I'm not crystal clear on the implications for executables - according to the racket team (in this random reddit thread) - it looks like they see stand alone executables as being fine under their LGPL : https://www.reddit.com/r/scheme/comments/2bu321/not_that_i_dont_like_racket/ https://www.reddit.com/r/scheme/comments/2bu321/not_that_i_d... Shouldn't be too far off from gcc/glibc really.