Bogdanp

I don’t expect that these scripts will be complex enough to warrant knowing about metatables. They will mostly be about filtering data and maybe doing some math, in which case the infix notation will come in handy. That said, the app will let folks use Racket if they want to. I just don’t want to scare them off with the parens, which many people are unfortunately allergic to, as you say.

> How much of the standard Lua test suit can your implementation pass?

I haven't tried it yet, but I don't believe it would get very far since I haven't yet exposed ways to load Lua code from Lua modules (`dofile`, `load`, `require`, etc.). I've been building up my own test suite[1] while working through the reference manual[2]. I had never really used Lua before this, so it's been pretty interesting learning the language while implementing it.

> Do you have some benchmarks to compare the speed?

I've been using programs from the benchmarks game[3] and comparing them against regular Lua on my machine. On these programs, the overhead is usually somewhere around 2-3x. I believe that's mostly because these programs tend to be very mutation heavy. It's also possible that the way I'm compiling things down to Racket is defeating optimizations, but I haven't yet dug in.

If you're curious, you can get it to print the code it generates for any given module by setting the `RACKET_LUA_DEBUG` env var to `x` before running some code. Eg:

    $ echo -e '#lang lua\nprint(1)' > test.lua
    $ env RACKET_LUA_DEBUG=x racket test.lua
    <<test.lua>>
    '((#%provide #%chunk)
      (#%define _ENV (#%global))
      (#%load-stdlib! _ENV)
      (#%define (#%lua-module . #%rest) (#%begin (#%begin (print 1)) (#%values)))
      (#%define #%chunk (#%adjust (#%lua-module))))
    1

> What is the problem with scientific notation? Racket can parse floating point numbers, including some weird cases [1], but I guess Lua has a slightly different set of weird cases.

Yup. I just haven't gotten around to it. My goal this week has been to get it to a usable spot for embedding in my app and then iterate from there.

[1]: https://github.com/Bogdanp/racket-lua/tree/master/lua-test/l...

[2]: https://www.lua.org/manual/5.4/manual.html

[3]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/

But individual countries within the EU can and do have constitutions. Here's title 2, chapter 2, article 28[1] of Romania's constitution:

> Secretul scrisorilor, al telegramelor, al altor trimiteri poştale, al convorbirilor telefonice şi al celorlalte mijloace legale de comunicare este inviolabil.

> Secrecy of the letters, telegrams and other postal communications, of telephone conversations, and of any other legal means of communication is inviolable.

[1]: http://www.cdep.ro/pls/dic/site2015.page?den=act2_1&par1=2&i...

“Pure Python” commonly means implemented using only the Python language. Something written in pure Python ought to be portable across Python implementations. I was merely pointing out that this line

https://github.com/python/cpython/blob/4395ff1e6a18fb26c7a66...

isn’t exactly pure Python, because, under a different runtime (eg PyPy), the code would take a different path (the “pure Python” implementation of _count_elements[1] instead of the C implementation[2][3]). Yes, it's hard to draw exact lines when it comes to Python, especially as the language is so tied to its implementation. However, I think in this case it's relatively clear that the code that specific line is calling is an optimization in CPython, specifically intended to get around some of the VM overhead. Said optimization comes into play in the OP.

[1]: https://github.com/python/cpython/blob/4395ff1e6a18fb26c7a66...

[2]: https://github.com/python/cpython/blob/4395ff1e6a18fb26c7a66...

[3]: https://github.com/python/cpython/blob/4395ff1e6a18fb26c7a66...

I have no dog in this fight, but I do want to point out that’s it’s not exactly true that Counter is implemented in pure Python:

* it’s a subclass of dict

* its update method (used by the code in the post) dispatches to a C implementation on its fast path

Author here. It's strange seeing this on HN this morning! We shut down the site in march for non-business reasons. Despite what a couple comments here are implying, sales were indeed made and quite a sizeable number of customers were sad to see us go. If I were to do it again, I wouldn't change a thing. As stated in the article, the "code parts" remained the easiest parts throughout.

I agree that Racket development is less interactive than CL development partly because of the slower compile times and partly because of the way the editors choose to reload modules on change. Nothing inherent prevents fast reloading[1], though, and Racket development is still plenty interactive[2].

I would say the package story is more complicated in CL as a consumer of packages. As a package creator, they're similarly complex.

[1]: https://www.youtube.com/watch?v=wWj7OPvXGgA [2]: https://www.youtube.com/watch?v=7uGJJmjcxzY&t=495s

> Last I checked it was pretty slow

I agree it is slower than the fastest CL implementations, depending on what you test, because some of the features present in the language make optimizations harder. The compiler is definitely also slow. As far as dynamic languages go, however, Racket is very fast in general and you can push it very far.

> use in production was not its main focus.

What makes you say this/what do you think it's missing as far as "use in production" goes? Instrumentation? Something else? I've deployed both production web apps and desktop apps with Racket, and the experience has been as good or better than other languages I've deployed similar things in.

What made it not a practical competitor to CL before for you?

Racket has a nice runtime (much nicer than what you get with CL, though with some downsides (eg. memory usage is higher in Racket)), a large standard library, a comparable number of packages (~1800 on pkgs.racket-lang.org versus ~2100 on quicklisp), good editor support and a pretty great distribution story (via `raco exe`, `raco distribute` and the relatively-new `raco cross` for cross-compilation). All things that make it very practical in my book.

> It looks like this means "Racket-on-Chez-Scheme"(i.e. "Racket >= 8.0") will run, but it won't use Chez Scheme it'll default to the old system: https://github.com/racket/racket/issues/3802

No, that item means Racket CS runs on platforms where native code generation isn't available via a portable bytecode backend.

I think it depends whether you consider me making a model in my head of how things are supposed to fit together a "derivative work," which I don't. The codebases are vastly different, and it's clear in certain places that kafka-python has taken inspiration from librdkafka (2-clause BSD license), and that both have similarly taken inspiration from the Java client (Apache 2), which makes complete sense to me since the docs are insufficient for building a client, as I mentioned in my OP.

I've been working on a pure-Racket Kafka client[1] off and on (for fun) since February and it's a good amount of work. When the official protocol docs and Wireshark fail me, I usually look at librdkafka and kafka-python[2] to figure out how things are supposed to fit together. Kudos to the authors of both libraries for writing code that's easy to follow!

[1]: https://defn.io/2022/03/12/ann-racket-kafka/

[2]: https://github.com/dpkp/kafka-python

You can also pick your own epoch and use centiseconds since that epoch for the time component. It's what I do in [1].

[1]: https://docs.racket-lang.org/buid/index.html?q=buid#%28part....

> Does this allow AOT compiling of Racket code to native ARM?

Yes, there's an example of this in the section "Cross-compile Racket modules for iOS".

> Assuming that JIT is still not possible on iOS.

JIT on iOS is not possible for non-side-loaded apps, like you mentioned downthread. That's part of the caveats[1] I mention at the top of the article and the more complex part of the change: when compiling new code (eg. via `eval`), we flip the protection bits between W and X for the minimum set of memory segments necessary based on certain heuristics.

[1]: https://github.com/racket/racket/blob/351c0047d6371e36cf422b...

As far as I know, no. I believe the restriction on language embedding that you might be thinking of was very short-lived.

The Racket runtime is also embedded so you can compile and run arbitrary code at runtime as well.

> So, does this mean that a library/module written in Racket can be called from an iOS application written in Swift?

Yup! There’s an example of just that at the very end.

Shameless plug: I wrote and use nemea[0] for all my stuff.

[0]: https://github.com/Bogdanp/nemea

As of a couple releases ago, the message gets set according to the status code so this code would behave as expected:

    (response/xexpr #:code 404 '(h1 "Not Found"))

You don’t have to specify those things yourself unless you want to manually construct a response struct. There are helpers like response/xexpr and response/output that construct responses for you.

This article might help: https://defn.io/2020/02/12/racket-web-server-guide/

Yes, definitely. I was just struck by how close some of the similarities were in this case. That said, it is a simple enough class of app that there are bound to be similarities between them and I was sincere in congratulating the OP.

Congrats on launching!

I have to say, though, this looks uncannily like my own app, Remember, that I launched a few months ago:

* https://remember.defn.io/

* https://apps.apple.com/ro/app/remember-quick-reminders/id149...

* https://github.com/bogdanp/remember

Right down to the key bindings and some of the marketing copy[1].

[1]: https://www.producthunt.com/posts/remember-6

https://defn.io . I mostly write about Racket-related stuff.

I know these people willingly shared this information in public, but, for whatever reason, this compilation makes me uncomfortable.

EDIT to clarify: what makes me uncomfortable about this is not the broad range of salaries. I don't find that surprising at all. It's gathering all this information together and associating it with people's names (and complete bios!) that bothers me. Some of them may find they want to delete those tweets later.

Thank you for the kind words!

If you log into your gumroad account and go to gum.co/rememberapp you should have the option to "purchase again" under the download button.

Sending/receiving (plus encoding and decoding) one payload takes less than 100 microseconds on my machine. It's far from being a problem, although you're right that linking against a shared library and making the calls that way would be faster.

> Very interesting choice! The Racket code is beautiful, and I like that it's parsing user input as commands.

Thanks! I wrote the core in Racket to make it easy to port the app to other platforms and because I'm a lot more productive when writing Racket code.

> One feature a user might want is an overview of stashed notes.

You can actually see your stashed entries by pressing the up/down arrows or ctrl+n :D

I've been using org-mode capture templates for years and I've always wished I had something like that for the whole system. I took advantage of the holiday break to build this. The UX is a lot like Spotlight, but instead of using it to find files, you use it to create quick reminders.

Pre-built versions are available (for pay-what-you want (including $0)) on Gumroad[1].

[1]: https://gumroad.com/l/rememberapp

My bad! I had set the `autoplay` attribute to `"false"`, thinking it wouldn't autoplay. And it didn't, at least in Firefox, but reading the MDN docs for the `video` element, I can see that browsers'll try to autoplay the video if it's present. It's fixed now.

It depends upon what you mean by slow. Typed Racket code compiles more slowly than normal Racket code, but should run about as fast or faster (for a small set of specifically-typed code[0]).

[0]: https://docs.racket-lang.org/ts-guide/optimization.html