5 ms·

I really enjoyed this review. You can tell the author spent some time trying to spot the good and bad things about Go. Too many Go reviews turn out to be: Watc

by zuzun 11y ago

I really enjoyed this review. You can tell the author spent some time trying to spot the good and bad things about Go. Too many Go reviews turn out to be: Watch me trying to use Go as a functional programming language and fail miserably because it lacks generics. Anyway, just like the author I found myself fighting the forced directory structure at first, but it's something I started to like about Go: Go doesn't come with a complicated package management. All packages lie in a directory and you can edit everything with normal shell commands. This keeps things refreshingly simple.

picardo 11y ago
You're exactly right. It's sad that a lot of people in the community cannot keep an open mind when they evaluate a technology.
wyager 11y ago
>Watch me trying to use Go as a functional programming language and fail miserably because it lacks generics. Go's lack of generics and its incapacity for functional programming are mostly unrelated.
- bigdubs 11y ago
  Can you add more color here? What is the separation between generics and functional programming? As an example in favor of their coupling it is very hard to write generalized functions for list operations without generics (without duplicating code). It is especially hard if you want to maintain type safety and don't resort to type erasure (interface{}).
  - nine_k 11y ago
    You can do FP in Go — just not in a type-safe way. OTOH, chances are you'll still get more type safety than doing FP in Common Lisp.
    - innguest 11y ago
      > OTOH, chances are you'll still get more type safety than doing FP in Common Lisp. Maybe that was the case in the past? Now there's Shen, so now you can get a lot more type safety in Common Lisp than in Go.
      - nine_k 11y ago
        Definitely Shen, Typed Scheme, and Clojure give you much more type safety than "plain" Lisp. My closest encounters with Lisp is writing elisp, which lacks all these amenities. Thus my comment.
        karols 11y ago
        It's not entirely that bad in CL: (locally (declare (optimize (safety 3))) (defun list-int-p (list) (every #'integerp list)) (deftype list-int () `(satisfies list-int-p)) (defun xxx (list) (declare (type list-int list)) list)) It's still runtime check, but better than nothing.
        nine_k 11y ago
        Runtime checks can be implemented anywhere — I did similar things for Python and JavaScript, as many others here did, I suppose. It's better than nothing, but it still bombs in prod, instead of giving you a static analysis error. The nice thing about static types being a core part of the language (ML, Haskell, C#,...) is that you have concise syntax and type inference at all the required spots. Otherwise (Clojure) you have to be pretty verbose, as if you were writing Java.
        rol 11y ago
        In regards to Common Lisp, depending on which implementation you use you may get some sort of type checking at compile time. For example, if you save the following code[1] into a file and try to load it into SBCL, it will give a compile time error: (ql:quickload 'defstar) (use-package 'defstar) (declaim (optimize (debug 3) (speed 0) (safety 3))) (defun* factorial ((x (integer 0 *))) ;; x is an integer from 0 up to +inf (if (zerop x) 1 (* x (factorial (1- x))))) (defun main () (factorial "foo") ;; Compile time error: "foo" conflicts with its assert type UNSIGNED-BTYE (factorial -1) ;; Compile time error: -1 conflicts with its assert type UNSIGNED-BTYE (factorial 1.0) ;; Compile time error: 1.0 conflicts with its assert type UNSIGNED-BTYE (factorial 0)) ;; Works And when you load the file into SBCL you get the following error message (assuming you have Quicklisp installed): $ sbcl --load compile-time-safety.lisp This is SBCL 1.2.7, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. To load "defstar": Load 1 ASDF system: defstar ; Loading "defstar" ; file: /home/rol/src/lisp/compile-time-safety.lisp ; in: DEFUN MAIN ; (FACTORIAL "foo") ; ; caught WARNING: ; Constant "foo" conflicts with its asserted type UNSIGNED-BYTE. ; See also: ; The SBCL Manual, Node "Handling of Types" ; ; compilation unit finished ; caught 1 WARNING condition It's not as nice as Haskell's type system, but it's something :) The main problem with this sort of compile-time checking is that it's implementation dependent, so some Common Lisp implementation may not provide it. You can configure the defstar library that I used on this code so that it automatically adds calls to "(check-type ...)". But then you are back at doing run-time checking of types. -- [1] - The defstar library can be found on Quicklisp or here: https://bitbucket.org/eeeickythump/defstar/ https://bitbucket.org/eeeickythump/defstar/ It's pretty much just a nicer way to write all of the "(declaim ...)" and "(declare ...)" needed to provide the most information to the Common Lisp type system.
  - wyager 11y ago
    >What is the separation between generics and functional programming? What is the connection? There are tons of functional languages (Tulip, Racket, some Lisps) that are untyped or optionally typed. Strong types are awesome, but you don't need them for FP. Go isn't good at powerful typing or functional programming.
- innguest 11y ago
  Except for the tiny fact that you don't get higher-kinded types, which is huge for functional programming.
  - Manishearth 11y ago
    Note that Rust doesn't have proper HKTs yet, though I believe we'll be getting them eventually.
  - seanmcdirmid 11y ago
    Many statically typed FP languages don't have higher kinded types, or haven't had them for very long. They are kind of new.
    - innguest 11y ago
      Such as?
      - seanmcdirmid 11y ago
        F# for sure. I'm only sure that Haskell and Scala have them, I'm not sure about SML, OCAML, and the other statically typed FP languages (definitely none of the simple statically typed OO languages have them).
  - wyager 11y ago
    HKTs aren't even remotely necessary for basic functional programming. HKTs are very useful for e.g. typeclasses (used for Monad, Functor, etc. definitions) but you don't need them. Strictly speaking, you don't even need types at all (even though they're great).
    - innguest 11y ago
      That's totally right which is why I never said anything to the contrary. You're crazy if you do FP without HKT though.
- lmm 11y ago
  If you want to represent effects as pure value + interpreter (e.g. IO from Haskell) then you pretty much need generics. To my mind avoiding side effects is a central part of "functional programming", but the term means different things to different people.
istvan__ 11y ago
Which part of his review was about functional programming in particular? Generics has nothing to do with functional programming at all. I think it would be worth to clarify what does functional programming mean to you.
- AnimalMuppet 11y ago
  zuzun said: > Too many Go reviews turn out to be: Watch me trying to use Go as a functional programming language and fail miserably because it lacks generics. You replied: > Which part of his review was about functional programming in particular? I think you totally missed zuzun's point. The point was not that this review was about functional programming, the point was that this review was not about functional programming.
  - istvan__ 11y ago
    Yeah like all of the other guys in the thread. Everybody missed. I understand now, my bad of getting involved in this low class debate that has nothing factual or valuable.

by zuzun 11y ago

picardo 11y ago

You're exactly right. It's sad that a lot of people in the community cannot keep an open mind when they evaluate a technology.

wyager 11y ago

>Watch me trying to use Go as a functional programming language and fail miserably because it lacks generics. Go's lack of generics and its incapacity for functional programming are mostly unrelated.

bigdubs 11y ago
Can you add more color here? What is the separation between generics and functional programming? As an example in favor of their coupling it is very hard to write generalized functions for list operations without generics (without duplicating code). It is especially hard if you want to maintain type safety and don't resort to type erasure (interface{}).
- nine_k 11y ago
  You can do FP in Go — just not in a type-safe way. OTOH, chances are you'll still get more type safety than doing FP in Common Lisp.
  - innguest 11y ago
    > OTOH, chances are you'll still get more type safety than doing FP in Common Lisp. Maybe that was the case in the past? Now there's Shen, so now you can get a lot more type safety in Common Lisp than in Go.
    - nine_k 11y ago
      Definitely Shen, Typed Scheme, and Clojure give you much more type safety than "plain" Lisp. My closest encounters with Lisp is writing elisp, which lacks all these amenities. Thus my comment.
      - karols 11y ago
        It's not entirely that bad in CL: (locally (declare (optimize (safety 3))) (defun list-int-p (list) (every #'integerp list)) (deftype list-int () `(satisfies list-int-p)) (defun xxx (list) (declare (type list-int list)) list)) It's still runtime check, but better than nothing.
        nine_k 11y ago
        Runtime checks can be implemented anywhere — I did similar things for Python and JavaScript, as many others here did, I suppose. It's better than nothing, but it still bombs in prod, instead of giving you a static analysis error. The nice thing about static types being a core part of the language (ML, Haskell, C#,...) is that you have concise syntax and type inference at all the required spots. Otherwise (Clojure) you have to be pretty verbose, as if you were writing Java.
        rol 11y ago
        In regards to Common Lisp, depending on which implementation you use you may get some sort of type checking at compile time. For example, if you save the following code[1] into a file and try to load it into SBCL, it will give a compile time error: (ql:quickload 'defstar) (use-package 'defstar) (declaim (optimize (debug 3) (speed 0) (safety 3))) (defun* factorial ((x (integer 0 *))) ;; x is an integer from 0 up to +inf (if (zerop x) 1 (* x (factorial (1- x))))) (defun main () (factorial "foo") ;; Compile time error: "foo" conflicts with its assert type UNSIGNED-BTYE (factorial -1) ;; Compile time error: -1 conflicts with its assert type UNSIGNED-BTYE (factorial 1.0) ;; Compile time error: 1.0 conflicts with its assert type UNSIGNED-BTYE (factorial 0)) ;; Works And when you load the file into SBCL you get the following error message (assuming you have Quicklisp installed): $ sbcl --load compile-time-safety.lisp This is SBCL 1.2.7, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. To load "defstar": Load 1 ASDF system: defstar ; Loading "defstar" ; file: /home/rol/src/lisp/compile-time-safety.lisp ; in: DEFUN MAIN ; (FACTORIAL "foo") ; ; caught WARNING: ; Constant "foo" conflicts with its asserted type UNSIGNED-BYTE. ; See also: ; The SBCL Manual, Node "Handling of Types" ; ; compilation unit finished ; caught 1 WARNING condition It's not as nice as Haskell's type system, but it's something :) The main problem with this sort of compile-time checking is that it's implementation dependent, so some Common Lisp implementation may not provide it. You can configure the defstar library that I used on this code so that it automatically adds calls to "(check-type ...)". But then you are back at doing run-time checking of types. -- [1] - The defstar library can be found on Quicklisp or here: https://bitbucket.org/eeeickythump/defstar/ https://bitbucket.org/eeeickythump/defstar/ It's pretty much just a nicer way to write all of the "(declaim ...)" and "(declare ...)" needed to provide the most information to the Common Lisp type system.
