bud VS purego

Yeah. It seems like Bud is the best option I have to get what I want: https://github.com/livebud/bud/

Hit me up if you have a longer time horizon and want to give https://github.com/livebud/bud a shot!

Awesome!

This would be such a game-changer for server-side rendering Javascript in Go with V8.

I'd love to integrate this into Bud[1].

[1] https://github.com/livebud/bud

I've also been seeing updates on this project, which is kind of preferring Svelte https://github.com/livebud/bud

https://github.com/livebud/bud - similar idea, but uses Svelte (a JS framework) to do the front end stuff. It’s smart enough to render the JS stuff on the server when possible, so you end up with the best of both worlds.

https://github.com/livebud/bud this framework is achieving SSR in go. Not Vue specifically last I saw, but maybe you can draw inspiration from what they did https://www.reddit.com/r/golang/comments/uoxocj/bud_the_fullstack_web_framework_for_go_developers/i8ke92h/?utm_source=reddit&utm_medium=web2x&context=3

See https://github.com/livebud/bud to learn more.

Just to clarify: Fymo is taking the same approach as Bud. See: https://github.com/livebud/bud/discussions/248 for details 🙂

An open-source GoLang project also took the same approach, livebud/bud.

I know how to create APIs. I actually don't wanna do an API link with the front end. You can check a framework built in GoLang, livebud/bud in Github. Seeking something like that, 'cause the project is still being developed.

Thank you author for your kind words about my Go SQLite driver.

That said, purego solves a build infrastructure issue, not perfomance issue. You're still using the same underlying mechanisms to call into C, and the same performance is expected to be the same. I'm not the one saying this, here's it from the authors: https://github.com/ebitengine/purego/issues/202

wazero uses a different mechanism, the one used to call Go assembly, but adds its own overhead (trampolines, adapting calling conventions, and the inherent Wasm sandbox overhead, e.g. the guest can't read the host's memory, there's bounds checks, etc).

Also “Cgo is fast” and “Cgo is slow” is not the correct framing; rather it depends, for various reasons:

- Cgo is a moving target (it mostly improves with time, but can regress)

- it's different to just call C from Go, or then callback Go from C

- there's not just call overhead to consider, but also scheduler overhead which is much harder to measure consistently

Let's consider how to use it from Golang. We could use cgo, of course, but this time I employed a library called purego.

https://ebitengine.org/en/documents/install.html

For anything other than windows:

> Installing a C compiler

> A C compiler is required as Ebitengine uses not only Go but also C.

I mean, even on platforms without cgo, it's it working magically?

No; it's using https://github.com/ebitengine/purego, which is:

> A library for calling C functions from Go without Cgo.

Like... I mean.... okaaaay, it's not cgo, but it's basically cgo? ...but it's no cgo so you can say 'no cgo' on your banner page?

Seems kind of like... this is maybe not the right hammer for gamedev.

The other big thing we're working towards is making DarwinKit not use CGO at all! Using purego, we can call into Apple frameworks without involving CGO. This will improve build time, make smaller binaries, and allow DarwinKit to be used in programs that need to avoid CGO for whatever reason.

Click here to view the commit: https://github.com/ebitengine/purego/commit/1a4ea678b5a7598275a28e787179da1b7a058b11

Click here to view the commit: https://github.com/ebitengine/purego/commit/1a4ea678b5a7598275a28e787179da1b7a058b11

Maybe interesting for you: https://github.com/ebitengine/purego