Sabitlenmiş Tweet
I have made thousands of static visualizations for Go, it's time to try something new:
youtube.com/watch?v=fwHok9…
YouTube
English
Phuong Le
1K posts
Phuong Le
@func25
Software Engineer @VictoriaMetrics, building VictoriaLogs
Katılım Ağustos 2014
122 Takip Edilen8.2K Takipçiler
Enums are good. I wish Go supported "real" enums. But union types are not, at least IMO.
At the very least, I do not want union types in a TypeScript-ish form:
func F(x int | string | []byte | io.Reader) { ... }
This function accepts many unrelated shapes of input.
Inside the function, you must figure out which one you got.
It's never good to be too convenient. It loosens the language in a way that makes APIs harder to reason about.
If Go somehow were to add union types, a more Go-ish version would be:
type ParseResult[T] union {
Ok(T)
Err(error)
}
type Shape union {
Circle(radius float64)
Rect(width, height float64)
}
That is closer to an enum with payloads, or a sum type or tagged union or Rust-style enums. It keeps the set of cases closed and explicit.
Go does not need "any value can be A or B or C" union types. Go would benefit from "this domain value has one of these known variants" sum types.
You cannot pass values like in TypeScript:
f(123)
f("hello")
You need to pass explicit variants instead, assuming Input is a tagged union:
f(Input.Number(123))
f(Input.Text("hello"))
More verbose but safer and stricter.
See more at
github.com/golang/go/issu…
github.com/golang/go/issu…
Sean Roberts@sean_j_roberts
hot take: Go would be the greatest programming language on earth if it had enums and union types. they simplified their way into having to do really weird stuff just to represent reality. you should still probably use it though.
English
Phuong Le retweetledi
"We weren't gambling on a new technology — we were promoting one we'd already been operating in production against our own workload, and that consistently outperformed Loki in our side-by-side testing on the kinds of queries we and our users actually run."
Zerops@zeropsio
The dedicated logger service inside every Zerops project is now using VictoriaLogs. - 100x more log retention - 3x faster queries - VictoriaLogs UI embedded into Zerops - Already rolled out to every existing project Full story below.
English
Phuong Le retweetledi
Something is seriously wrong with how people contribute to open source these days.
People submit AI-generated code they clearly don't understand. When reviewers comment, they feed it back to the AI and submit again. The loop never ends.
Low-effort PR requires extremely high effort to review. That math is never fair.
You think this is how you build a reputation in open source? No, no, and no. You're just burning out maintainers.
---
Use AI to understand the codebase instead. Ask it to explain things. Build your own judgment. It's ok to use AI as a tool for coding, but make sure you filter out any AI slop before submitting.
You gain the skills. You gain the reputation. The project actually benefits.
Is it that hard?
English
A language in which “a lot of correctness around cancellation, task lifetimes, cleanup, error propagation, and backpressure is left to us, the programmer” cannot rationally be said to offer “simple, pragmatic concurrency.”
Demand better. Because better is widely available.
Phuong Le@func25
Go is not bad at concurrency. A more factual take is Go is excellent at making concurrency cheap, explicit, and approachable (and approachable, and approachable), especially for common backend patterns. But Go gives you relatively low-level primitives, a lot of correctness around cancellation, task lifetimes, cleanup, error propagation, and backpressure is left to us, the programmer. So the fair comparison is not "Go vs JVM, who wins?" It is: Go optimizes for simple pragmatic concurrency, the modern JVM ecosystem has stronger tools for structured and resource-safe concurrency. Which one is better depends on how complex the concurrency problem is. This is just a "depends on the problem" discussion.
English
@HSVSphere @JustDeezGuy Because you don't need that level of concurrency abstraction most of the time. context, waitgroup, errgroup, clear ownership patterns cover many common cases well
English
@func25 @JustDeezGuy Sure. Why waste engineering time trying to (and eventually failing to) get cancellation and other primitives working? Languages can do this for you so you can focus on real issues
English
@raghavan_srini Agreed, though most backend systems people build aren't mission-critical at that level. Go ofc can, it just shifts responsibility to developers or to higher-level tooling
English
@func25 But thats so critical in misson critical concurrent systems
English
Go is not bad at concurrency. A more factual take is Go is excellent at making concurrency cheap, explicit, and approachable (and approachable, and approachable), especially for common backend patterns.
But Go gives you relatively low-level primitives, a lot of correctness around cancellation, task lifetimes, cleanup, error propagation, and backpressure is left to us, the programmer.
So the fair comparison is not "Go vs JVM, who wins?" It is: Go optimizes for simple pragmatic concurrency, the modern JVM ecosystem has stronger tools for structured and resource-safe concurrency. Which one is better depends on how complex the concurrency problem is. This is just a "depends on the problem" discussion.
James Ward@JamesWard
Generally developers think of Go as being great for concurrency. Its not. JVM approaches are vastly superior. And even some of the best in the whole industry when you include virtual threads, structured concurrency & Effects.
English
@turbofish_pk I'm waiting right along with you :) It's currently going through an audit but I'm expecting it to be out sometime this month
English
@rahulyadavsep92 @sanskarpan It depends on the editor, but I expect it to be released this month
English
@func25 @sanskarpan Thanks @func25 for a very insightful book.
Can you also give us timeline of when we can expect this? It's been a month since I am waiting for final chapter in my account.
English
English
@func25 @sanskarpan Adding to my previous post, last chapter I can see in my account email: rahulyadavsep92@gmail.com is "Chapter 5 Garbage Collection"
English
Chapter 8 of The Anatomy of Go is ready for review. It goes into concurrency, the Go scheduler, threads, the system monitor thread, goroutine preemption, what happens at startup, how channels work, how the select statement works, and how timers work behind the scenes, a lot and a lot, with visual explanations.
This is the final chapter, it is near the end of the journey.
English
Phuong Le retweetledi
Who's the biggest Victoria-stack bull in my feed that wants to say why they love it?
I'm yolo porting from Prom/Loki etc in a project because I saw some nice numbers in the past and want to try it out but want to hear some people that are excited by it geuinely
English
@mrkaran_ @techsutra @VictoriaMetrics I'm from the VictoriaLogs dev team, let me know if you need any help
English
Yes, in fact that’s the direction I'm working towards.
I’m actively refactoring Logchef to support multiple backends, and I’m currently experimenting with VictoriaLogs (from @VictoriaMetrics) as one of them. DuckDB/Parquet is also something I want to support, especially for small deployments, local-first setups, and single-node use cases.
I wouldn’t promise a timeline yet, but it’s definitely on the roadmap as part of making Logchef - so you get auth/rbac/alerts etc out of box!
English
@mrkaran_ The vector integration link from logchef.app/getting-starte… (at the bottom) gives a 404
English
@func25 fam I bought it but not able to access it. I’ve DMed you the details
English
@0xELL10T @sanskarpan Thanks a lot, will do a full pass and fix all the reported issues
English
@func25 @sanskarpan I love how you go into detail on the assembly generated by different functions
Also there’s a small typo/error on page 82 where you just swapped which side is the go assembly and which is the go code
English
