4 ms·

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

by xvilka 6y ago

CameronNemo 6y ago
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).
- philosopher1234 6y ago
  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.
  - CameronNemo 6y ago
    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 https://golang.org/pkg/database/sql/#NullBool.Scan > Scanner is an interface used by Scan. https://golang.org/pkg/database/sql/#Scanner 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.
    - philosopher1234 6y ago
      >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.
      - CameronNemo 6y ago
        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.
      - deleted 6y ago
        [deleted]
    - tptacek 6y ago
      Null pointer exceptions in Go are, technically, SEGVs. But they're just NPEs. Do you have something more interesting than that?
      - searchableguy 6y ago
        Have you read this - https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/ https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...
- zapf 6y ago
  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.
  - square_usual 6y ago
    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.
- StavrosK 6y ago
  I have had a very pleasant experience using types in a FastAPI project (detailed here): https://www.stavros.io/posts/fastapi-with-django/ 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.

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

by xvilka 6y ago

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).

philosopher1234 6y ago
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.
- CameronNemo 6y ago
  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 https://golang.org/pkg/database/sql/#NullBool.Scan > Scanner is an interface used by Scan. https://golang.org/pkg/database/sql/#Scanner 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.
  - philosopher1234 6y ago
    >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.
    - CameronNemo 6y ago
      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.
    - deleted 6y ago
      [deleted]
  - tptacek 6y ago
    Null pointer exceptions in Go are, technically, SEGVs. But they're just NPEs. Do you have something more interesting than that?
    - searchableguy 6y ago
      Have you read this - https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/ https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...
zapf 6y ago
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.
- square_usual 6y ago
  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.
StavrosK 6y ago
I have had a very pleasant experience using types in a FastAPI project (detailed here): https://www.stavros.io/posts/fastapi-with-django/ 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.