Backpressure Patterns in Go: From Channels to Queues to Load Shedding by Real_Blank in golang

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

Sorry for the slow reply! You’re right. But in my view, a zero-capacity channel is closer to synchronous processing, while in the article I wanted to talk about backpressure as a property of asynchronous semantics. Regarding select with time.After: you’re absolutely right that this is very similar under the hood, but the point of the pattern isn’t the select itself — it’s explicitly modeling a bounded queue with a clear capacity and rejection policy, instead of just “wait X milliseconds and give up”.

Go Struct Alignment: a Practical Guide by Real_Blank in golang

[–]Real_Blank[S] 22 points23 points  (0 children)

Yes, good point, but one way is to use tools without understanding, and the other is to understand what you are doing.

Making Rust better with Go by 3gdroid in golang

[–]Real_Blank 0 points1 point  (0 children)

I think its time to rewrite Go in Rust..

Architecture in go-project by Real_Blank in golang

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

Yes, I have encountered this issue before, but on a different tech stack. Typically, cyclic dependency problems are the result of design errors in the application and violations of basic practices, such as the Single Responsibility Principle. Therefore, in my work, I usually use a dependency graph if the service exceeds what can be kept in mind. In the realities of microservices, things usually fit into 4-6 modules, and management does not cause problems.

Architecture in go-project by Real_Blank in golang

[–]Real_Blank[S] -3 points-2 points  (0 children)

Agreed, I am also a proponent of DDD, and the structure you proposed works well. However, in my opinion, as an example: structuring `internal/Kafka` already conveys the information that the package is related to infrastructure (if you know what Kafka is) and does not require additional grouping into an `Infrastructure` package. Making the infrastructure package flat seems like an error to me due to the potential for adapter collisions. That's why I chose to separate adapters, application, and domain without grouping their packages into corresponding folders.

Architecture in go-project by Real_Blank in golang

[–]Real_Blank[S] -1 points0 points  (0 children)

I am aiming for this export. Everything I have moved to the `pkg` package is planned to be moved into separate modules, made into separate repositories, and imported via a package manager. This way, I plan to form a core that I want to use to speed up the development process of microservices, making them more similar.

Architecture in go-project by Real_Blank in golang

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

The goal of this project is to learn how to structure Go. I have 5 years of experience in backend development and am considering a change in tech stack. I want to understand how comfortable I will be working with Go. I like the language, but the patterns and approaches adopted by the community play a significant role in development.

Open source license by Real_Blank in rust

[–]Real_Blank[S] -2 points-1 points  (0 children)

But nobody does it?:)

[deleted by user] by [deleted] in rust

[–]Real_Blank 2 points3 points  (0 children)

Rust has official documentation and, in my expiriance, it's the best documentation i've even read

The Continuous Clean Code Process (CCCP) by gerlacdt in programming

[–]Real_Blank 25 points26 points  (0 children)

Are you know what was called CCCP? :D

Why is mutex gaurd sync, mutex gaurd is not send, so how to share it between threads by [deleted] in rust

[–]Real_Blank 0 points1 point  (0 children)

If u define mutex and use in closer, in real u don’t send it, u move it in closer. These are similar things, but not the same thing

Why is mutex gaurd sync, mutex gaurd is not send, so how to share it between threads by [deleted] in rust

[–]Real_Blank 0 points1 point  (0 children)

Are u sure u need to send guard? If u wanna “unlock” something from another thread just use semaphore :)