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

Location: Canada <-> Central America <-> Mexico

Remote only : 10 years remote, 12 years experience

Technologies : C, C++, SIMD, OpenGL, WebGL, WASM, JS, TS

Interests : systems programming, 2D & 3D graphics, performance

--------

Hello, my name is Jesse.

I describe myself as a competent generalist, and a lifelong learner. I'm frequently working on something I've never done before. My most recent professional experience has been about a year at a semiconductor startup; I wrote prototypes for an ISA, compiler and a (really sweet) cycle simulator & debugger.

In terms of hard technical skills, I can quickly become productive in nearly any language, and at any level of the stack. I'm comfortable working in soft-realtime environments which are heavily multithreaded/async, and performance is a key acceptance criteria. I have a good understanding of modern hardware architectures, including GPUs, from main memory to registers and instruction pipelines. I have working knowledge of interpreters and dynamic language runtimes, including GCs. I'm convinced I can learn nearly anything (albeit some things more quickly than others), given an appropriate problem domain to apply it to.

In terms of business value, I can take hand-wavy visions of new products and turn them into working prototype(s), quickly. I'm comfortable refining those raw materials and delivering real value to customers, internal or external. I have a long track record of successfully identifying 80/20 solutions and love the feeling of making tools that make peoples lives better.

I'm a natural leader; informal teams coalesce around me when I'm not in a labelled position of leadership. I aspire to someday, maybe in the far future, become a strong technical leader. One of my best qualities is my (nearly) unwavering personal vendetta against mediocrity. I'm generally friendly and easy to get along with, but do not hesitate to volunteer constructive criticism where I see room for improvement. This has caused friction for me in the past, but I'm now generally good at gently steering my teammates in the direction of technical excellence.

In my personal life, I enjoy travelling, surfing, climbing, backcountry skiing, snowmobiling, pirates, and attending raves. I like the phrase "have strong opinions, weakly held".

If I was born to do one thing in this world, it's program computers.

Jesse

--------

https://scallywag.software

https://scallywag.software/resume.html

https://github.com/scallyw4g

jesse@scallywag.software


I've been working on a 3D voxel-based game engine for like 10 years in my spare time. The most recent big job has been to port the world gen and editor to the GPU, which has had some pretty cute knock-on effects. The most interesting is you can hot-reload the world gen shaders and out pop your changes on the screen, like a voxel version of shadertoy.

https://github.com/scallyw4g/bonsai

I also wrote a metaprogramming language which generates a lot of the editor UI for the engine. It's a bespoke C parser that supports a small subset of C++, which is exposed to the user through a 'scripting-like' language you embed directly in your source files. I wrote it as a replacement for C++ templates and in my completely unbiased opinion it is WAY better.

https://github.com/scallyw4g/poof


That is so neat. I built something a little bit like this for a simulator of a 3D portal mill. Trying it on real wood got expensive fast so for debugging runs and trials of designs I would run a simulation where the toolbit would hack out the shape out of a three dimensional array of voxels. This was then displayed using a very simple engine built with PyGame. I got a lot of use out of that and it saved days (and a small forest).

Great to see something along those lines but with much better visuals.


That's an interesting application! I'm excited to see where these kinds of projects go now that we have so much computing power.

This thing I built was in 2006 or so iirc, here is a screenshot:

https://jacquesmattheij.com/snapshot4.png

Apologies for the low resolution, I don't think I have a better one.


Wow the voxel engine work is beautiful! Impressive work man

Thank you! It's definitely been a labour of love

Cool. Especially love the low dependency approach. Readme says OpenGL 3.3. Are you doing the GPU compute using old-school GPGPU techniques?

Yeah, just render to texture, with one instance of cpu readback (for generating voxel data). There are a couple features I'd like to implement that require 4.3, but I'm pretty committed to the bit at this point. Maybe one day I'll have some optional features.

Do you know the whole story about HyTale? I feel like you'd be an amazing fit to help out there.

I'm nominally familiar with the story. Are you connected to the team in any way? I'd be interested in learning more about the project

"Function" link in the Examples section of the poof repo is 404.

Oh, thank you! Will fix that when I'm at my laptop

Looks so good!

Thank you!

Pretty sure this is here, my dude.


What are you referring to?


