2 ms·

Good point. It's sometimes challenging to get a Rust program to compile... but if you do, it's probably going to work.

• moomin 2mo ago
  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.
  • m00x 2mo ago
    > 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.
    • dnautics 2mo ago
      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.
  • toolslive 2mo ago
    > "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 tool here. Change the concept? Just change the type in the code and follow through by fixing the error messages the compiler spits out.
    • moomin 2mo ago
      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.
• Pavilion2095 2mo ago
  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.
  • soniczentropy 2mo ago
    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.
    • Pavilion2095 1mo ago
      > Once I was as proficient at Rust as I was at Go That's a big time investment for many people though. The one they—or rather their employers—cannot really afford.
  • pdimitar 2mo ago
    Rust's disadvantage in adding time is mostly a one-time initial investment, in my experience. After you get comfortable and learn the important idioms, you go through the development loop quite quickly. Compilation/linking speed can still suck though.
• throwaway63467 2mo ago
  Not panicking doesn’t mean working as intended, the biggest issue with LLM generated code is that it will do something that’s subtly wrong not that it will crash. It anything LLMs are too careful with Golang code and litter useless nil checks everywhere e.g. for function calls with pointer receivers. That whole fear of panics is totally overblown.
  • thfuran 2mo ago
    Sure, rust has better memory safety than most languages, but it also has a strong enough type system that many other kinds of programming errors won't pass compilation.
    • throwaway63467 2mo ago
      So the language knows what you want to program and if it’s functionally correct? I don’t think so.