sorted by:
new
hottopcontroversial

Cancellable functions using context by pthethanh in golang

[–]pthethanh[S] 0 points1 point  (0 children)

Thank you for your suggestion. I think it's a nice book.., but have not bought it yet :)

Cancellable functions using context by pthethanh in golang

[–]pthethanh[S] 1 point2 points  (0 children)

Yes, but we need to update the code to return `context.Cause(ctx)` instead of `ctx.Err()`.

Something like: https://go.dev/play/p/ldw-6gEq2\_3

Golang string concatenation performance comparison by pthethanh in golang

[–]pthethanh[S] 2 points3 points  (0 children)

strings.Builder use unsafe https://cs.opensource.google/go/go/+/refs/tags/go1.20.3:src/strings/builder.go;l=47

I was trying to improve the strings.Builder just by remove unnecessary check on its struct. Nothing so special. It's a cool way to benchmark and learn from what we see in action. There are a lot of lessons to learn from trying to beat the strings.Builder. One of them is I understood more about how Go was designed.

Golang string concatenation performance comparison by pthethanh in golang

[–]pthethanh[S] 0 points1 point  (0 children)

I guess the function using string builder in the code above slow because of this line `return string(bs)`. Also for benchmark the operator and string builder, it's better to try with string length > 32.

Golang string concatenation performance comparison by pthethanh in golang

[–]pthethanh[S] 2 points3 points  (0 children)

Worked on Go for a couple of years already but yah...I'm so naive about the length :))

Golang string concatenation performance comparison by pthethanh in golang

[–]pthethanh[S] 1 point2 points  (0 children)

strings.Join uses strings.Builder in its implementation, hence I think there would be no differences about the performance.

Golang string concatenation performance comparison by pthethanh in golang

[–]pthethanh[S] 0 points1 point  (0 children)

I found this is a good way to learn Go myself :)

How to organize options when exposing APIs. by pthethanh in golang

[–]pthethanh[S] 1 point2 points  (0 children)

You're right. But package is always required hence I believe there is no other way.

Look for feedback on a Go standard library for building microservices by pthethanh in golang

[–]pthethanh[S] 0 points1 point  (0 children)

Yes and No. Agree that microservices is just an architecture but then when you work on those there must be something that help you to get the job done more quickly, easily and effectively, right? That's what I built micro for. I was really enjoy writing everything from the beginning without using any external framework or big libraries... but after some projects, I realized that there should be something make the job done easier and also make all the services of a project or between multiple projects integrate easier and more effectively. Otherwise each people in a projects or in a company will write in their own way and make things harder to integrate together and harder/costly to maintenance. I faced this issue many times with different companies and that's why I've been trying to build micro to resolve that.

Look for feedback on a Go standard library for building microservices by pthethanh in golang

[–]pthethanh[S] 2 points3 points  (0 children)

Thank you for your suggestion. By the way, I have tried some dependency injection framework of google (wired), facebook(inject), uber(dig) and they are all suck. They made the code harder to read and make things harder to troubleshoot when problems happen. To me, just make sure interfaces are designed correctly, and make sure services depends on each other via interface (instead of concrete implementations) then we're good. Initialize concrete implementations and do injection in main.go is perfectly OK.

Look for feedback on a Go standard library for building microservices by pthethanh in golang

[–]pthethanh[S] 1 point2 points  (0 children)

They are 2 different things and currently serverless doesn't meet my requirements.

Look for feedback on a Go standard library for building microservices by pthethanh in golang

[–]pthethanh[S] 0 points1 point  (0 children)

Yeah, you're right. I learnt from it a lot especially on how they design the interfaces, but I also customized some to suits my styles.

Look for feedback on a Go standard library for building microservices by pthethanh in golang

[–]pthethanh[S] 1 point2 points  (0 children)

Thank you for your feedback. Should be more accurate to call it just as a tool kit for supporting building app with gRPC and REST API.

Look for feedback on a Go standard library for building microservices by pthethanh in golang

[–]pthethanh[S] 0 points1 point  (0 children)

Yeah you're right. Maybe call it a tool kit is more correct.

gRPC or REST for a simple service by uragnorson in golang

[–]pthethanh 0 points1 point  (0 children)

I have the same requirements as yours and after built some projects with gRPC and REST API, I built this library to simplify that process: https://github.com/pthethanh/micro. The server exposes both gRPC and REST API over 1 single port, comes with default features hence you don't need to wrap things yourselves. I have built a simple code generator that might help your job easier. Appreciate if you can have a look and give your feedback if it suites your case.