My bad, didn't fact check myself before I made an annoying quip. For some reason I thought browsers and started to roll out out native support for TS.


It's been stuck at stage 1 since early 2022 unfortunately. https://github.com/tc39/proposal-type-annotations


Maybe you got confused, because NodeJS is now able to strip annotations (it does not transform enums, etc) to let you run Typescript files directly.


Ahhhh, that was it. Thank you


Not sure what the Rust situation is like, but last I checked (and compiled a non-trivial personal application) WASM supported the pthreads API and it seemed to work reasonably well. Have you encountered stumbling points porting a heavily MT Rust program to WASM?


That's supposedly WASI, an interface specifically designated for system programming use, and that's where it implements part of the POSIX support including pthread.

OTOH you still need to start a wasm runtime first, then import the WASI module into the wasm host.

P.S.: used to tinker with wasmtime and wasmi to add wasm support to my half abandoned deno clone ;) I learned this the hard way


WASI does not implement POSIX. And it isn't the goal of WASI to implement POSIX. It does not support pthreads either. WASI is similar to POSIX because its an API that provides a "system interface" for WASM programs. But the API is much simpler and quite different and capability based. There are things like WASIX (by Wasmer) built on of WASI that aims to provide POSIX support for multiple languages


I think GP was probably using Emscripten


Correct


WASM itself does not support pthreads. However things like Emscripten have very good support for pthreads. WASM is one of the compilation targets of Emscripten (we had asm.js before that) and on top of that emscripten provides excellent shims for many POSIX APIs. Regarding Rust which has supported WASM as a compilation target for a long time now, the idiomatic way of doing this is not shiming, but using higher level APIs: if you need parallel execution threads and need to compile to WASM you would use a crate (such as rayon) that is able to compile to WASM (and will use web workers under the hood just like Emscripten does). You would not use pthreads directly (std::thread)


WASM does not support pthreads in the browser, only web workers, which are much more limited.


Hot take alert

> When is WASM finally going to be able to touch the DOM?

Coming from a web background, and having transitioned to games / realtime 3D applications...

Fuck the DOM dude. The idea that programming your UI via not one but TWO DSLs, and a scripting language, is utter madness. In principal, it might sound good (something something separation of concerns, or whatever-the-fuck), but in reality you always end up with this tightly coupled garbage fire split across a pile of different files and languages. This is not the way.

We need to build better native UI libraries that just open up a WebGL context and draw shit to that. DearIMGUI can probably already do like 85% of what modern webapps do.

Anyways .. /rant


> DearIMGUI can probably already do like 85% of what modern webapps do

I’m with you. Main blocker I’ve seen to “just use ImGui for everything” (which I’d love to adopt), is if I run ImGui in WASM the keyboard doesn’t open on mobile. This seems possible in theory because egui does it.

Even though running ImGui on mobile via WASM isn’t the primary use case, inevitably the boss or someone is going to need to “just do a quick thing” and won’t be able to on mobile, and this seems to be a hard ceiling with no real escape hatch or workaround.

One of those scenarios where, if we have to use a totally different implementation (React or whatever) to handle this 1% edge case, we might as well just use that for the other 99%.


I'd say two things about this.

1. Opening the native keyboard and plumbing those events through to the WASM runtime sounds pretty easy. It's probably not cause modern software, but conceptually it should be trivial.. right??

2. In terms of 'the boss' wanting to do 'that one weird thing' that there isn't a library/plugin/whatever for in DearImgui land. If dev time for everything else gets faster, than the 10x cost of that small corner case can be absorbed by net win. Now, I'm pretty sus on the claim everything else gets better today, but we can certainly imagine a world where they do, and it's probably not far away


> Opening the native keyboard…

I think this is the roadblock, that there isn’t always a way to pop open the keyboard programmatically. Rather, the mobile keyboard only pops up when there’s a DOM input element detected. So it would need a hidden input layered on top of the ImGui WASM app and mapping coordinates, or would need an HTML input element overlayed on top of every text input.


I mean, yikes. But having a hidden html input you just piggy back off of also doesn't sound that bad


Preach. HTML and CSS are markup languages for creating documents. Using them for GUI applications is wild and obviously a bad idea.


HTML is pretty bad (XUL was better), but (subset) of CSS is probably OK.


