How and why GraphQL will influence the Sourcehut alpha

Does this mean that SourceHut will become completely written in Go? Amazing news if so!

Why? I am currently converting a Flask/SQLAlchemy application to Go and gRPC. Go has not been that much of a win from my perspective. Lots of rough edges and missing functionality in libraries available, a lackluster type system that does enough to get in the way but not enough to properly express programmatic intention, and an atypical non-ideal error handling model have left me with little reason to champion Go. Not that it is a terrible language, I just do not see the value add compared to even Python (let alone Kotlin or Rust).

Could you name some specific rough edges and missing functionality that have frustrated you? I'm a big fan of Go and have a good experience with it, so I'd be very curious to hear from someone with an opposite experience.

On several occasions I have gotten panics (segfaults), many times without using CGo. This is not something I would expect from a "high level" language that has a garbage collector.

The constant use of generated code is another real pain point, particularly when I am writing business logic that needs to operate on generated types for which there is no interface available that does what I need (and why would there be? how would the library/codegen-tool author know all the permutations of business logic that might be out there?).

The sql library has some fairly annoying documentation, e.g.

> Scan implements the Scanner interface.

https://golang.org/pkg/database/sql/#NullBool.Scan

> Scanner is an interface used by Scan.

https://golang.org/pkg/database/sql/#Scanner

There is only really one concrete example of how to use Scan on the godoc page.

The introspection capabilities (reflect package) are quite obtuse and error prone (basically requiring 100% test coverage because you lose nearly the entire type system), yet absolutely critical to implementing anything notably complex with Go.

>The constant use of generated code is another real pain point, particularly when I am writing business logic that needs to operate on generated types for which there is no interface available that does what I need (and why would there be? how would the library/codegen-tool author know all the permutations of business logic that might be out there?).

Not sure what you mean here. Is there a particular codegen tool you found lacking?

>The introspection capabilities (reflect package) are quite obtuse and error prone (basically requiring 100% test coverage because you lose nearly the entire type system), yet absolutely critical to implementing anything notably complex with Go.

Ah, the lack of generics. I haven't really written any particularly large projects, where have you had to use reflection when working with go in your projects?

I hope my questions don't come across as dismissive. I think the typical go response to your complaints are "it wont come up" (a YAGNI variant), so I'm always interested to hear about the cases where that argument fails.

Null pointer exceptions in Go are, technically, SEGVs. But they're just NPEs. Do you have something more interesting than that?

I'm not working on anything particularly interesting. Standard CRUD service. Codegen tools used are protoc, SQLBoiler, and some custom bits. Reflection is being used to intermediate between protobuf generated types and orm types.

Have you read this - https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...

Had a similar experience.

Typed languages are great for systems development, and I think, not so good for writing web applications.

I also think, Ruby, Python, JS have dominated web dev world largely cause they don't come in the way of the developer having to constantly convert HTML (untyped) and JS (untyped)into types for the backend programming language.

Remember how ActiveRecord (not sure about SQLAlchemy) simply took away the pain of managing types? You didn't have to explicitly parse or cast "0.001" into 0.01.

ActiveRecord is parsing those types, you just don't do it explicitly. IME, a dynamic language may not get in your way when you need to go between JS and the backend, but it also certainly won't get in your way when you're about to shoot yourself in the foot in a large-ish project with errors that could've been caught at compile.

I have had a very pleasant experience using types in a FastAPI project (detailed here): https://www.stavros.io/posts/fastapi-with-django/

I quite like Python's type system, it's not very mature yet but it's definitely good enough to already catch a lot of bugs.

Yes.