- wyager 11y ago
  >What is the separation between generics and functional programming? What is the connection? There are tons of functional languages (Tulip, Racket, some Lisps) that are untyped or optionally typed. Strong types are awesome, but you don't need them for FP. Go isn't good at powerful typing or functional programming.
innguest 11y ago
Except for the tiny fact that you don't get higher-kinded types, which is huge for functional programming.
- Manishearth 11y ago
  Note that Rust doesn't have proper HKTs yet, though I believe we'll be getting them eventually.
- seanmcdirmid 11y ago
  Many statically typed FP languages don't have higher kinded types, or haven't had them for very long. They are kind of new.
  - innguest 11y ago
    Such as?
    - seanmcdirmid 11y ago
      F# for sure. I'm only sure that Haskell and Scala have them, I'm not sure about SML, OCAML, and the other statically typed FP languages (definitely none of the simple statically typed OO languages have them).
- wyager 11y ago
  HKTs aren't even remotely necessary for basic functional programming. HKTs are very useful for e.g. typeclasses (used for Monad, Functor, etc. definitions) but you don't need them. Strictly speaking, you don't even need types at all (even though they're great).
  - innguest 11y ago
    That's totally right which is why I never said anything to the contrary. You're crazy if you do FP without HKT though.
lmm 11y ago
If you want to represent effects as pure value + interpreter (e.g. IO from Haskell) then you pretty much need generics. To my mind avoiding side effects is a central part of "functional programming", but the term means different things to different people.

istvan__ 11y ago

Which part of his review was about functional programming in particular? Generics has nothing to do with functional programming at all. I think it would be worth to clarify what does functional programming mean to you.

AnimalMuppet 11y ago
zuzun said: > Too many Go reviews turn out to be: Watch me trying to use Go as a functional programming language and fail miserably because it lacks generics. You replied: > Which part of his review was about functional programming in particular? I think you totally missed zuzun's point. The point was not that this review was about functional programming, the point was that this review was not about functional programming.
- istvan__ 11y ago
  Yeah like all of the other guys in the thread. Everybody missed. I understand now, my bad of getting involved in this low class debate that has nothing factual or valuable.