HTML isn't even a particularly good markup language for documents, web or otherwise.

> Using them for GUI applications is wild and obviously a bad idea.

I agree it's wild, but bad idea implies there are better options for cross platform applications with the same ease of distribution, and accessibility as the web.


Most major GUI frameworks operate on something very similar to HTML + CSS.


Can you elaborate? I don't see how this is true.


QML and XAML for example, or the layout authoring tools from Motif back in the day.


> We need to build better native UI libraries that just open up a WebGL context and draw shit to that. DearIMGUI can probably already do like 85% of what modern webapps do.

Would be totally into that! But then as soon as you're developing for a worldwide paying audience (or your employer is), one manager realizes the need for ARIA stuff, another for SEO, another for fully-native input controls (textboxes, checkboxes, radios, buttons etc) for most-fluid&familiar UX on every OS, another for embedding externally loaded markup+scripts (whether that's social media sharing widgets, auth providers, Google Maps / OpenStreetMaps etc), for supporting user-generated `<img>`s and `<video>` in all the various formats the browser natively furnishes, and on and on and on =)


That's true. But without the DOM we also loose the browser native accessibility support and text interaction and so on.


I know nothing about how accessibility supports works in the browser, but could they offer a way to use the accessibility API with your custom UI rendered in WebGL/WebGPU?


There doesn't exist a way to infer the individual elements of a rendered frame in canvas because it just encodes the pixels. You can't know which pixels make up a text or button, that information is lost, unlike a DOM tree.


> We need to build better native UI libraries that just open up a WebGL context and draw shit to that.

This is what Flutter does. It works well, but you do lose some nice things that the browser/DOM provides (accessibility, zooming, text sizing/selection, etc). There’s also a noticeable overhead when the app + renderer is initially downloaded).


Couldn't you implement something like HTMX in wasm then and still have locality-of-behavior by specifying the behavior as html attributes?


They might have meant lack of true 64bit pointers ..? IIRC the chrome wasm runtime used tagged pointers. That comes with an access cost of having to mask off the top bits. I always assumed that was the reason for the 32bit specification in v1


I'm firmly in the "use a debugger" camp, but printf is sometimes indispensable when attempting to debug race conditions. By confirming timing invariants hold with printf, you can usually narrow in fairly quickly on the problem. Doing the same in a debugger is much more of a hassle. It's not impossible, certainly, but it's way more of a pain in the ass.


The 'actively misleading' part is a real killer. I've gone down deep, dark rat holes a couple times because the debugger lied to me. I'm 100% in the "use the debugger" camp, but I sure wish they felt a bit more solid. I haven't used one for a long time that wasn't pretty buggy.


lol, agree to disagree here. While the interface to gdb is annoying, there are many gui frontend alternatives.

VS, on the other hand, gets worse with every release. It is intolerably slow and buggy at this point. It used to be a fantastic piece of software, and is now a fantastic pile of shit.


Any recommendations on gdb frontends? Have tried with emacs, but I just really enjoy the point and click stuff, emacs keybinds don't work for me there.


From https://news.ycombinator.com/item?id=35710350 :

> ... py-list, py-up and py-down, py-bt, py-print, and py-locals GDB commands

> [ DDD, pyclewn (vim), trepan3k, Voltron, gdbghidra ]

gdbghidra: https://github.com/Comsecuris/gdbghidra

radare2: https://github.com/radareorg/radare2

voltron: https://github.com/snare/voltron

And from https://news.ycombinator.com/item?id=41943521 :

> pyvmidbg (libVMI + GDB)

But that's archived.

There's a QEMU gdbstub GDB interface.

To print registers with GDB:

  info reg
  info all-registers
  i r a


IMO the GDB frontend in QtCreator is quite nice.


GitHub.com/nakst/gf


Very roughly, hardware watchpoints are memory addresses you ask the processor to issue an "event" for when they're read from, written to, or executed. This event is processed by the kernel, and passed through to the debugger, which breaks execution of the program on the instruction that issued the read/write/exec.

A concrete use case for this is catching memory corruption. If your program corrupts a known piece of memory, just set a hardware watchpoint on that memory address and BOOM, the debugger breaks execution on exactly the line that's responsible for the corruption. It's a fucking godsend sometimes.


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: