docs/guides: additional resources for WebAssembly

[deadprogram]

This PR adds more to docs/guides with additional resources for WebAssembly.

[aykevl]

Good idea, but I'm not sure about some of the blog posts. If we're going to link to external posts, we should make sure they're at least using current recommendations and not all of them do unfortunately.

[aykevl]

This one still uses -wasm-abi=generic which has been removed a while ago. Otherwise it seems fine.

[deadprogram]

cc @technosophos

[deadprogram]

Removed from this PR, can add to this page once it is updated, I suppose.

[aykevl]

This one contains some outdated information on malloc and free. I'm not sure we should encourage people reading this? (Or perhaps send a message to the blog post writers to update?)

[deadprogram]

Or perhaps send a message to the blog post writers to update?

That for sure! cc @codefromthecrypt

[codefromthecrypt]

the jury is still out on the malloc/free stuff, but coming in soon. We need to see benchmark before after and it is nearly there.

[codefromthecrypt]

basically there are a lot of people using the existing approach (which was reviewed by several) we owe it when doing an update to say what the new is and what it will cost you tetratelabs/wazero#1390

[aykevl]

@codefromthecrypt I'm not sure what you mean? malloc and free has been safe for use since tinygo-org/tinygo#3148 and I doubt we'll ever change that back.
A hand rolled malloc will have a much bigger chance of being subtly wrong.

[codefromthecrypt]

@aykevl Thanks. We we were missing the context

What you said "malloc and free has been safe for use since tinygo-org/tinygo#3148 and I doubt we'll ever change that back." should be in the PR desc as rationale to use the CGO as the only way and remove the others, especially as the benchmarks don't show any perf regression. The same PR can update the site docs to only say one way (CGO malloc/free). @lburgazzoli can you update tetratelabs/wazero#1390 accordingly? Once that's in, I'll we can remove the manual exports from tinymem, leaving it only used for slice helper functions.

[aykevl]

What you said "malloc and free has been safe for use since tinygo-org/tinygo#3148 and I doubt we'll ever change that back." should be in the PR desc as rationale to use the CGO as the only way and remove the others, especially as the benchmarks don't show any perf regression.

@codefromthecrypt I'm not sure I follow. Was this a reply to me, or which PR are you referring to?

[deadprogram]

@lburgazzoli can you update tetratelabs/wazero#1390 accordingly?

I think @codefromthecrypt was asking @lburgazzoli to update tetratelabs/wazero#1390 accordingly. 😸

[aykevl]

I didn't fully look at the new blog post series.
I'm also not sure whether it's worth it to review each and everyone of them. Instead, I think it's more important to provide good primary documentation in the first place, which, to be very honest, we have very little of. So, I guess that's a weak LGTM on this PR from me.

[aykevl]

Some things I noticed:

// readBufferFromMemory returns a buffer from WebAssembly
func readBufferFromMemory(bufferPosition *uint32, length uint32) []byte {
    subjectBuffer := make([]byte, length)
    pointer := uintptr(unsafe.Pointer(bufferPosition))
    for i := 0; i < int(length); i++ {
        s := *(*int32)(unsafe.Pointer(pointer + uintptr(i)))
        subjectBuffer[i] = byte(s)
    }
    return subjectBuffer
}

This is one example where unsafe.Slice would be perfect (although I'm not sure about the uint32 vs byte conversion, or what is supposed to be happening there):

// readBufferFromMemory returns a buffer from WebAssembly
func readBufferFromMemory(bufferPosition *byte, wordLength uint32) []byte {
    length := wordLength * 4
    subjectBuffer := make([]byte, length)
    copy(subjectBuffer, unsafe.Slice(bufferPosition, length))
    return subjectBuffer
}

[deadprogram]

Thanks everyone for the feedback. Now merging.