Hacker Newsnew | past | comments | ask | show | jobs | submit | frankgrecojr's commentslogin

The hello world example does not work. In fact, no website I've tried works. It's usually always panics. For the example in the readme, the errors are:

```

./lightpanda-aarch64-macos --host 127.0.0.1 --port 9222

info(websocket): starting blocking worker to listen on 127.0.0.1:9222

info(server): accepting new conn...

info(server): client connected

info(browser): GET https://wikipedia.com/ 200

info(browser): fetch https://wikipedia.com/portal/wikipedia.org/assets/js/index-2...: http.Status.ok

info(browser): eval script portal/wikipedia.org/assets/js/index-24c3e2ca18.js: ReferenceError: location is not defined

info(browser): fetch https://wikipedia.com/portal/wikipedia.org/assets/js/gt-ie9-...: http.Status.ok

error(events): event handler error: error.JSExecCallback

info(events): event handler error try catch: TypeError: Cannot read properties of undefined (reading 'length')

info(server): close cmd, closing conn...

info(server): accepting new conn...

thread 5274880 panic: attempt to use null value

zsh: abort ./lightpanda-aarch64-macos --host 127.0.0.1 --port 9222

```


Not OP -- do you have some kind of proxy or firewall?

Looks like you couldn't download https://wikipedia.com/portal/wikipedia.org/assets/js/gt-ie9-... for some reason.

In my contributions to joplin s3 backend "Cannot read properties of undefined (reading 'length')" was usually when you were trying to access an object that wasn't instantiated. (Can't figure out length of <undefined>)

So for some reason it seems you can't execute JS?


Lightpanda co-author here.

Thanks for opening the issue in the repo. To be clear here, the crash seems relative with a socket disconnection issue in our CDP server.

> info(events): event handler error try catch: TypeError: Cannot read properties of undefined (reading 'length')

This message relates to the execution of gt-ie9-ce3fe8e88d.js. It's not the origin of the crash.

I have to dig in, but it could be due to a missing web API.


That's Zig for you. A ``modern'' systems programming language with no borrow checker or even RAII.


Those statements are mostly true and also worth talking about, but they're not pertinent to that error (remotely provided JS not behaving correctly), or the eventual crash (which you'd cause exactly the same way for the same reason in Rust with a .unwrap() call).


Not exactly the same. `.unwrap()` will never lead to UB, but this can in Zig in release mode.

Also `unwrap()`s are a lot more obvious than just a ?. Dangerous operations should require more ceremony than safe ones. Surprising to see Zig make such a mistake.


> UB vs "safe" panic

Yes, it's not exactly the same if you compile in ReleaseFast instead of ReleaseSafe. Both are bad though, and I'd tend to blame the coding pattern for the observed behavior rather than quibble about which unacceptable scenario is worse.

I see people adopting forced null unwrapping for dumb reasons all the time. For the remaining reasons, do you have a sense of what the language deficiencies are which make that feature helpful? I see it for somewhat sane reasons when crossing language boundaries. Does anything else stand out?

> ceremony

Yes. Thankfully ".?" is greppable, but I wouldn't mind more ceremony there, and less for `try` coding patterns.


you shouldn't be unwrapping, error cases should be properly handled. users shouldn't see null dereference errors without any context, even in cli tools...


That too, as a general coding pattern. I was commenting on the criticism of Zig as a sub-par system's language though, contrasting with a language most people with that opinion seem to like.


You could build the same thing in Rust and have the same exact issue.


If that kind of stuff is always preferable, the nobody would use C over C++, yet to this day many projects still do. Borrow checking isn’t free. It’s a trade-off.

I mean, you could say Rust isn’t a modern language because it doesn’t use garbage collection. But it’s a nonsensical statement. Different languages serve different purposes.

Besides, Zig is focusing a lot more on heavily integrating testing, debug modes, fuzzing, etc. in the compiler itself, which when put together will catch almost all of the bugs a borrow checker catches, but also a whole ton of other classes of bugs that Rust doesn’t have compile time checks for.

I would probably still pick Rust in cases where it’s absolutely critical to avoid bugs that compromise security.

But this project isn’t that kind of project. I’d imagine that the super fast compile times and rapid iteration that Zig provides is much more useful here.


That has absolutely nothing to do with RAII or safety…


You should take a look at Superblocks. I think you'll find our building blocks both flexible and extensible to solve you use cases.


Our of curiosity, which specific point does it violate? Would it help to remove the "Show HN: " prefix?


Probably easier to think 'what's a thing to post that would be interesting to HN users' rather than 'what are the precise conditions for maximum posting frequency'. 'We're iterating very fast and have some new features' is usually not interesting enough to get around the 'about once a year for reposts in Show HN' standard.

Of course, you can, as you point out, post outside Show HN but the same applies - the promotional effect has to be a consequence of interestingness so if you focus on interestingness, you get both and everyone wins.


Perhaps. Those who want to do that can leverage our Javascript and Python blocks to write whatever code they'd like.

Most of our platform is centered around "integrations". For example, You'd have a visual block for an S3 integration (that would have been previously configured) that you'd use rather than initializing an S3 client in code for example.

We want to meet people where they're at though. If you want to write code, you can do that but if you want to use a more visual approach, you can do that as well.


Another way to maybe approach this is to consider programming constructs that are "hard" to understand. Imagine you want to "do n things in parallel". If your company uses Java (or any language where it's no trivial to do concurrency), this is not straight forward. A visual way to do this makes it much easier.


Superblocks can absolutely be used to build something to solve this use case.


Each one of these "APIs" has a json/yaml DSL that could be constructed with any builder pattern. We just haven't released a public API for this yet.


We provide an agent deployment model that allows your data to never leave your network. We do not however offer an air-gapped solution.

Superblocks, Retool, and Airflow provide different approach to solve similar problems. We've found that lots of customers prefer Superblocks.


> We provide an agent deployment model that allows your data to never leave your network

I had i rapid look at the docs and, for what I understand, the agent is "dumb" and need to continuously contact your cloud (similar to github/gitlab ci runners) and also the user interface is on cloud. Correct?


The UI executes APIs against this agent which talks to Superblocks to fetch API definitions to run. These definitions will be "signed" by a key that only the agent is the authority of so customers can guarantee that it hasn't been tampered with.


n8n AFAIK is a workflow builder whereas at Superblocks, we are an Application builder (in addition to a workflow builder). We enable developers to build user interfaces that "bind" to APIs that they build with this feature.


I have yet to see a drag-n-drop workflow framework that captures the developer market. Every tool eventually lands on citizen developers.

Writing the code always ends up being easier and you can build visuals on that if you really need them.

Maybe this is closer to https://bubble.io/? (https://manual.bubble.io/help-guides/logic)


This is actually a completely separate feature! We're just iterating fast! Our AI launch introduced the ability to have AI generate and refactor code for you in our platform.


I usually expect "Show HN" posts to be about new products/projects you’ve worked on, not to post every feature annoucement of your company.

Also:

> Please make it easy for users to try your thing out, ideally without barriers such as signups or emails. You'll get more feedback that way.

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


Thanks for this! I personally wrote a significant portion of this feature am very excited about this new tech!

Unfortunately we require email to signup but have a free trial. Users are able to test end to end in just a few clicks.


Right but that's not really the cadence of Show HN which has its own weird rules.


I agree. We believe we've pulled off what hasn't been done before and solve the issues you mention. We're adding "step though debugging" (simple version is live today), version control (upcoming weeks), etc. to give an enterprise ready experience.


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: