Why use a lower version of Golang

[helbing]

Your question

Why use go1.14? Can I upgrade it to the latest version go1.19?

[seeflood]

We can't upgrade because Layotto has a dependency on MOSN, and MOSN use go 1.14 :(
MOSN can't upgrade because of some incompatible issues which I don't know. @nejisama Do you know why?

[seeflood]

MOSN can't upgrade because of some incompatible issues

Some MOSN production users use a modified version of go runtime, and they don't want to upgrade for now

[helbing]

MOSN can't upgrade because of some incompatible issues

Some MOSN production users use a modified version of go runtime, and they don't want to upgrade for now

It seems bad. It's not good for an open-source project that can't use the new features of Golang. So, does Layotto have any plans to reduce opaque dependencies?

[wenxuwan]

MOSN can't upgrade because of some incompatible issues

Some MOSN production users use a modified version of go runtime, and they don't want to upgrade for now

It seems bad. It's not good for an open-source project that can't use the new features of Golang. So, does Layotto have any plans to reduce opaque dependencies?

Why upgrade the golang version? Do you need any new features?

[helbing]

MOSN can't upgrade because of some incompatible issues

Some MOSN production users use a modified version of go runtime, and they don't want to upgrade for now

It seems bad. It's not good for an open-source project that can't use the new features of Golang. So, does Layotto have any plans to reduce opaque dependencies?

Why upgrade the golang version? Do you need any new features?

Not for now. I want to contribute testing tools to Layotto to add more test cases for reliability. Maybe I will use Generics, Fuzzing, or not. They are unnecessary. On the other hand, I may use a package with new features of Golang that make me have to use this package with a low version. It may have bugs that fix in the high one. And I can't use the new features of this package too. It's not friendly for coding that has to pay attention to too many things. And this is why Dapr, Kubernetes, and other open-source projects always upgrade to the latest go version.

[helbing]

I see a To-do, Layotto without MOSN, in the project Deployment on multiple clouds. What it will do? How about it priority? @seeflood @wenxuwan

[seeflood]

I see a To-do, Layotto without MOSN, in the project Deployment on multiple clouds. What it will do? How about it priority? @seeflood @wenxuwan

We found that legacy systems often have their own rpc framework and don't want to migrate to mosn. They just want to use Layotto apis without RPC feature. This "todo" aims to solve this problem.
This means we have to support two modes:
Layotto-on-mosn (default mode)
Layotto-without-mosn

It's just an idea and still up for discussion :)

[seeflood]

MOSN can't upgrade because of some incompatible issues

Some MOSN production users use a modified version of go runtime, and they don't want to upgrade for now

It seems bad. It's not good for an open-source project that can't use the new features of Golang. So, does Layotto have any plans to reduce opaque dependencies?

Why upgrade the golang version? Do you need any new features?

Not for now. I want to contribute testing tools to Layotto to add more test cases for reliability. Maybe I will use Generics, Fuzzing, or not. They are unnecessary. On the other hand, I may use a package with new features of Golang that make me have to use this package with a low version. It may have bugs that fix in the high one. And I can't use the new features of this package too. It's not friendly for coding that has to pay attention to too many things. And this is why Dapr, Kubernetes, and other open-source projects always upgrade to the latest go version.

@helbing I agree that using a low version golang is bad 😢 But it takes time to push production users to upgrade.
Is there a short-term, compromise solution? How about we put the tools in a separate go module or a separate repository, and use a higher version of golang in it?
For example, I put the code generator in a seperate repo https://github.com/seeflood/protoc-gen-p6 and use golang 1.16 in it. I'll move it to the layotto organization when I'm sure the license is fine.

[helbing]

MOSN can't upgrade because of some incompatible issues

Some MOSN production users use a modified version of go runtime, and they don't want to upgrade for now

It seems bad. It's not good for an open-source project that can't use the new features of Golang. So, does Layotto have any plans to reduce opaque dependencies?

Why upgrade the golang version? Do you need any new features?

Not for now. I want to contribute testing tools to Layotto to add more test cases for reliability. Maybe I will use Generics, Fuzzing, or not. They are unnecessary. On the other hand, I may use a package with new features of Golang that make me have to use this package with a low version. It may have bugs that fix in the high one. And I can't use the new features of this package too. It's not friendly for coding that has to pay attention to too many things. And this is why Dapr, Kubernetes, and other open-source projects always upgrade to the latest go version.

@helbing I agree that using a low version golang is bad 😢 But it takes time to push production users to upgrade. Is there a short-term, compromise solution? How about we put the tools in a separate go module or a separate repository, and use a higher version of golang in it? For example, I put the code generator in a seperate repo https://github.com/seeflood/protoc-gen-p6 and use golang 1.16 in it. I'll move it to the layotto organization when I'm sure the license is fine.

Yeah, it’s a big thing to push production users to upgrade. Well, I will develop the testing tools first through the method you provide. 😁

[seeflood]

@helbing Thanks!
By the way, I'm curious about the testing tools you mentioned. Do you mean to add more unit test cases, or write a standalone tool? Could u briefly introduce your design?

[helbing]

@helbing Thanks! By the way, I'm curious about the testing tools you mentioned. Do you mean to add more unit test cases, or write a standalone tool? Could u briefly introduce your design?

It's for integration testing. Is someone working on this now? I write a package to automatically up & down the environment through docker-compose when testing. But it still has some problems. #796

[seeflood]

@helbing We have a very simple integration test script and you can run it with make integrate-runtime.
It's too simple and @bxiiiiii submitted a PR to improve it, see #795 and #415
Can we merge your tool and his improvement into one?

[helbing]

@seeflood Of course, but please give me a few days to improve the package. It still has some problems.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue or help wanted) or other activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue or help wanted. Thank you for your contributions.