6 ms·

Frankly, this article has the opposite effect of convincing me. The author starts with a perfectly reasonable data model and munges it for some questionable spa

by phyrex 6y ago

Frankly, this article has the opposite effect of convincing me. The author starts with a perfectly reasonable data model and munges it for some questionable space savings (that only apply in the dumbest of databases that don't do any sort of compression), for the price of a lot of boilerplate, and significantly less insight into the data if you look at it in serialized format (either directly in the database or on the wire). Maybe someone can explain to me how this is supposed to be better?

corylanou1 6y ago
You aren't wrong. I think it depends on what your needs are. As well as what the scenarios are. If you are serializing this data a lot, then having ints vs strings is a significant advantage. Again, it depends on your use case. If you don't care about serialization size, then I agree, it's extra effort that you may not need.
shadowgovt 6y ago
One of Go's strengths is that it should make it easier to swing between the optimized abstraction and the less-optimized abstraction. If you start with that data represented as strings and then find yourself backed into a performance corner and need to change the representation, Go types and type-based compile-time method selection can make it a bit easier to make that change. Even in this era of fast computers and preposterously large storage, one sometimes hits a situation where the way to get the improvements you need is to start number-representing your strings.
- corylanou1 6y ago
  That's a great point. Anyone who has spent significant time with Go knows how easy it is to do a large refactor (or even a minor one) due to it being a types language. And yes, you may not start with ints, but you could easily add code for the marshal/unmarshal later on to convert those strings to ints for serialization purposes. And it wouldn't require a change to any of your other code, not to mention that if you stored these values in a database already you don't need to perform a migration either.
  - stouset 6y ago
    This perspective ignores the fact that there is no shortage of typed languages that don’t have all the—in 2021—inexcusable downsides of golang.
    - morelisp 6y ago
      There is unfortunately a shortage, still in 2021, of languages that have a null set of inexcusable downsides. I will trade - unhappily - ADTs for value types, automatic memory management, some language-level concurrency support, a compiler that builds our largest project in under two minutes, and a community large enough I can spend my time training new hires on fundamentals and business problems and not tool onboarding.
      - pjmlp 6y ago
        .NET Native, OCaml, Eiffel, Common Lisp, D, Nim just for starters.
      - kaba0 6y ago
        Value types are almost there in Java, but without deliberately trashing the GC you can get away without them, and it has all the other qualities (and will have ADTs as well, sealed classes are already in preview)
  - gher-shyu3i 6y ago
    Go has many shortcomings that make it difficult and extremely annoying to do refactorings. Things like no constructors where types are declared as follows A { Field1: field1, Field2, field2, } Now adding a new field to A would require ensuring that all code paths initialize Field3, otherwise you're going to have silent errors at runtime. This has been solved ages ago in Java and C# and similar languages by means of constructors.
    - shadowgovt 6y ago
      A constructor is just a function though... If I add a new field to a Java class and fail to add its initialization to the constructor, I have the exact same problem because Java initializes the field to its default value when the constructor is called. You are correct that every situation where the struct in Go is initialized "bare" would need to be addressed if a field is added, but Go considers this a feature, not a bug (and, conversely, considers "bare initialization" of structs at dozens of places in your code to be bad practice if that struct could ever grow new fields). If you're bare-initializing structs, you're comfortable using them in a "loosey-goosey" context where zero-initialized fields are permitted (or, better, useful... https://www.youtube.com/watch?v=PAAkCSZUG1c&t=6m25s https://www.youtube.com/watch?v=PAAkCSZUG1c&t=6m25s). In Go, the issue of required structure is addressed by wrapping the struct in an interface and then providing a function in the package that can create an instance of the interface. Used in that way, you get something very similar to a Java class (though Go doesn't force you into the "everything is a class" paradigm that Java demands).
- mhh__ 6y ago
  Is this compared to a good language or (say) server-side JavaScript because the languages I tend to use allow me to do that and Go looks looks very Algol-68-y from that perspective as opposed to some hyper abstract wonder-language.
  - shadowgovt 6y ago
    What languages do you tend to use?
    - mhh__ 6y ago
      I work for the D foundation, so mainly D for things I get to choose.
newlisper 6y ago
Bringing Java's premature over-engineered over-abstracted practices to Go.
- shellac 6y ago
  Java has Enums, so why would you bother with all of this?
- deleted 6y ago
  [deleted]
dastx 6y ago
That boiler plate usually can be generated for you. See Go's stringer which does all the magic for you. All you have to do is define the type and constants, and a go generate directive.
- lma21 6y ago
  would you have a sample code? sounds interesting
  - dastx 6y ago
    Example from the docs: // pill.go package painkiller //go:generate stringer -type=Pill type Pill int const ( Placebo Pill = iota Aspirin Ibuprofen Paracetamol Acetaminophen = Paracetamol ) Then running `go generate` will yield: $ cat pill_string.go // Code generated by "stringer -type=Pill"; DO NOT EDIT. package painkiller import "strconv" func _() { // An "invalid array index" compiler error signifies that the constant values have changed. // Re-run the stringer command to generate them again. var x [1]struct{} _ = x[Placebo-0] _ = x[Aspirin-1] _ = x[Ibuprofen-2] _ = x[Paracetamol-3] } const _Pill_name = "PlaceboAspirinIbuprofenParacetamol" var _Pill_index = [...]uint8{0, 7, 14, 23, 34} func (i Pill) String() string { if i < 0 || i >= Pill(len(_Pill_index)-1) { return "Pill(" + strconv.FormatInt(int64(i), 10) + ")" } return _Pill_name[_Pill_index[i]:_Pill_index[i+1]] } Note: indentation is messing up because of Hacker News, so ignore the indentation.
- itake 6y ago
  Code generators don't solve the problem of the language being too verbose/boiler plate. Instead of expressing a concept in a simple fashion, you have to generate 100s of lines of code that needs to be maintained across versions of golang and your data model.
- tsimionescu 6y ago
  And install stringer in every dev env, and debug all the boilerplate anyway when things go wrong. Code generation is always the last resort.
treis 6y ago
I think this is mostly a toy example. In the real world the Genre would have it's own data, books can belong to multiple Genres, and you'd need the concept of SubGenres. So you'd have: Book Genre BookToGenre GenreToGenre

by phyrex 6y ago

corylanou1 6y ago

You aren't wrong. I think it depends on what your needs are. As well as what the scenarios are. If you are serializing this data a lot, then having ints vs strings is a significant advantage. Again, it depends on your use case. If you don't care about serialization size, then I agree, it's extra effort that you may not need.

shadowgovt 6y ago

One of Go's strengths is that it should make it easier to swing between the optimized abstraction and the less-optimized abstraction. If you start with that data represented as strings and then find yourself backed into a performance corner and need to change the representation, Go types and type-based compile-time method selection can make it a bit easier to make that change. Even in this era of fast computers and preposterously large storage, one sometimes hits a situation where the way to get the improvements you need is to start number-representing your strings.

corylanou1 6y ago
That's a great point. Anyone who has spent significant time with Go knows how easy it is to do a large refactor (or even a minor one) due to it being a types language. And yes, you may not start with ints, but you could easily add code for the marshal/unmarshal later on to convert those strings to ints for serialization purposes. And it wouldn't require a change to any of your other code, not to mention that if you stored these values in a database already you don't need to perform a migration either.
- stouset 6y ago
  This perspective ignores the fact that there is no shortage of typed languages that don’t have all the—in 2021—inexcusable downsides of golang.
  - morelisp 6y ago
    There is unfortunately a shortage, still in 2021, of languages that have a null set of inexcusable downsides. I will trade - unhappily - ADTs for value types, automatic memory management, some language-level concurrency support, a compiler that builds our largest project in under two minutes, and a community large enough I can spend my time training new hires on fundamentals and business problems and not tool onboarding.
    - pjmlp 6y ago
      .NET Native, OCaml, Eiffel, Common Lisp, D, Nim just for starters.
    - kaba0 6y ago
      Value types are almost there in Java, but without deliberately trashing the GC you can get away without them, and it has all the other qualities (and will have ADTs as well, sealed classes are already in preview)
- gher-shyu3i 6y ago
  Go has many shortcomings that make it difficult and extremely annoying to do refactorings. Things like no constructors where types are declared as follows A { Field1: field1, Field2, field2, } Now adding a new field to A would require ensuring that all code paths initialize Field3, otherwise you're going to have silent errors at runtime. This has been solved ages ago in Java and C# and similar languages by means of constructors.
  - shadowgovt 6y ago
    A constructor is just a function though... If I add a new field to a Java class and fail to add its initialization to the constructor, I have the exact same problem because Java initializes the field to its default value when the constructor is called. You are correct that every situation where the struct in Go is initialized "bare" would need to be addressed if a field is added, but Go considers this a feature, not a bug (and, conversely, considers "bare initialization" of structs at dozens of places in your code to be bad practice if that struct could ever grow new fields). If you're bare-initializing structs, you're comfortable using them in a "loosey-goosey" context where zero-initialized fields are permitted (or, better, useful... https://www.youtube.com/watch?v=PAAkCSZUG1c&t=6m25s https://www.youtube.com/watch?v=PAAkCSZUG1c&t=6m25s). In Go, the issue of required structure is addressed by wrapping the struct in an interface and then providing a function in the package that can create an instance of the interface. Used in that way, you get something very similar to a Java class (though Go doesn't force you into the "everything is a class" paradigm that Java demands).
mhh__ 6y ago
Is this compared to a good language or (say) server-side JavaScript because the languages I tend to use allow me to do that and Go looks looks very Algol-68-y from that perspective as opposed to some hyper abstract wonder-language.
- shadowgovt 6y ago
  What languages do you tend to use?
  - mhh__ 6y ago
    I work for the D foundation, so mainly D for things I get to choose.

newlisper 6y ago

Bringing Java's premature over-engineered over-abstracted practices to Go.

shellac 6y ago
Java has Enums, so why would you bother with all of this?
deleted 6y ago
[deleted]

dastx 6y ago

That boiler plate usually can be generated for you. See Go's stringer which does all the magic for you. All you have to do is define the type and constants, and a go generate directive.

lma21 6y ago
would you have a sample code? sounds interesting
- dastx 6y ago
  Example from the docs: // pill.go package painkiller //go:generate stringer -type=Pill type Pill int const ( Placebo Pill = iota Aspirin Ibuprofen Paracetamol Acetaminophen = Paracetamol ) Then running `go generate` will yield: $ cat pill_string.go // Code generated by "stringer -type=Pill"; DO NOT EDIT. package painkiller import "strconv" func _() { // An "invalid array index" compiler error signifies that the constant values have changed. // Re-run the stringer command to generate them again. var x [1]struct{} _ = x[Placebo-0] _ = x[Aspirin-1] _ = x[Ibuprofen-2] _ = x[Paracetamol-3] } const _Pill_name = "PlaceboAspirinIbuprofenParacetamol" var _Pill_index = [...]uint8{0, 7, 14, 23, 34} func (i Pill) String() string { if i < 0 || i >= Pill(len(_Pill_index)-1) { return "Pill(" + strconv.FormatInt(int64(i), 10) + ")" } return _Pill_name[_Pill_index[i]:_Pill_index[i+1]] } Note: indentation is messing up because of Hacker News, so ignore the indentation.
itake 6y ago
Code generators don't solve the problem of the language being too verbose/boiler plate. Instead of expressing a concept in a simple fashion, you have to generate 100s of lines of code that needs to be maintained across versions of golang and your data model.
tsimionescu 6y ago
And install stringer in every dev env, and debug all the boilerplate anyway when things go wrong. Code generation is always the last resort.

treis 6y ago

I think this is mostly a toy example. In the real world the Genre would have it's own data, books can belong to multiple Genres, and you'd need the concept of SubGenres. So you'd have: Book Genre BookToGenre GenreToGenre