They are quietly trying to become the chatbot that everyone uses to look things up. That strikes me as an intelligent move - not everything has to be done by an expensive frontier model.
306 karma · joined June 5, 2015
They are quietly trying to become the chatbot that everyone uses to look things up. That strikes me as an intelligent move - not everything has to be done by an expensive frontier model.
Post both versions
And it still isn't natural language, where you can paraphrase, use synonyms etc. Good job for an LLM
Now, code by Gen AI is straightforward in comparison. Coding is not writing poetry, even if the lines also don't reach the right margin
It's a lovely metaphor for the soulful business of doing something really well, even if there is no 'market' for that kind of quality
So (again) we are just sharing anecdata
There aren't enough programmers to justify the valuations and capex
Rust projects can really go bananas on dependencies, partly because it's so easy to include them
The article is about it encroaching in the domain of human communications. Mass adoption is the only way to justify the incredible financial promises.
(I know, I have to declare Cargo bankruptcy every few weeks and do a full clean & rebuild)
Context poisoning is not a uniquely LLM problem
One cool thing about standalone services which needs to be factored in is that they can be spun up and debugged very easily. But for deployment, we pay for all the network latency/marshaling overhead, and coordination complexity.
So, best of both worlds? As for polyglot, there does have to be a shared platform (C ABI, JVM, etc). (Go doesn't play so nicely with other languages due to goroutine stack allocation.)
Consider this classic: https://stackoverflow.com/questions/12122159/how-to-do-a-htt...
In short, it still feels like a leaky abstraction: marvelous to look at working code, but errors (both compile and run-time) expose the underlying machinery underneath the syntactical sugar.
This is probably heresy, but as a former Rust dev I'm enjoying web-services in Go more these days.
(It is possible that I have never experienced a truly beautiful desktop, but my eyes are no longer particularly precise enough to operate at modern pixel densities)
The newtype pattern in Go is easier to use, but isn't strict enough - your wrapped string can still appear directly in a string concatenation without a cast. Any wrapped integer can still be used to index a slice! Considering how careful the language is with mixed arithmetic (can't add uint8 to uint16 without casting) this feels like an oversight.