[implying]

They've fixed the import / modules situation to a point where it's usable and much improved, and generics have been added.

However, the issue this brings up about structs / types not explicitly declaring which interfaces they implement is a real and unaddressed problem, especially in large codebases. The only tool that I'm aware of that finds implementations is GoLand, at steep JetBrains prices.

Figuring out what type an API is asking for should not require reading every line of code in the package, and slows down every developer of large Go projects

[voidfunc]

When developers who usually make 6 figures of money complain about $90/yr IDE price I just cannot help laugh. Actually it's even better... the price elevators down from $90 -> year2 90 - 20% -> year3 90 - 40%.

Over three years that's like $150-$200 total and it will save you so many headaches. But that's a steep price? Are you kidding? Why do developers hate tools that cost money when they save them time and allow them to do more?

[kstenerud]

Sorry, no. I have JetBrains and have since stopped using it for go development. It's too slow, too buggy, and lacks the ecosystem that VS code has. I still use it for Java because the rest are even worse

A language that depends too much on IDE integration for usability is a real problem, because now you have tool fragmentation as everyone goes different routes with varying levels of success to fix the deficiencies in your language. In the end you end up rolling your own tools as I have done, which is the absolute WORST of all worlds.

Go was supposed to be simple, but all it succeeded in doing is shifting the complexity elsewhere and calling mission accomplished. When you're designing a language, it's VERY important to understand the difference between the emergent complexity of the domain, and the inherent complexity of your design. The latter can be fixed, the former can only be managed - in ways that are already well researched (or just swept under the rug, as go has done).

Too much magic and too much "clever" re-purposing of existing paradigms (file names, capitalization, implicit contracts, etc) makes for an infuriatingly bad design.

[srer]

Pretty simple for me:

I like working with Free and Open software much more than proprietary software. I think it's important for society, and I have more fun that way too!

Also the payoff for me has been very good, I can learn emacs once and enjoy using it for the rest of my life for all significant written language tasks on a computer.

Perhaps I could be a little more efficient if I were using a jetbrains IDE, but then I wouldn't like what I was doing as much. Enjoying what I do, even if it may look slightly contrived to others, is important in me achieving results at work.

[faitswulff]

I would be more supportive of this message if it was a $90 LSP server that you could support by buying (a la intelephense), but software developers are very opinionated about their editors and not everyone wants to use IntelliJ products.

[xigoi]

Professional developers in the USA usually make 6 figures.

[implying]

Putting fundamental features of the language behind a price barrier at all will keep students and people who want to experiment with the language out of the ecosystem. This isn't a papercut, it's an intentional omission that has backfired and can only be fixed by tooling. If the only way to access an often necessary feature is proprietary, why not make the whole language proprietary at that point?

[bmitc]

What's even worse is getting companies to pay for this stuff. Getting a company to buy software to help you do your job is like pulling teeth.

[dehrmann]

I'm shocked at how often I see software engineers not paying for Sublime Text. These are people who get paid to write software not paying for software.

[beebmam]

I think a tool like GitHub Copilot is worth far more than $90/year and I'll gladly pay for it. Probably up to $500/year or even $1000/year I'd pay for Copilot. It has saved me so much headache and time. There's no real competitor for that product and I'm looking forward to it going GA. I'd use emacs/vim and Copilot any day over an IDE.

But I'm not sure any IDE is worth $90/year when VS Code is free. The extensions for VS Code are next-level, especially the SSH extension. No other IDE comes remotely close to how well that extension works for its use case.

[AtlasBarfed]

Well, the companies won't buy it for them without wasting about 10x the cost in approval paperwork.

[sanderjd]

Not to mention how much the company paying their salary (who should be paying for their IDE) makes!

[prmoustache]

Regardless of the price jetbrains intellij based editors are so slow they are borderline unusable.

[richardsondrew]

> However, the issue this brings up about structs / types not explicitly declaring which interfaces they implement is a real and unaddressed problem

You can do this with a line of code below the struct definition, something like:

  var _ <interface> = &<struct>{}

The compiler will also generate helpful errors if the struct doesn't implement the interface.

Not requiring struct definition is a great feature in golang. I'm able to add an interface to a struct defined in another library to inject a different implementation for unit tests.

[thiht]

It would be cool though to be able to optionally declare the interfaces implemented by your struct, for documentation and tooling purpose. Also to validate that the struct you’re writing actually implements the interface you have in mind. I know you can make an anonymous assignment to check that, but some sugar on that would be nice.

[mseepgood]

> is a real and unaddressed problem

No, it's not. It's one of the best features, and I wish every language did this. At least TypeScript does it, too.

[sam0x17]

It's more than that though. There is just no standard library to be spoken of. I mean things like the most basic string processing methods, etc., are left to the programmer to sort out themself. Every time I've done contracting work on Go projects, I'm shocked by the things I have to implement from scratch (not that it isn't fun) that we take for granted in every other modern compiled languge I've tried (Rust, Crystal, Nim). I know this is more of an environment thing than a language thing, but in practice, language and environment are so intertwined it's pointless to not consider them together.

[gabereiser]

This isn’t true. Go has a basic standard package list. https://pkg.go.dev/std

