Hacker News new | past | comments | ask | show | jobs | submit | Jyaif's comments login

Can't talk about the Jackal without mentioning this mod: https://www.hackster.io/news/tom-granger-s-sony-fx-300-jacka...

It's really cool, my only regret is that they didn't use the CRT. I know, I know, resolution and all that but still...

The Weyland logo on startup is a really nice touch.


That 3.2" TFT likely has 240x320 resolution, which is a lot lower than a typical BW CRT.

You're right, the choice was made for color, not resolution.

How do you debug WASM modules that are running in a host program?

In v8 environments like browser or node, source maps work, so if you inject console.trace you can get printf debugging w/ legible stack traces on each log line, at least that’s my experience with c code compiled with Emscripten.

According to this 2020 blog post from Google, the Chrome debugger appears to have pretty full featured support for interactive debugging, although I’ve never needed to use it. https://developer.chrome.com/blog/wasm-debugging-2020


Unfortunately Go doesn’t support exporting DWARF for WASM atm, so printf is the only option.

https://github.com/golang/go/issues/33503


the one true debugging method: printf debug

Poorly. The tooling is very bad. But to be fair, this is not specific to Go.

Immediately noticed and was annoyed by the cursor thing. What the hell are they smoking over there?

you are supposed to say it's snow leopard

Regarding using WebAssembly as a plugin API, like for zed:

how do plugin developers debug their code? Is there a way for them to do breakpoint debugging for example? What happens if their code crash, do they get a stacktrace?


> You should never write code that's impossible to understand without fancy IDE features

with Rust that ship has sailed


I code Rust just fine without any fancy IDE you should give it a shot. The languages I find hardest to code without fancy IDE features are C and C++ due to their implicit casts. Rust is typically easy to code without IDE features due to its strong type system, lifetimes and few implicit casts.


Rust is one of my favorite new languages, but this is just wrong.

> few implicit casts

Just because it doesn't (often) implicitly convert/pun raw types doesn't mean it has "few implicit casts". Rust has large amounts implicit conversion behavior (e.g. deref coercion, implicit into), and semi-implicit behavior (e.g. even regular explicit ".into()" distances conversion behavior and the target type in code). The affordances offered by these features are significant--I like using them in many cases--but it's not exactly turning over a new leaf re: explicitness.

Without good editor support for e.g. figuring out which "into" implementation is being called by a "return x.into()" statement, working in large and unfamiliar Rust codebases can be just as much of a chore as rawdogging C++ in no-plugins vim.

Like so many Rust features, it's not breaking with specific semantics available in prior languages in its niche (C++); rather, it's providing the same or similar semantics in a much more consciously designed and user focused way.

> lifetimes

How do lifetimes help (or interact with) IDE-less coding friendliness? These seem orthogonal to me.

Lastly, I think Rust macros are the best pro-IDE argument here. Compared to C/C++, the lower effort required (and higher quality of tooling available) to quickly expand or parse Rust macros means that IDE support for macro-heavy code tends to be much better, and much better out of the box without editor customization, in Rust. That's not an endorsement of macro-everything-all-the-time, just an observation re: IDE support.


Have you actually tried coding Rust without IDE support? I have. I code C and Rust professionally with basically only syntax highlighting.

As for how lifetimes help? One of the more annoying parts of coding C is to constantly have to look up who owns a returned pointer. Should it be freed or not?

And I do not find into() to be an issue in practice.


Is this technique still used in modern engines to determine which part of a level to render?


Similar techniques are used, UE5 has Precomputed Visibility Volumes and Cull Distance Volumes, among other render optimizations.

https://dev.epicgames.com/documentation/en-us/unreal-engine/...

https://dev.epicgames.com/documentation/en-us/unreal-engine/...


> curious if anyone has ideas how an LLM provider could moat AI

By knowing a lot about me, like the details of my relationships, my interests, my work. The LLM would then be able to be better function than the other LLMs. OpenAI already made steps in that direction by learning facts about you.

By offering services only possible by integrating with other industries, like restaurants, banks, etc... This take years to do, and other companies will take years to catch up, especially if you setup exclusivity clauses. There's lots of ways to slow down your competitors when you are the first to do something.


It is better to leave this up to the «LLM browser», than the LLM. Both because of privacy and portability.


Forget about forking, just offering a build of Chromium for a single platform and architecture that gets the security updates in time is a lot of work.


Nice work!

Out of curiosity, are there any of these features that couldn't be done with WebGL 2?


Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: