If ecosystem compatibility can be handled well, this seems perfectly viable.
Go is an ideal language for AI-assisted software engineering
461–470 of 586 posts
Re: Go is an ideal language for AI-assisted software engineering
#462Earlier quoted context omitted.
Good point. It's sometimes challenging to get a Rust program to compile... but if you do, it's probably going to work.
And by that point a program written in go has been deployed and making money for months. These are two wildly different languages, people should stop comparing them as if they're targetting the same niche. Checks and protections that rust has aren't necessary in most cases, but increase development and maintenance time.
Do you have some evidence of that? I use both daily and my experience has been the opposite, if anything. Once I was as proficient at Rust as I was at Go, the "increased development and maintenance time" disappeared completely.
Re: Go is an ideal language for AI-assisted software engineering
#463Earlier quoted context omitted.
Java already had M:N threads in the early days, aka green threads, because the JVM and Java specifications did not assert what kind of threading was to be provided. Thus most JVM implementations had a mix of red (1:1:) and green (M:N) threads, eventually only red threads were kept in the surviving implementations. With Project Loom now both models are officially supported and part of the specification.
Yeah I've heard of the Java 1-2 greenthreads, but supposedly those were M:1, ie you could only run them on one core. At least this SCO release note linked from Wikipedia says that: https://www.sco.com/developers/java/j2sdk122-001/ReleaseNote... And the pros are more about compatibility than performance
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...
Re: Go is an ideal language for AI-assisted software engineering
#464It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making. What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go. Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squint…
Fair criticism, it's my main gripe with Go as well - it's not strict enough when it comes to e.g. nil, enums, and type safety. Annotations are supported but they're just strings. Projects require additional tooling / linters to check for things like unchecked errors and many more "gotchas" that I think could (should?) be part of the compiler or standard tools. Trivial example, Go's compiler will error when you have a…
How about Swift and Erlang? Why are these always left out of comparisons?
Re: Go is an ideal language for AI-assisted software engineering
#465Earlier quoted context omitted.
It's not even a qualitative statement about Kubernetes.
Kubernetes doesn't solve any technical problem, so the language it's written in is irrelevant.
I have a bunch of volumes that I'd like to get automatically attached and mounted to nodes on which their respective workload runs (which are automatically scheduled) who automatically fetch and mount their config files and secrets from a HA DB on demand. I also need some internal loadbalancing and integrations with something like certbot for all of my web workloads. Id also like to make sure that I get metrics and logs from every workload in some form.
Thats basically it for starters, what non-technical solution do you propose?
Re: Go is an ideal language for AI-assisted software engineering
#466Earlier quoted context omitted.
Yeah I've heard of the Java 1-2 greenthreads, but supposedly those were M:1, ie you could only run them on one core. At least this SCO release note linked from Wikipedia says that: https://www.sco.com/developers/java/j2sdk122-001/ReleaseNote... And the pros are more about compatibility than performance
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.
Re: Go is an ideal language for AI-assisted software engineering
#467It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making. What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go. Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squint…
i am using nilaway from fb it's great for those
It's from uber, I believe.
Re: Go is an ideal language for AI-assisted software engineering
#468It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making. What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go. Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squint…
Fair criticism, it's my main gripe with Go as well - it's not strict enough when it comes to e.g. nil, enums, and type safety. Annotations are supported but they're just strings. Projects require additional tooling / linters to check for things like unchecked errors and many more "gotchas" that I think could (should?) be part of the compiler or standard tools. Trivial example, Go's compiler will error when you have a…
i never run into these issues in >100k loc of productionized llm generated elixir (nil safety, type issues). i wonder, is there something architecturally in go that makes this a particular problem?
Re: Go is an ideal language for AI-assisted software engineering
#469Earlier 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.
> As for readability, the fact that AI-written Go closely resembles human-written Go is not necessarily a point in Go’s favour. There's just not many ways of writing Go. It's a very dull language. It was designed to be dull and easily understandable.
but there are a whole lot of ways you can mess up a dull language, like shitty variable names, bad code organization, etc.
if an llm has learned dumb things from dumb users it could disproportionately cause provlems versus other languages, just by being "in a sloppy mood" when writing go.
Re: Go is an ideal language for AI-assisted software engineering
#470Earlier quoted context omitted.
It's not even a qualitative statement about Kubernetes.
Kubernetes doesn't solve any technical problem, so the language it's written in is irrelevant.
What I meant is that the fact that the world is running on Kubernetes is not a qualitative statement about Kubernetes.