Replies: 4 comments
-
Considering scenarios similar to injection into gin/serverless functions, I believe we need the capability to inject neva nodes. |
Beta Was this translation helpful? Give feedback.
-
@Mr-Ao-Dragon I didn't work with both but sounds interesting. If you can provide with more details (what exactly should be supported in that order) - would be good 👍 |
Beta Was this translation helpful? Give feedback.
-
as serverless SaaS / Gin, context scope only have in 1 func, so we need new build target ( go package ) import "some-neva-program/build/package"
func main()() {
alicloud.Serverless.Func.Launch(package.EntryPoint)
} |
Beta Was this translation helpful? Give feedback.
-
This is exactly how NATS Jetstream works. You orchestrate the streams ( not go code ) , and under each stream you can write code in any language that binds to NATS Jetstream. It would give NEVA a massive adoption kick because NATS is many popular, and used for projects demanding high quality. |
Beta Was this translation helpful? Give feedback.
-
After conversation with Nevo David (Postiz/Gitroom creator), I've realized that something needs to be done, in order to promote Nevalang.
We need to do what wasp-lang guys are doing - solve existing problem in existing eco-system. Wasp allows to scaffold a full-stack app in JS (node/react), avoid boilerplate and reduce maintenance by delegating it to a third-party tool. This way project gets dependency on wasp. I was thinking what we could do in a similar way, but for Go ecosystem?
An idea came after conversation with @jacob-ebey - Nevalang could be a "glue" language for different parts of the Go application. You orchestrate Go code on a high-level and control parallelism there, in Neva, while having lower-level stuff in Go. This is also one possible way for gradual adoption.
Language Agnostic?
Jacob's idea was a bit broader - could Nevalang be language-agnostic glue? I believe this is also close to what wasp guys are doing. Perhaps they not glue but rather a "kick-starter" thing but anyways. I think we should focus on Go. The only way to be heterogenous is to implement different backends. I like that idea a lot and compiler is modular enough to have more backends, but that should not be our focus, I think.
Related to Go-interop and Promotion
Beta Was this translation helpful? Give feedback.
All reactions