HN user

andrew_rfc

228 karma
Posts19
Comments19
View on HN
6over3.com 2mo ago

The End of the Mind

andrew_rfc
2pts0
github.com 7mo ago

Show HN: A distraction-free writing environment

andrew_rfc
1pts0
andrews.substack.com 8mo ago

TypeScript X Perl

andrew_rfc
3pts0
andrews.substack.com 8mo ago

Embedding TypeScript

andrew_rfc
1pts0
andrews.substack.com 9mo ago

Reverse engineering iWork

andrew_rfc
123pts5
github.com 1y ago

Show HN: embedding Apple Intelligence on-device models in any application

andrew_rfc
1pts0
yume.sh 1y ago

Yume – Transform your content with GPU shaders

andrew_rfc
1pts0
andrews.substack.com 1y ago

4 mains or nothing at all

andrew_rfc
16pts0
andrews.substack.com 1y ago

Get in loser. We're rewinding the stack

andrew_rfc
87pts2
andrews.substack.com 1y ago

Show HN: Sandboxing Perl with WebAssembly

andrew_rfc
5pts0
github.com 1y ago

Show HN: An experimental 2D/3D game engine for the terminal

andrew_rfc
11pts2
3124.co 1y ago

Show HN: Project 3124

andrew_rfc
1pts1
dolus.app 1y ago

Extending the Windows Shell Progress Dialog

andrew_rfc
2pts0
dolus.app 1y ago

Dolus

andrew_rfc
2pts0
github.com 2y ago

Bebop v3: a fast, modern replacement for Protocol Buffers

andrew_rfc
46pts42
github.com 2y ago

Source Code for Area 51 (2005) by Midway Studios Austin Found at Garage Sale

andrew_rfc
203pts73
github.com 3y ago

Show HN: Tempo – gRPC alternative, faster and browser/serverless-friendly

andrew_rfc
1pts0
gist.github.com 3y ago

Show HN: Crack this cipher and get $100

andrew_rfc
2pts6
github.com 3y ago

Show HN: Tempo – low latency, cross-platform, end-to-end typesafe APIs

andrew_rfc
2pts0

I spent a few days brute forcing tables before I came across your repo and it finally clicked what was actually going on; thank you so much!

Would this require using the WASIX libc? I didn’t spend much time on it, but when I attempted to use it the build started failing in mysterious ways - happy to open an issue on the relevant repo with a reproduction / notes on what I think our some bugs.

You cannot today build anything on the Blead of Perl with perlcc.

Support has languished because the language changed fast enough that it never kept up. It may be used in the industry, but for a modern Perl application (or anything past 5.10) it won’t work. Hence why it was removed.

I’m not sure where you got the idea it’s slow, but it executes within 30% of native speed. Which means extracting the metadata from a 30 GB pro video in my test takes 300-400ms.

Speaking of - libexif doesn’t support a lot of file formats, whereas ExifTool does.

If I always opt to choose the easiest path then I’m setting a precedent for myself that I will compromise on all my goals for half finished solutions that take me further from initial idea.

Author here: it wouldn't have been. Sure, it would be nice to have a native version, but that is a lifelong maintenance burden, and ExifTool is already the best at what it does and stays up-to-date with file format changes.

By completing this work, I can use ExifTool in any environment now - and more broadly, there is now a portable, embeddable, and sandboxed version of Perl that others can use in their projects. I can think of a lot of use cases, and helping other developers makes any hardship I endured worth it.

In its current state it’s mostly just something fun to toy around with if you’re interested in game engine development; once it’s more mature I’ll probably ship a game on it. I have POC multi-player setup where you can telnet to a box and join a 3D world with other users.

Apologies if my initial comment came off the wrong way; when I say “not alternatives” I was injecting bias into that statement since I normally use Cap’n Proto on embedded and memory constrained systems (amazing library btw.)

When I created Bebop years ago I tried to benchmark it against Cap’n Proto, but the lack of a semi-decent web or C# implementation mentally made me recategorize.

So I suppose I’m just comparing what’s closest in terms of ecosystem support rather than a purely functional level.

you get forward and backwards compatibility out of the box so long as you adhere to the schema guidelines.

The docs go into more detail on how different types are handled. We also have some special features like “binary schema” which let you ship your schema with data so clients are always up to date.

Cap’n Proto and Flatbuffers are not alternatives to Protocol Buffers. They solve entirely different issues and have distinct limitations.

They aren’t relevant to what Bebop is doing and thus no benchmark or comparison can be made between them.

They were never particularly all that fast, especially not in the browser where support is far from acceptable. Most implementations rely on runtime magic, reflection, and other hacks.

So in that sense they aren’t all that modern as they’ve failed to evolve and keep up with platform evolutions.

Bebop just aims to generate code that modern and current with its target language, works everywhere, and avoids pitfalls protobuf suffers from.

We don’t benchmark against FlatBuffers or Cap'n Proto for a few reasons:

- They are impossible to benchmark against each other without making an assumption about how often you want to access the data, and which parts of it you want to access. But this means Bebop, Cap'n Proto, FlatBuffers can exist side-by-side / solve different problems: what FlatBuffers and Cap'n Proto do makes sense if you want to access only parts of your objects in limited specific ways, what we do is better if you're always interested in the whole packet.

- We don’t benchmark against Capt’n Proto because it does not have a stable web-based implementation, at least not one that has the features that make it so fast natively, so there is nothing to compare.

Basically, Bebop is great for message oriented applications or where you need the entirety of your packet deserialized in a single step. So we can only benchmark against similar formats (JSON, Protobufs, MsgPack, etc.)