What’s Next: Roadmap for GoLand 2019.1

Two weeks ago we released GoLand 2018.3 which introduced a new Change Signature refactoring, debugging for Google App Engine apps, the ability to analyze core dumps, and support for Testify and Mozilla rr. It also improved code completion, added new code inspections and intention actions, and more.

If you haven’t checked out these new features yet, head on to our what’s new page. Or, if you prefer watching rather than reading, we also have this short 5-minute video for your viewing pleasure.

Over these two weeks, we’ve sorted out your feedback and discussed the features that we want to deliver in the next major version. Let’s go behind the scenes and take a sneak peek at what GoLand 2019.1 will likely bring.

But before we do that, we’ll continue our tradition of saying a heartfelt THANK YOU to all our evaluators! These kind people help us deliver a better IDE with each release and each EAP build, telling us about their product experiences and giving us their candid feedback and suggestions.

Today, we’d like to specially mention these wonderful folks:

  • Sergej Zagursky (YouTrack username: g7r)
  • Roland Illig (YouTrack username: roland.illig)
  • Stuart Carnie (YouTrack username: scarnie)
  • Denis Cheremisov (YouTrack username: sirkon)

As a token of our gratitude, each of you is getting a free 1-year subscription for GoLand! Use it to extend your current subscription or start a new one. You will receive an email with a coupon code and instructions on how to redeem it. Ping us if you don’t!

Now on to our roadmap!

Please note we can’t guarantee that all of the features listed below will be included in GoLand 2019.1.

Remote development

First of all, the next release will unlock remote developing via Docker and WSL!

Quick-fixes

  • GoLand 2019.1 will resolve references to unexported symbols and allow you to navigate to its declaration or use a quick-fix to export it.
  • Two quick-fixes based on Change Signature refactoring:

    — Add/remove missing return parameters in a signature.
    — Add/remove the parameter to the function call.

Code inspections

  • A new code inspection that will alert you about variables that are only written to but not read from.
  • An inspection that will warn about values used before corresponding error is handled.
  • A code inspection that will alert you about type assertions which can generate a panic.

Refactorings

  • The Extract Interface refactoring will be added to allow you to generate an interface from an existing type.
  • Extract Method will support return statements.
  • The Rename refactoring will ask whether implementations should be renamed together with a method specification.

Code editing

  • Support for escaping in string literals.
  • New intention actions to join and split declarations.

Debugger

  • Better presentation for Watches panel: Hex, Time format, and more.
  • Smart Step Into will make it easier to debug lines with multiple function calls.
  • The debugger will display goroutines instead of threads.

Look and feel

  • The IDE will download and install the Go SDK for you.
  • We will update descriptions in the Run configuration, error messages on Run, and improve warning messages for code inspections.

Didn’t find what you were looking for in either GoLand 2018.3 or this roadmap? Let us know! Feel free to comment here, use our issue tracker, or tweet at us. We’re listening!

This entry was posted in Roadmap and tagged , . Bookmark the permalink.

13 Responses to What’s Next: Roadmap for GoLand 2019.1

  1. Stuart Carnie says:

    Thank you, Ekaterina (username scarnie)!

  2. Denis Cheremisov says:

    Showed this to my colleagues )

  3. nombreinvicto says:

    please, please, please add remote development functionality on remote SDK’s on Linux platforms like Raspberry Pis!!!

    • Alexander Zolotov says:

      Hi! It would help us a lot if you describe how you see this feature.

      Something like invoking go build and running the resulted execution right on the device using SSH commands? What about the libraries (GOPATH), should GoLand upload entire GOPATH on the device before the build?

      You can describe it here or in the new issue at https://youtrack.jetbrains.com.

      Thanks!

      • nombreinvicto says:

        Is this achievable? Lets say, Goland allows us to choose the Go SDK path of the remote target via SSH and it also automatically detects the GOPATH defined in the target device. No need to upload entire GOPATH on the device before the build. And yes, invoking go build would run the resulted execution right on the device using SSH.

        • Alexander Zolotov says:

          Hi!

          > Lets say, Goland allows us to choose the Go SDK path of the remote target via SSH and it also automatically detects the GOPATH defined in the target device.

          Ok.

          > No need to upload entire GOPATH on the device before the build.

          Then we need to download entire GOPATH from the remote device to the local system, right? So GoLand will be able to analyze the dependencies and provide proper completion/inspections/etc.

          > And yes, invoking go build would run the resulted execution right on the device using SSH.

          Ok.

          I think it is achievable, I’ll take a look at it in the nearest future. Please stay tuned. Your feedback during the EAP can help a lot with this.

  4. Aleksei Besogonov says:
    • Alexander Zolotov says:

      No plans on supporting it so far, sorry :(
      I think, as a workaround, you can generate Go files with SWIG. Please correct me if I’m wrong.

      • Aleksei Besogonov says:

        I can generate files manually but then I lose native SWIG support from Go compiler. So I need to commit generated files into the source code repository to be able to use modules natively.

        It shouldn’t actually be that hard to support SWIG, you just need to expand SWIG templates and index them.

        • Alexander Zolotov says:

          > It shouldn’t actually be that hard to support SWIG, you just need to expand SWIG templates and index them.

          I’m not sure what you mean by expanding SWIG template but indexing requires parsing and parsing of a completely new language and implementing its own resolution rules is not an easy task. It can be implemented via plugin, though.
          At the moment, we have other and more upvoted feature requests that don’t have any workarounds, so we’ll address them first.

          • Aleksei Besogonov says:

            During the build the compiler expands the SWIG template into Go files in a temporary folder.

            It would be nice if you could just index them. This doesn’t require any knowledge of SWIG.

            It would also help other code generators (protobuf comes to mind).

        • Alexander Zolotov says:

          Ah, got it now. This approach sounds reasonable and indeed it looks not so hard.
          Could you please describe the exact steps that GoLand should do regarding this in the https://youtrack.jetbrains.com/issue/GO-3828? Preferably, with a project sample.
          Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *