It's 2026 and programmers are still fighting over language choices. Lmao
Go is an ideal language for AI-assisted software engineering
511–520 of 586 posts
Re: Go is an ideal language for AI-assisted software engineering
#512I’ve been using Perl 5 with minimal 3rd party libraries. I just feel like it will be supported for a long time, and the language parser and runtime are especially small
Re: Go is an ideal language for AI-assisted software engineering
#513I'd argue Go is not on a "Pareto frontier" and that no matter how you value the various attributes of programming languages, a fair assessment will never select Go. A simple example is: if you highly value language popularity; Go is not most popular. If you highly value a type system that catches errors; Go's type system catches fewer errors than others. Etc. There is no weighted sum of attributes that will select Go…
Uh compile time and linting efficiency, lightweight runtime, gc. There’s no equivalent competitor, it’s the best if u want to just write lots of undifferentiated code.
What is "linting efficiency", never heard of this term before?
Re: Go is an ideal language for AI-assisted software engineering
#514Earlier quoted context omitted.
>fwiw I have a bunch of LLMs writing first Lean code How do you bridge the mental gap? The gap between me writing high quality rust do this steps and something being logically sound seems enormous to me Maybe I'm misunderstanding things but I just can't articulate my ideas in casual lean4. But i can do casual rust spec
As someone experimenting with this, it's definitely very difficult to articulate your ideas using advanced type systems. At the same time, the process of doing it often forces me to seriously think through what I want the code to do, which I've noticed qualitatively improves the end result and my understanding of it. My advice is to be okay with starting small: don't go for full end-to-end correctness or anything lik…
every time the meta-theory is altered enough by a feature set, feature, or sub-feature that consistency/soundness may be affected the change normally gets wired through the fundamental lemma and the ripple towards it and away from it can be a week of token burn, 10s of millions of tokens across multiple agents - one plan had 28 individual steps, each step of which burned through multiple contexts
this is in comparison to me getting an agent to port Ruby to jart's Cosmopolitan project -- a walk in the park relatively speaking in hindsight
Re: Go is an ideal language for AI-assisted software engineering
#515Ada Spark is better. Embedding proofs into the code that prove absence of runtime errors lets the bot know what your actual intent is and gives it an iterable target that is actually correct.
Re: Go is an ideal language for AI-assisted software engineering
#516Earlier quoted context omitted.
How have you found a SCO note, which never did nothing relevant for Java? Here from Oracle, as historically taken from Sun documentation for JDK 1.1. => Many-to-Many Model (Java on Solaris--Native Threads) https://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqk/inde...
I think there's a naming confusion here. You said "M:N threads, aka green threads". However, your linked document clarifies that "green threads" are the M:1 threads that "[do] not exploit multiprocessors" (see the "Green Threads" parenthetical in the first subheading). It is interesting that JDK 1.1 also had an M:N threading model, but that's not what people usually mean by green threads.
Well M:N means green to me, but that got me too, the docs only refer to M:1 as green.
Re: Go is an ideal language for AI-assisted software engineering
#517Earlier quoted context omitted.
The authors make some good points: compile time and test speed matter, platforms matter. But they really dodge the whole “guardrails matter” thing. And guardrails are going to win long term. As for readability, the fact that AI-written Go closely resembles human-written Go is not necessarily a point in Go’s favour.
> "guardrails matter" This thing has been solved in the 70s. Basically, have a powerful type system, and a compiler that beats you into submission when you try to stray from the straight and narrow. Languages like (S/OCa)ML, Haskell and Rust will bring this to you. As a consequence, you fight the compiler, and once it submits, you have a good chance it's going to work. The compiler is also the ultimate refactoring to…
Of those, the weakest points for Haskell and the MLs is the platform and documentation. However, I don’t know if we can call this solved just yet. We may need to invent whole new types of guardrail.
Re: Go is an ideal language for AI-assisted software engineering
#518Earlier quoted context omitted.
Java has so many excellent concurrency containers, plus robust 3rd-party containers like JCTools. It puzzles me why Go communities do not offer such containers.
No thread/goroutine handles for fork/join handling from "outside", and no generics for many formative years that influenced tons of habits, then significantly weaker generics (improving very soon[1]), have all led to most concurrent code to be very "intrusive" - you create bare threads and add bare synchronization primitives (or nearly) by hand inside the threaded code to make it concurrent. `errgroup` is as far as a…
It sounds like Go didn't follow the suggestion of pretty much every CS books on concurrency: favor containers over concurrency primitives.
> while Go forces channels for `select` whether they model your problem nicely or not, and they're very difficult (often impossible) to wrap without changing semantics.
I understand that Go's concurrency model is based on CSP and fork-joins and the primitives like locks, but they are not mutually exclusive with concurrency containers, right? It's okay if the Go team's core philosophy is that channels are the universal abstraction, but I don't get why the community didn't produce 3rd-party containers as robust as JCTools.
Re: Go is an ideal language for AI-assisted software engineering
#519Earlier quoted context omitted.
> Go is bad so "I reach for Rust, Zig..." I hope my every competitor will take your advice to heart, as one of our competitors did when they read that "Go is not a memory safe language", so they wrote a blog about how they are porting to Rust. While our team was moving fast and using those "primitives that should almost never be used" around our long running production code base with success. Some time has passed and…
Perhaps that company failed because it chose to port things to Rust and not because of Rust itself? Or any other number of reasons that survivorship bias might be mistaking.
Lol, so Rust is perfect until you actually try to do something with it.
Re: Go is an ideal language for AI-assisted software engineering
#520Earlier quoted context omitted.
No thread/goroutine handles for fork/join handling from "outside", and no generics for many formative years that influenced tons of habits, then significantly weaker generics (improving very soon[1]), have all led to most concurrent code to be very "intrusive" - you create bare threads and add bare synchronization primitives (or nearly) by hand inside the threaded code to make it concurrent. `errgroup` is as far as a…
It sounds like Go didn't follow the suggestion of pretty much every CS books on concurrency: favor containers over concurrency primitives. > while Go forces channels for `select` whether they model your problem nicely or not, and they're very difficult (often impossible) to wrap without changing semantics. I understand that Go's concurrency model is based on CSP and fork-joins and the primitives like locks, but they…
No, they're not mutually exclusive and tons of go code uses both to implement some kind of semantic. They serve moderately different purposes because their semantics are quite different.
Select, however, is encouraged very widely, and is used very widely, because it's very useful to be able to wait on any of multiple things efficiently. Select is great, you quickly grow to miss it in languages that don't have it. But select only works with channels, and often that means you're essentially forced to use channels where a mutex is much simpler and more natural. It also means tons of APIs are channel-centric because it's kinda the only non-blocking option (atomics exist, but that's a very different kind of non-blocking, and dramatically more error-prone for normal humans to write).
Once you go channel-centric for things like streams or concurrent RX style stuff, it does work, and some libraries do exactly that. But then you run into the historical limitations on generics, which makes for sometimes unnatural code, and channel performance is usually significantly worse than mutexes (it's still very fast, but you don't want to use it for extremely small things). And you are pretty much required to use those channels directly with select by hand because wrapping channels changes some semantics. And the semantics of those libraries are not mutex-y and are different from what most are already used to, because few other languages are channel-centric.
So you end up with high-level channel-oriented concurrency libraries that people only want to use for large expensive operations, thus are only designed for large expensive operations, which means it's not very common over all, and few develop the habit. E.g. there are quite a lot of goroutine-pool-helping libraries for ~seconds of work, but few functional-flavored generic parallelizing ones for opportunistic use.
It's part ecosystem, part language design, and part language history. You can do most of the Java stuff in Go with enough effort, but it just isn't done in practice very much, and it'll look and feel quite different.