As someone who has been coding production Swift since 1.0 the Go example is a lot more what Swift in practice will look like. I suppose there are advantages to being able to only show the important parts.

The first line won't crash but in practice it is fairly rare where you'd implicitly unwrap something like that. URLs might be the only case where it is somewhat safe. But a more fair example would be something like

    func fetchUser(id: Int) async throws -> User {
      guard let url = URL(string: "https://api.example.com/users/\(id)") else {
        throw MyError.invalidURL
      }
    
      // you'll pretty much never see data(url: ...) in real life
      let request = URLRequest(url: url)
      // configure request
      
      let (data, response) = try await URLSession.shared.data(for: request)
      guard let httpResponse = response as? HTTPURLResponse,
            200..<300 ~= httpResponse.statusCode else {
        throw MyError.invalidResponseCode
      }
    
      // possibly other things you'd want to check
    
      return try JSONDecoder().decode(User.self, from: data)
    }

Oh, don't get me started on handling the same type of exception differently depending on what call actually threw the exception. I find the happy path in Swift to be lovely, but as soon as exceptions have to be handled or there's some details that have to be gotten right in terms of order of execution, everything turns into a massive mess.

Still better than the 3 lines of if err is not nil that go gets you to do though.

I'm not familiar with Swift's libraries, but what's the point of making this two lines instead of one:

  let request = URLRequest(url: url)
  let (data, response) = try await URLSession.shared.data(for: request)

  // vs
  let (data, response) = try await URLSession.shared.data(from: url)

Thanks. What could possibly cause an invalid URL in this example though?

Yes swift-format will say "never force-unwrap" because it is a potential crash.