It’s not their code, and it’s not for them to understand. The endgame here is that code as we know it today is the “ASM” of tomorrow. The programming language of tomorrow is natural human-spoken language used carefully and methodically to articulate what the agent should build. At least this is the world we appear to be heading toward… quickly.
But the endgame is not here and will likely never be, because unlike ASM, LLMs are not deterministic. So what happens when you need to find the bug in the 100,000k LoC you generated in a few weeks that you've never read, and the agent can't help you ? And it happens a lot. I am not doing this myself so I can't comment, but I've heard many vibe coders commenting that a lot of the commits they do is about fixing the slop they outputted a week prior.
Personally, I keep trying OpenCode + Opus 4.6 and I don't find it that good. I mean it does an OK job, but the code is definitely less quality and at the moment I care too much about my codebase to let it grow into slop.
There is a large and growing segment of executives in the software world that is pushing this model hard, like betting their career on it. To them the “dark factory” is an inevitability. As a consequence, not only are developers choosing this path, but the companies they work for are in varying degrees selecting this path for them.
Most, if not all of them, are shooting themselves in the foot. I've been saying this for a long time. The only thing LLMs actually are useful for is automating labor and reducing the amount a worker can demand for their work. Don't fall for this trap.
No, I'm not. Through university (and even before) I have access to their full suite. I have tried to use PyCharm, GoLand and Idea.
Idea was useful for Java but felt quite slow and even with vim bindings was a pain to navigate. Learning the shortcuts helped but it never got quite as fast as helix/vim for general editing (especially as my work usually is a polyglot). It might be the best for Java (compared to eclipse or bluej) but that does not mean it fits my workflow/way of work.
PyCharm/GoLand both are "nice" but it did not feel better/more efficient than pylance/pyright)/gopls + vscode/helix. The only I still occasionally use is DataStorm as it is quite a nice SQLite/PostgreSQL client.
No, not just like. You're downplaying significant differences between the two that do in fact matter. So much so in fact, that you're just wrong. Stop spreading misinformation.
Go use cases overlap the most with Java. I think the reputation you mentioned comes from Google using a lot of C++ for high-level things others would likely do in Java, so they see Go as a replacement for C++ in some areas. (assuming you meant C++ not C)
It's replete with oddities and limitations that signal "ah, this is because systems language."
Go’s type system, for example, is very much a systems-language artifact. The designers chose structural typing because it was lighter weight, but provided enough type safety to get by. It sucks though for enterprise app development where your team (and your tooling) are desperate for nominal typing clarity and determinism.
The error handling is like a systems language for sure, I'll agree on that.
But where do Go's docs or founders call it a C replacement? gf000 asked where this is mentioned besides marketing, but I don't see it in the marketing either.
Thanks. I'm not surprised they called it a C++ competitor back then. All those systems-style features do make it awkward now that it's targeting the Java-like use cases. No pointer arithmetic, but pointers yeah, and it's not very clear what you're supposed to pass by value vs by ref. You can do things like a DBMS in Go that count as systems programming, but for sure it's not a competitor with C.
Go happened to be attractive for web backends too because it had good greenthreading before Java etc did, and better performance than JS, so it makes sense that they changed the marketing.
Go's runtime is thin: goroutines, a GC specialized for concurrency, networking, and little else. Java, by contrast, assumes a JVM plus massive stdlibs to handle everything from enterprise apps to big-data, making its platform genuinely "fat" and layered. Other Java-tier languages, C# included, follow the same model.
I agree Go's runtime is as thin as runtimes get. But having a runtime at all disqualifies it from being a C replacement. Rust is trying to replace C, Go is trying to replace Java and some of C++.
> We now know that we prefer composition over inheritance
When people say "composition over inheritance" in Java discussions, they usually mean the trivial modeling rule: prefer has-a over is-a.
But that’s not what composition is really about.
The deeper idea is interface composition -- building types by composing multiple behavioral contracts behind a single cohesive surface.
Java provides inheritance and interfaces, but it doesn’t provide first-class delegation or traits. So most developers never really practice interface composition. They either subclass, or they wire objects together and expose the wiring.
The slogan survived. The concept mostly didn’t.
The manifold project, for example, experiments with language-level delegation to make interface composition practical with Java.
> Java provides inheritance and interfaces, but it doesn’t provide first-class delegation or traits.
I'm not sure I am missing first class delegation much (not a lot of UI projects in Java these days).
But interfaces with default (and static) method implementations are actually quite usable as traits / mixins. Since Java 8 IIRC.
You can also pass around functions / lambdas (coincidentally also since Java 8) to compose functionality together. A bit harder to follow and/or understand, but another perfectly legitimate and very powerful tool nevertheless.
How does a type class help with composition? They do help with the expression problem (adding support for an "interface" after definition), and via parametric polymorphism they might give you a bit with regards to composing two traits.. but you do also have generics in Java, even if not as good as type classes.
So anyways, I don't see as big of a change here. But there was a Brian Goetz mail/presentation somewhere where he talked about adding "basically type classes" to Java? But unfortunately I couldn't find it for you now.
Kotlin's "delegation" feature isn't true delegation, it's just call forwarding, which is better than nothing, but it falls down pretty quickly as an alternative to implementation inheritance.
The manifold project provides true delegation[1] for Java.
Yes, the empty infix operator is often called the "juxt" operator, which is an apt term here.
However, I use the term "binding expressions" intentionally because there’s more going on than ordinary juxtaposition. In a normal juxt expression such as:
a b c
the evaluation order is static and independent of the type system:
(a b) c
With binding expressions the precedence is type-directed, so the type system determines which grouping is valid:
(a b) c
a (b c)
Additionally, the operation itself can be provided by either operand. For a given expression a b, the compiler may resolve it as:
a.prefixBind(b)
b.postfixBind(a)
For example:
10kg
Here kg is a MassUnit, and MassUnit defines postfixBind(Number) returning Mass, so given there is no left-to-right binding, the expression resolves right-to-left as:
kg.postfixBind(10)
So while juxtaposition is the syntactic surface, the semantics are type-directed binding.
> California's new speed camera pilot (AB 645) explicitly solves for this... like parking tickets
That makes the Florida judge's framing of red light cameras as a revenue generating scheme even more applicable. More than that, it ambiguates the crime.
> The drawback is that building an AST now requires a symbol table
Well, yes and no. During AST building a binding expression resolves as an untyped polyadic expression. Only later during the compiler's type attribution phase does a binding expression's structure resolve based on the operand types.
var plumber = contacts.select(contactId)
var date = inputForm.getDateTime()
var building = findLocation(warehouse)
Schedule plumber on date at building
But, honestly, I can't say I personally use it that way ;)
reply