Migrating from Go to Rust

Perhaps more people are using AI as part of an editorial process that is largely driven by what they wish to convey but where they have stopped fighting the AI on its preferred style. It’s supremely annoying when AI updates your prose with its own formulation despite plenty of instructions otherwise. Too often AIs mangle meaning which can be especially worrisome as it’s not easy to catch subtle word/grammar changes that dramatically shift meaning. Overall though, defects aside, for me, and only very recently, it’s been more helpful than not. I think AIs will continue to improve in this regard and be better editorial partners. For competent writings, it won’t replace human authorship or expert review.

Specifically, I’ve recently used ChatGPT for legal/administrative writing where the AI seems to be trained on a large corpus and seems to know the conventions and vocabulary well; a lawyer who reviewed the work had important corrections. Before AI, I would have sought model filings and have had less success at emulating the genre. So it’s lowered time/cost somewhat but it takes lots of diligence. By default, current AI outputs seems intelligible but are still really far off the mark. I’ve found a structured interview is a good way to start rather than jumping into draft generation.

I'm so perplexed by this, because Rust errors are what make the language so amazing.

> Now I’m debugging macro expansion errors and spending approximately the same amount of time

This never happens once you've learned the language a bit more. Anyhow and thiserror are a cinch.

> I realize that this is pretty tedious, manual work, so someone points me to thiserr or similar

Claude writes Rust so effectively. It can do all of this for you now. It's effortless. In fact, I don't see any reason to use any other language unless I'm targeting web or some specific platform, or dealing with legacy code. Rust is now the best tool for most problems.

> Similarly when I had lifetime problems and half the community told me to just use clone and Rc everywhere until I had performance problems, so instead I just had different static analysis problems

Do this for a month, then it'll click and be second nature. Also Claude will make quick work of it now.

> feels like the least bad thing until the Rust community can arrive at some consensus and document it in The Book

It's difficult because it's so different. But once you get used to it, you'll realize it's the best approach we have right now.

> Or maybe I just need to try again in the LLM era?

Seriously this. You'll be writing Rust code as quickly as you would Python code. It'll be high quality. And the type system will mean that Claude emits better code on average. You'll pick it up quickly.

Go is really easy to read and write, even if Go's philosophy means that some of that feels clunky because it's less featureful than other languages. It makes up for it with a comprehensive stlib that makes it trivial to build services with few to no third party dependencies.

I don't think the value prop has changed at all there. One day the AI gravy train will stop and people who used AI to punch above their weight will no longer be able to debug the stuff they built unless they put in the hard work of learning the language.

Nothing to worry about with Go in that respect because of how much it's been designed to be simple. Even the annoying err/nil checks you need to do all the time are in service of that simplicity. It gets old fast but it leaves nothing to the imagination.

You can do better than the errors in other languages. You can provide all the relevant information in the emum variant.

  enum MyApiBindingCrateError {
    // You didn't provide an 
    // API key. Maybe we should 
    // design our interface to
    // make this impossible 
    ApiKeyMissing,

    // Client was unauthorized 
    // to make this request 
    AuthorizationError,

    // The entity you requested 
    // did not exist (404'd)
    NotFoundError,

    // You're sending too many 
    // requests to the server 
    TooManyRequests,

    // That specific error with
    // the API
    // Maybe users can't delete 
    // folders until they're empty 
    // Whatever 
    SpecificApiIssue1,

    // Some other specific error
    // with the API
    SpecificApiError2,
  
    // Server didn't respond the
    // way we expected. 
    // Here's what it told us
    UnexpectedHttpResponse { 
      // HTTP status code
      status_code: StatusCode, 

      // If it had a 
      // string-encoded body
      body: Option,
    },

    // Unhandled Issue with IO 
    IoError(io::Error),
  
    // Unhandled Issue with 
    // request library
    ReqwestError(reqwest::Error),

  }

The beauty with Rust is that you can create really detailed concrete errors at the crate level. Your callers will know exactly what the actual error states are.

Your application can be a little less structured if you want. Though with LLMs, I'm using anyhow and thiserror a lot less.

Quite new to Go, so sorry in advance for a stupid question:

> "Go got generics in 1.18 (March 2022), thirteen years after the language shipped. They are useful, but they feel tacked on, and in practice they have most of the downsides of a generic type system without delivering the upsides you’d expect coming from Rust, Haskell, or even modern C++."

The problems with Go generics have now largely been solved, haven't they? Is this comment from the author still applicable?