Racket 7.8 | Hacker News Reader

Racket 7.8

blog.racket-lang.org

171 pointssamth30 comments

For those who like me aren't familiar with the concept of "float boxing", I think this is the same thing: https://www.lexifi.com/ocaml/unboxed-floats-ocaml/

Basically if I understand correctly this removes an indirection when using floats, probably reducing the memory footprint and improving performance.

For computations using a lot of float arithmetic it removes boxing and unboxing. Say: (fl+ (fl* f1 f2) (fl* fl3 fl4)). This has to unbox fl1 fl2 fl3 and fl4, but racket 7.7 immediately boxes the result of fl* only to unbox it again for fl+. This new racket does not.

I like the HTTP speed ups. I wonder how fast the new engine is in general.

I have played with Chez, haven’t had time to try doing a serious amount of Racket but worry about algorithmic performance-graph traversals, for instance.

I'm not very up on about the chez integration into racket, but on it's own, chez is/was consistently at the top of scheme performance benchmarks in almost all areas - it's nearly 40y old with continuous improvements/research into performance throughout the history and was sold commercially for many years and well past the era where buying tools for software development is the default.

This paper from 15 years ago should impress anyone interested in compiler design performance, esp. for weakly typed languages or lisps:

https://legacy.cs.indiana.edu/~dyb/pubs/hocs.pdf

Is HN still running on Racket via arc? Have you guys tried out the chez backend?

I think you mean the chez backend? Chicken is a different scheme implementation.

Yes, thanks! Just edited

Anyone try running this on iOS? Does the CS backend always definitely need writable executable memory access (not available on iOS) or can it interpret a bytecode?

https://defn.io/2020/01/05/racket-on-ios/

Ah yes I remember seeing this then forgot. Thanks! :D

Use https://racket-stories.com to find old Racket stories.

Cool! I have a gemini PDA that runs AArch64, always good to be able to do more functional programming on it :)

> Racket CS may become the default Racket implementation in the next release

Looking great!

I’m curious why we have aarch64 and not ARM64?

"AArch64 is the 64-bit state introduced in the Armv8-A architecture (https://en.wikipedia.org/wiki/ARM_architecture#ARMv8-A). The 32-bit state which is backwards compatible with Armv7-A and previous 32-bit Arm architectures is referred to as AArch32. Therefore the GNU triplet for the 64-bit ISA is aarch64. The Linux kernel community chose to call their port of the kernel to this architecture arm64 rather than aarch64, so that's where some of the arm64 usage comes from.

As far as I know the Apple backend for aarch64 was called arm64 whereas the LLVM community-developed backend was called aarch64 (as it is the canonical name for the 64-bit ISA) and later the two were merged and the backend now is called aarch64."

https://stackoverflow.com/questions/31851611/differences-bet...

After a little research it looks like aarch64 (Arm ARCHitecture 64-bit) is the official name. ARM64 comes from the previously closed source llvm backend for aarch64 made by Apple: https://www.phoronix.com/scan.php?page=news_item&px=MTY5ODk, but is now used as shorthand, like x64.

> like x64

I seem to recall reading somewhere that "x64" actually referred to something which was distinct from x86_64 (was it a special mode of using 32-bit pointers with a 64-bit kernel? I can't remember exactly now), but now that I am googling for it, I can't seem to find anything.

You're thinking of x32 ABI [1].

[1] https://en.wikipedia.org/wiki/X32_ABI

Because ARM decided to "relabel" their 32-bit architecture as AArch32 and the 64b one as AArch64, and most people just followed with that to avoid confusion.

Furthermore "ARM64" collides a slight bit with ISA revisions naming scheme, which is of the form ARMvX-<variant>.

My understanding is that it is the same thing

https://en.m.wikipedia.org/wiki/AArch64

Aren't they one and the same thing? Like x86-64 and amd64?

And still no proper dependency versioning, it seems that the progress made by Npm, RubyGems, Cargo is entirely lost on them.

Please don't be a jerk when discussing other people's work in HN comments. It subtly poisons the environment.

https://news.ycombinator.com/newsguidelines.html

Racket has a much smaller community. Also, it is more geared towards academic/hobby work than towards production software.

So priorities are different from the languages you mentioned. Still, racket remains by far the best solution for research in language technology.

You might be interested in Bogdan Popa's new Racksnaps work: https://defn.io/2020/05/03/ann-racksnaps/ or Sage Gerard's new work on zcpkg: https://github.com/zyrolasting/zcpkg.

There are a vast number of critiques regarding the model those ecosystems have used; it would be unwise to stick the label 'progress' on them until some of those core problems are resolved.

With regards to dependency versioning? I wasn't aware of that. I've been very happy with Cargo's handling of versioning so far, but maybe I've been lucky and haven't hit the pain spots.

That's rich considering Python is routinely criticized here for lack of proper dependency management until recently. Just because Racket is a cute Lisp/academic language does not mean it should be held to lower standards especially considering their recent efforts in relicensing and marketing to be regarded as a "serious" production language.

Be the pull request you want to see in the world

Ain't nobody got time for that.

Reply on news.ycombinator.com