[skybrian]

Not sure what you mean. The types consumed by an API are declared (though they might be interface types), and reading the godoc will give you a good overview of a package.

When would you want to look for all implementations of an interface? Is this something like an abstract syntax tree?

[grey-area]

The interface defines the behaviour required at the point of use - that’s the point of them. You should not need to know which types implement an interface and if you do things are deeply broken in your codebase.

I’ve developed large Go codebases and never had this problem so your last sentence is false. In addition this is not an issue other go developers I’ve spoken to have ever worried or talked about.

[serial_dev]

> structs / types not explicitly declaring which interfaces they implement is a real and unaddressed problem

Isn't it a feature? You can have a "writer" as long as it can "write", and then use that writer anywhere where a function expects a writer?

[richardwhiuk]

But do you obey all of the semantics of the writer interface which aren't expressed in code?

[sudo_chmod777]

> However, the issue this brings up about structs / types not explicitly declaring which interfaces they implement is a real and unaddressed problem, especially in large codebases. The only tool that I'm aware of that finds implementations is GoLand, at steep JetBrains prices.

So are you trying to find implemented interfaces or interfaces' implementors?

Former: In Vim I can use `:GoImplements`, which internally calls `guru` I guess.

Latter: `gopls` supports this.

I agree it's still a pain that one can not tell directly from code what interfaces a struct implements tho.

[thegeekpirate]

Every major editor I can think of has a way to find out what implements an interface using guru (https://github.com/golang/tools/tree/master/cmd/guru). In VSCode, it's right-click -> Find All Implementations. vim-go has :GoImplements. Using go-mode, emacs provides go-guru-implements.

[Beltalowda]

> However, the issue this brings up about structs / types not explicitly declaring which interfaces they implement is a real and unaddressed problem, especially in large codebases. The only tool that I'm aware of that finds implementations is GoLand, at steep JetBrains prices.

Alan Donovan's guru tool could do this, but it kind of broke with modules and it was never updated and deprecated in favour of gopls. I don't know if gopls added this yet (I never really found a use for it).

I don't think it's very hard to write a tool for this though; parsing Go code is fairly easy and the stdlib provides a decent API for it. I think you could have a functional tool in a day if you wanted to, although without any caching it might be a little bit slow on larger code bases.

[BreakfastB0b]

It's not great, but I use this pattern to check / enforce interface membership.

  type Bar interface {
     BarMethod(int, int) int
  }

  type Foo struct {}

  // Error: Foo does not implement Bar (missing method BarMethod)
  var _fooImplementsBar Bar = Foo{}

[zbobet2012]

I highly disagree with the interfaces criticism.

Firstly You can literally just use one of the dozens of go lsps or code tools to search for API invocations to find what structs are passed/called into it. More importantly if you need to know you've written bad code. The entire point of an interface is that you SHOULDN'T need to know the underlying type. If you do you've violated the entire point. Just pass concrete ones. I've written Go for years and never had a problem with this, even in large open source projects like Kuberenetes.

Secondly, the criticism about flipping return values order/meaning isn't a criticism of interface being structurally typed (https://en.wikipedia.org/wiki/Structural_type_system). If you return int, int and the second int "should be even", you should have defined a type "Even" and returned int, Even*. Systems which are structurally typed can demonstrate functional extensionality and (https://github.com/FStarLang/FStar/wiki/SMT-Equality-and-Ext...) and check whether you've flipped the arguments, which would be a more valid criticism (but such checks are expensive and conflict with compile time requirements). Also Java has the same problem, if you define two interfaces with the same method signature and a single class implements both you can't disambiguate.

Thirdly, the structural typing has a huge advantage, namely looser coupling and more tightly defined interfaces. If you follow the "accept interfaces return structs" go idiom, you'll see why. An open source library that does so leaves their returned structs open to be used by consumer code, that itself uses interfaces, without modification required. This means most go code has small, tightly defined interfaces, where every function on the interface is invoked in the relevant function.

For example if you have a library with this definition:

type Baz struct {}

func (b Baz) Foo(){} func (b Baz) Bar(){}

I can use Baz in my code like so:

type Fooer interface { Foo() }

func DoSomething(f Fooer) { }

And use the underlying library, while being decoupled from it, without having to modify it.

Fourthly: You can explicitly say a type implements an interface...

* A good study: https://blog.boot.dev/golang/golang-interfaces/

* In Idris we would do:

even : Nat -> Bool even Z = True even (S k) = odd k where odd Z = False odd (S k) = even k

int -> even doubler a = 2 * a

[X6S1x6Okd1st]

You can explicitly declare that it implements an interface:

https://go.dev/play/p/VCcrSXT59w0

[benhoyt]

I think you forgot the "hasA" type on the var line. Fixed: https://go.dev/play/p/0Amm7nd1Av4

[raxxorraxor]

I don't write Golang but honestly that was one of the features that interested me the most. Automatic type compatibility. I get the criticism as you will depend on tooling to get some expected convenience. But if you are used to void *ptr anyway...

To be fair, most APIs need documentation and code is just plainly not enough. At least if we are talking about specialist interfaces that aren't just another web framework.

[saturn_vk]

Doesn't the official language server have support for this?