3 ms·

Like Java, Go is a fundamentally broken language and its mistakes, starting from not having sum/option/result types from day 1, make it impossible to fix. edit

Like Java, Go is a fundamentally broken language and its mistakes, starting from not having sum/option/result types from day 1, make it impossible to fix. edit to respond: as the commenter below pointed out, dynamic languages can express sum types just fine (though statically verifying e.g. null checks isn't possible without some sort of gradual typing effort). This is why they are superior to traditional statically typed languages like Java. But even better are languages which have static sum types.

AlotOfReading 6y ago
Yes, person on a lisp-powered hackers forum, tell us more about how languages lacking native sum types are unusable.
- Ericson2314 6y ago
  With untyped languages, essentially everything is a (shitty) sum type because of runtime tagging. Tags <-> sum type.
  - zeeboo 6y ago
    You can do dynamic tagged values in Go, too. It's called interface{} and everyone hates it. So this does not respond to the parent's point.
    - Ericson2314 6y ago
      I'm not arguing untyped is good: it's most certainly not. Everything nullable is also bad, and also introduces a limited some type (Maybe). What I am saying is if you have static types (good) but don't do anything else, you loose sums (bad). You then need to add (back) sums.
  - kazinator 6y ago
    Please don't spread this flamewar-provoking way of speaking about type-systems. Firstly, dynamic languages are typed. The word "untyped" has a very specific meaning in a narrow branch of computer science, as in "untyped calculus", which refers to a situation in which the types of the syntax tree nodes of the program are not being taken into consideration. (Which doesn't mean they don't exist, by the way!) In sofware engineering, an untyped language is something utterly unsafe, like assembly language or BCPL, where every value is just a machine word, and the meaning/type of a machine word is just that of whatever operation is being applied to it at a given spot in the program. Dynamic languages are typed, and even to the extent that some of them do assign type to the nodes of program (type inference). Secondly, a "tag" is an implementation concept. A tag typically does not give all of the type information about an object, or not about every object kind. There may be more than one kind of tag used. For instance, a value might have a two-bit tag indicating a crude classification of a value into four categories. For an unboxed fixnum integer, that indicates the exact type (fixnum), but most heap objects might be lumped into the same category accordint to that tag, distinguished by a more comprehensive type tag that might take on, say, one of twenty values. That tag is also not complete information for all objects. For instance for an OOP object, the tag might indicate "this is an OOP object", without regard for its class: all OOP objects might share the same tag. Yet, at the language level, their type is their class. Another example is functions. All functions might have a tag indicating "this is a function". There might be a separate tag for things like compiled function, interpreted function, foreign function or whatever. But the type of a function takes into account not just that it's a function, but other properties like number of arguments. In many dynamic languages, you cannot call a two arguments function with three arguments. That check doesn't come from the tag, which doesn't have that information. The type of an object in a dynamic setting goes beyond the tag. For some objects, the word tag tells everything, and the heap tag does for others; but not for all object kinds. When the dynamic language implements a type inference system, the truths which that inference system works with cannot simply be reasoning about tags. The representation of type has to include concepts like the class of an object, or the number of arguments and types of a function and its return type.
- wyager 6y ago
  I think it's disingenuous to conflate the GP's claims of poor design choices with "unusable". To its credit, lisps also tend to have plenty of interesting, unique, and very good design choices. I don't think it's fair to compare Go to lisp in this context.
  - deleted 6y ago
    [deleted]
higerordermap 6y ago
Can functional program people speak without mentioning sum types or monads?
- damnyou 6y ago
  I don't care nearly as much about first-class monads, though monadic patterns pop up everywhere in programming. Anyone who's written a foldMap or a flatMap has at least a sense of what a monad feels like. Sum types are a zillion times more important.
- pjmlp 6y ago
  Those educated on Lisp languages.
danfang 6y ago
Yep, every language is fundamentally broken. Fortunately, some are useful. Go has proven to be useful in building stuff that matters, at the end of the day. This unfortunately can't be said of all the fancy languages with perfect type systems.

AlotOfReading 6y ago

Yes, person on a lisp-powered hackers forum, tell us more about how languages lacking native sum types are unusable.

Ericson2314 6y ago
With untyped languages, essentially everything is a (shitty) sum type because of runtime tagging. Tags <-> sum type.
- zeeboo 6y ago
  You can do dynamic tagged values in Go, too. It's called interface{} and everyone hates it. So this does not respond to the parent's point.
  - Ericson2314 6y ago
    I'm not arguing untyped is good: it's most certainly not. Everything nullable is also bad, and also introduces a limited some type (Maybe). What I am saying is if you have static types (good) but don't do anything else, you loose sums (bad). You then need to add (back) sums.
- kazinator 6y ago
  Please don't spread this flamewar-provoking way of speaking about type-systems. Firstly, dynamic languages are typed. The word "untyped" has a very specific meaning in a narrow branch of computer science, as in "untyped calculus", which refers to a situation in which the types of the syntax tree nodes of the program are not being taken into consideration. (Which doesn't mean they don't exist, by the way!) In sofware engineering, an untyped language is something utterly unsafe, like assembly language or BCPL, where every value is just a machine word, and the meaning/type of a machine word is just that of whatever operation is being applied to it at a given spot in the program. Dynamic languages are typed, and even to the extent that some of them do assign type to the nodes of program (type inference). Secondly, a "tag" is an implementation concept. A tag typically does not give all of the type information about an object, or not about every object kind. There may be more than one kind of tag used. For instance, a value might have a two-bit tag indicating a crude classification of a value into four categories. For an unboxed fixnum integer, that indicates the exact type (fixnum), but most heap objects might be lumped into the same category accordint to that tag, distinguished by a more comprehensive type tag that might take on, say, one of twenty values. That tag is also not complete information for all objects. For instance for an OOP object, the tag might indicate "this is an OOP object", without regard for its class: all OOP objects might share the same tag. Yet, at the language level, their type is their class. Another example is functions. All functions might have a tag indicating "this is a function". There might be a separate tag for things like compiled function, interpreted function, foreign function or whatever. But the type of a function takes into account not just that it's a function, but other properties like number of arguments. In many dynamic languages, you cannot call a two arguments function with three arguments. That check doesn't come from the tag, which doesn't have that information. The type of an object in a dynamic setting goes beyond the tag. For some objects, the word tag tells everything, and the heap tag does for others; but not for all object kinds. When the dynamic language implements a type inference system, the truths which that inference system works with cannot simply be reasoning about tags. The representation of type has to include concepts like the class of an object, or the number of arguments and types of a function and its return type.
wyager 6y ago
I think it's disingenuous to conflate the GP's claims of poor design choices with "unusable". To its credit, lisps also tend to have plenty of interesting, unique, and very good design choices. I don't think it's fair to compare Go to lisp in this context.
- deleted 6y ago
  [deleted]

higerordermap 6y ago

Can functional program people speak without mentioning sum types or monads?

damnyou 6y ago
I don't care nearly as much about first-class monads, though monadic patterns pop up everywhere in programming. Anyone who's written a foldMap or a flatMap has at least a sense of what a monad feels like. Sum types are a zillion times more important.
pjmlp 6y ago
Those educated on Lisp languages.

danfang 6y ago

Yep, every language is fundamentally broken. Fortunately, some are useful. Go has proven to be useful in building stuff that matters, at the end of the day. This unfortunately can't be said of all the fancy languages with perfect type systems.