4 ms·

The future of Raphters, a web framework for C.

19 points by DanWaterworth 16y ago

JoachimSchipper 16y ago
Previously: http://news.ycombinator.com/item?id=2407334 http://news.ycombinator.com/item?id=2407334. The author seems to have taken a good look at some of the suggestions given there - or am I just imagining that?
- DanWaterworth 16y ago
  Yes, I've certainly studied the suggestions made in those comments. This design document represents a sharp change in design.
JoachimSchipper 16y ago
Personally, I'd want to have a --disable-v8 option. If I'm writing a web application in C, I must have had tight speed/memory/code size requirements; a JSON-based v8-backed template language doesn't seem to fit very well. (Yes, v8 is pretty fast, but if it's fast/small enough for what I'm doing, I wouldn't be using C.)
- DanWaterworth 16y ago
  You will be able to disable v8.
  - vmind 16y ago
    Have you considered LuaJIT instead of v8? Given you are using v8 as a target VM for compiling another language to javascript, and lua is quite similar, although if other javascript libraries are used that could be a major factor. (This is assuming you are writing Chrysalis/Stencil)
    - DanWaterworth 16y ago
      That's a good idea. (I am writing Chrysalis/Stencil). The current design is that there is a code-generator that outputs javascript which can be run on either side. But outputting Lua instead for the server-side would seem possible.
      - silentbicycle 16y ago
        Also, compiling to Lua is not a bad option. Its syntax (http://www.lua.org/manual/5.1/manual.html#8 http://www.lua.org/manual/5.1/manual.html#8) is quite straightforward, and it's designed to compile rapidly (due to using table as a JSON-like serialization format). While writing out a (kinda silly) benchmark a while ago, it struck me that, while Python's compiler is rather slow, Lua's has very little impact on the overall runtime. Between that and the lack of weird corner cases in the grammar, I'm reasonably comfortable doing string-eval metaprogramming in Lua, something I would never do in Python. Benchmark (http://news.ycombinator.com/item?id=1800396 http://news.ycombinator.com/item?id=1800396) and commentary (http://news.ycombinator.com/item?id=1804166 http://news.ycombinator.com/item?id=1804166).
    - swah 16y ago
      Bump! Lua is small and sweet. Zed Shaw picked it for his framework, not that unlike Raphters in some ways: http://tir.mongrel2.org/home http://tir.mongrel2.org/home
      - throwa_way 16y ago
        Specifically, the luajit implementation is known for being ridiculously fast. http://luajit.org/performance.html http://luajit.org/performance.html http://lua-users.org/lists/lua-l/2009-06/msg00071.html http://lua-users.org/lists/lua-l/2009-06/msg00071.html
        silentbicycle 16y ago
        Normal Lua's performance is also quite decent (especially compared to its peers: Python, Ruby, and Perl), and has a very clear path for moving hotspots out to C. LuaJIT's performance is just a bonus. :)

19 points by DanWaterworth 16y ago

Previously: http://news.ycombinator.com/item?id=2407334 http://news.ycombinator.com/item?id=2407334. The author seems to have taken a good look at some of the suggestions given there - or am I just imagining that?

DanWaterworth 16y ago
Yes, I've certainly studied the suggestions made in those comments. This design document represents a sharp change in design.

JoachimSchipper 16y ago

Personally, I'd want to have a --disable-v8 option. If I'm writing a web application in C, I must have had tight speed/memory/code size requirements; a JSON-based v8-backed template language doesn't seem to fit very well. (Yes, v8 is pretty fast, but if it's fast/small enough for what I'm doing, I wouldn't be using C.)

DanWaterworth 16y ago
You will be able to disable v8.
- vmind 16y ago
  Have you considered LuaJIT instead of v8? Given you are using v8 as a target VM for compiling another language to javascript, and lua is quite similar, although if other javascript libraries are used that could be a major factor. (This is assuming you are writing Chrysalis/Stencil)
  - DanWaterworth 16y ago
    That's a good idea. (I am writing Chrysalis/Stencil). The current design is that there is a code-generator that outputs javascript which can be run on either side. But outputting Lua instead for the server-side would seem possible.
    - silentbicycle 16y ago
      Also, compiling to Lua is not a bad option. Its syntax (http://www.lua.org/manual/5.1/manual.html#8 http://www.lua.org/manual/5.1/manual.html#8) is quite straightforward, and it's designed to compile rapidly (due to using table as a JSON-like serialization format). While writing out a (kinda silly) benchmark a while ago, it struck me that, while Python's compiler is rather slow, Lua's has very little impact on the overall runtime. Between that and the lack of weird corner cases in the grammar, I'm reasonably comfortable doing string-eval metaprogramming in Lua, something I would never do in Python. Benchmark (http://news.ycombinator.com/item?id=1800396 http://news.ycombinator.com/item?id=1800396) and commentary (http://news.ycombinator.com/item?id=1804166 http://news.ycombinator.com/item?id=1804166).
  - swah 16y ago
    Bump! Lua is small and sweet. Zed Shaw picked it for his framework, not that unlike Raphters in some ways: http://tir.mongrel2.org/home http://tir.mongrel2.org/home
    - throwa_way 16y ago
      Specifically, the luajit implementation is known for being ridiculously fast. http://luajit.org/performance.html http://luajit.org/performance.html http://lua-users.org/lists/lua-l/2009-06/msg00071.html http://lua-users.org/lists/lua-l/2009-06/msg00071.html
      - silentbicycle 16y ago
        Normal Lua's performance is also quite decent (especially compared to its peers: Python, Ruby, and Perl), and has a very clear path for moving hotspots out to C. LuaJIT's performance is just a bonus. :)