@_naisstep @_devdeep No. All the functions in Go are synchronous from caller the point of view. See internals-for-interns.com/posts/go-netpo… for technical details.
English
Aliaksandr Valialkin
2.9K posts
Aliaksandr Valialkin retweetledi
I love LLMs, I hate hype geohot.github.io//blog/jekyll/u…
English
1. Multiple lists != 100 lists.
2. If the disk read bandwidth it the bottleneck, then store compressed data on disk and unpack it during reading. This is a common technique used in databases optimized for storing and querying big amounts of data, such as VictoriaMetrics / VictoriaLogs.
English
I'd ask this question slightly differently: are there useful and maintainable open-source projects written by AI with minimal human guidance (aka vibe-coded)?
Dillon Mulroy@dillon_mulroy
what are the best open source repos (in terms of quality) that have been written exclusively, or almost exclusively, by ai (bun excluded)
English
Agreed that the inline comment in the code is the best source of additional context for non-trivial or questionable code. The commit message is still a good source of additional context for the particular change in the code - it lives close enough to the code, and it doesn't need online access to the main repository.
English
@valyala In a non-oss org (and even for many oss orgs) there’s lots of text about what to do, how to do it, and why do it that way. Commit messages are one of the places where this information lives, and I’d argue it’s not the best place for it. I’d rather make a comment if need be
English
I feel the same. Histrically software engineers weren't good in writing good commit titles and descriptions. So typical commit titles were "WIP", "fix", "refactor", "chore", etc. Now I see detailed commit titles and very long commit messages with many points, which describe all the changes made by the commit. The problem is that these new titles and messages are mostly useless (and even harmful) because of the reasons outlined by Kenton below.
Make an effort and write good concise commit title and description by hand. If you cannot do this, then it is better to use "WIP" title instead of AI-generated misleading slop.
Kenton Varda@KentonVarda
I just declared a moratorium against AI-written change descriptions (e.g. PR and commit messages, also issues/tickets) from my team. AI was writing change descriptions that were worse than useless to me as I tried to review PRs: outlining details of the code that could easily be seen by looking at the code, but omitting the higher-level framing needed to understand broadly what the code is doing. I think people like having AI write these things because the output looks structured and thorough, which makes it feel professional in a way. But this isn't actually valuable. Concise, high-level descriptions are better for everyone. If I need to use my own AI to interpret what your AI wrote then something is wrong. Let AI write code, sure, but for the description, I'd rather see your prompt than your output. We could maybe have extended agents.md with guidelines on writing descriptions, but this seemed a bit pointless since a good, concise change description only takes a few minutes to write -- not a significant time savings to delegate to AI. At least, it doesn't take long if you understand the code -- and if you don't understand the code, then I'm definitely not merging it.
English
If your agents generate commit messages, which describe the contents of the commits, this is not what reviewers want to see. This is useless "capitain obvious" stuff. The commit message must contain higher-level overview of the commit - why it is needed and how does it resolve the given task / issue.
English
@valyala I feel like I’m living in an alternate universe. My agents produce concise, informative, commit messages and PR descriptions. They are much better than those produced by humans.
English
@GolerGkA Who reviews those 500 commits per day? Or you are just playing a slot machine?
English
@okwilkins I tried grok.com - it feels identical to the built-in Grok at X.
English
Not sure if it’s comparable to the “real” Grok chat experience on grok.com.
Would also say that Grok these past few months got super upgraded. Unlike Perplexity now, it uses ~50-70 sources, searched in parallel, for an answer now. The model capabilities of the model allows it to fully comprehend the relevant ones.
It’s largely replaced me manually searching for things when I have questions now.
English
I didn't notice any progress in LLM-based search for the last 3 years. I started using Perplexity 3 years ago, and was impressed by its' web search abilities comparing to Google. As any LLM system at that time, sometimes it could return bullshit. 3 years passed since then, ChatGPT and Google released their versions of LLM-based web search. But they have the same level of response quality and the same issues with hallucinated responses as Perplexity had 3 years ago and has now. Where is the progress in LLM-based web search? I'd expect significant progress according to the marketing claims about significant advances of LLM-based code generation during the last years.
English
Good commit titles and descriptions help investigating commit history. For example, if I need to understand why the particular code is written in that way, I run `git log -p ...` and investigate the related commits (including their titles and descriptions). Bad commit titles and description may slow down the investigation significantly.
English
@valyala Well, commit message or PR bodies do not matter that much anyway. What matters is « X made all these changes at that time ».
Important things about code should be in the code, not in a foreign metadata
English
@chrisczynski You can freely amend commit messages until the local commits are pushed to the upstream git repository. See stackoverflow.com/a/1186549 .
I frequently change the local commit title and description with `git commit --amend` before pushing it to the upstream repo.
English
@valyala It always annoyed me that you can't amend git commit messages without breaking the chain. This really needs to be decoupled.
English
@okwilkins Contrary, I noticed a regression in the Grok explanations under tweets: previously it was reasoning much more and was providing interesting insights sometimes. Now it just rephrases the original tweet, and that's it :(
English
@okwilkins I try Grok from time to time for the last year, but don't see significant progress with the quality of answers it provides.
English
@theharshpat This commit open sourced VictoriaMetrics, which was in development for a year before that commit - valyala.medium.com/open-sourcing-…
English
@valyala If they were good descriptions/commit messages it would be ok~ish. Usually I refer to this as if they were written by "Capt'n Obvious" they don't say why a given change was done, they make a textual equivalent to the diff (best case).
English