13 ms·

>Nim, Dart, and C as a comparison) Could I ask about your thoughts regarding Go (which has much less syntax and fewer features than all of the above). Have yo

>Nim, Dart, and C as a comparison) Could I ask about your thoughts regarding Go (which has much less syntax and fewer features than all of the above). Have you looked into it?

christophilus 9y ago
Yeah. It should have been in that list, actually. I wanted to like Go. It seems simple (which is what I like so much about Clojure), but honestly, I found it to be frustrating for all the standard reasons the Go team is tired of hearing (e.g. no generics, error handling littering my code and obscuring intent, etc). In fact, I think Go doesn't quite deserve the reputation it has as being a simple language. It's a familiar language, and it's a bare-bones language, but that's not the same thing as being simple. One last thing that was interesting: I got more null pointer runtime exceptions in Go than I expected (vs none in Nim, for example). Granted, I'm a Go n00b, but I'm also a Nim and Dart n00b, and didn't have nearly as much trouble with those two languages (aside from the aforementioned compiler bugs). I really wish modern statically typed languages would rid us of null pointer errors once and for all. This is totally possible with Option types, but seems to rarely be done. I wonder why?
- lambda 9y ago
  Have you looked at Rust? It uses Option types, has generics, also uses return values for error handling but has a lot more syntactic sugar to make it cleaner than in Go.
  - christophilus 9y ago
    I have tried Rust in the past, though not on this particular hobby project (my Clojure interpreter). I found it hard to get into, and I've gotten into a lot of languages in my time-- some of which are considered challenging (e.g. Haskell). With Rust, I always felt I spent too much time wrestling with it, and not enough time being productive. I imagine that you hit a threshold at some point and that begins to change. But for my side projects, that bar wasn't worth jumping.
    - steveklabnik 9y ago
      Rust's major goals this year are around learnability and productivity; maybe come check it out again someday :)
      - theprotocol 9y ago
        Could you point to any materials (e.g. blog post, roadmap document...) that deal with this? Thanks.
        steveklabnik 9y ago
        https://blog.rust-lang.org/2017/07/05/Rust-Roadmap-Update.html https://blog.rust-lang.org/2017/07/05/Rust-Roadmap-Update.ht... is our "the year is half over" update, and has a link to the overall goals right at the top.
        theprotocol 9y ago
        Awesome, thanks!
      - OoooooooO 9y ago
        Inferred lifetimes? A man can hope :).
        steveklabnik 9y ago
        If it were always possible to infer all lifetimes, we'd do it. Unfortunately that's not the case. There are a number of RFCs in the pipeline to help with lifetimes, including more elision. In no particular order: https://github.com/rust-lang/rfcs/pull/2115 https://github.com/rust-lang/rfcs/pull/2115 https://github.com/rust-lang/rfcs/pull/2094 https://github.com/rust-lang/rfcs/pull/2094 https://github.com/rust-lang/rfcs/pull/2093 https://github.com/rust-lang/rfcs/pull/2093
        dbaupp 9y ago
        Inferring lifetimes from the implementation of a function won't happen for the same reason that inferring types won't happen: it is really nice for the signature of a function to not automatically be changed if the body is changed, instead programmers should be told when they might be breaking their users. However, the compiler could (and did, I believe) run inference and suggest a fix that the programmer can explicitly include.
- logicallee 9y ago
  EDIT: this is getting downvotes for some reason even though it's just addressed to OP. OP, you could email me at the link on my profile if you didn't want to answer here. I'm not on the Go team or anything, just curious. --- Thanks for your answers! So I know you don't want to rehash what's easy to find elsewhere, but your perspective is different because you wrote a Clojure interpreter. It's not the same as what I can find from people who just use languages. You just list: >(e.g. no generics, error handling littering my code and obscuring intent, etc). But could you flesh out this litany of complaints, even if it's common? I just want to know your version of that list, without the 'etc'. It's not going to be the same as other people's - different things will bother you or come to mind for you. I'm trying to understand these from your perspective and background. (which is unusual.) Secondly, you write "but that's not the same thing as being simple". I don't really understand. Here on HN, people say you can pick up Go in an "afternoon" and become proficient in "a week". You write that it is not simple but I don't know what you mean in specific, even when you write as a "Go n00b". This reply will be particularly interesting to me, because, since you've literally written an interpreter, compared to an average user, everything is simple for you. Like, think of a standard designer who has first dabbled in Javascript and for some reason picks up Go. Whatever isn't "simple" for them would ordinarily be super-simple for you. So what's not "simple" for you is like obscure string physics to a person who is barely a programmer at all. I'm really curious what parts you didn't find simple. Thank you.
  - cstrahan 9y ago
    I'll let the parent answer you (though I have similar sentiments as someone with language implementation experience, and FWIW, I have professional experience with Go, Ruby, JavaScript, Clojure, C#, and I've used Haskell, F#, and much more in my free time). I will, however, point out that you're likely using a different definition of simple ("easily understood or done; presenting no difficulty. ") than is often used in technical circles ("composed of a single element; not compound"). Simplicity and ease are distinct, and one does not necessarily imply the other; it's not hard to find convoluted designs that feel easy due to familiarity, while a much smaller, consistent design will feel difficult because the concepts (while fewer in number) are foreign. Rich Hickey (creator of Clojure) gave a great talk on easy vs simple: https://www.youtube.com/watch?v=rI8tNMsozo0 https://www.youtube.com/watch?v=rI8tNMsozo0 Here's something familiar to most professional web developers: JavaScript. But it's also complicated: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat Here's the spec: https://www.ecma-international.org/ecma-262/8.0/index.html https://www.ecma-international.org/ecma-262/8.0/index.html And here's something unfamiliar and often considered difficult: lambda calculus. And yet it's very simple. Here's the entire definition of lambda expressions (lifted from Wikipedia): --- Lambda expressions are composed of: * variables v1, v2, ..., vn, ... * the abstraction symbols lambda 'λ' and dot '.' * parentheses ( ) The set of lambda expressions, Λ, can be defined inductively: 1. If x is a variable, then x ∈ Λ 2. If x is a variable and M ∈ Λ, then (λx.M) ∈ Λ 3. If M, N ∈ Λ, then (M N) ∈ Λ Instances of rule 2 are known as abstractions and instances of rule 3 are known as applications. --- So, while JavaScript programmers might find the lambda calculus unapproachable, it would be difficult to argue that the former has fewer gotchas than the latter, as the former is wildly complicated and the latter is so simple that you could fit its definition on business card. Once you appreciate the difference between simplicity and ease you can better evaluate your options, as it might be worth investing time in learning an intimidating, foreign solution if you believe that it will provide better stability/correctness guarantees/etc. Also, simple things are generally easier to work with compared to complex things assuming a similar degree of experience -- so investing in unfamiliar-yet-simple things will often save you a lot of effort in the long run. Strictly adhering to familiar things is a recipe for being stuck in a local optimum. To take this full circle, Go being easy doesn't mean that it's simple.
- TylerE 9y ago
  I sometimes feel Go went to far, as in the classic quote "Make it as simple as possible, but no simpler".
  - logicallee 9y ago
    I understand what you mean by your quote. I will give you a toy example, then show the single example I have from Go, and ask if you know of any more. Toy example, a language that is simpler than possible: - If a language does not have functions, you must copy and paste the code every time you call it. Such a language would be "simpler than possible". The only example I know from Go: - Many people feel that the lack of generic functions can be solved similarly - such as copying and pasting code or doing search/replace - but makes the language "simpler than possible". (in the exact sense you mean.) (A generic function is one that works on different types without knowing what they are when it is written, or similar behavior.) So I've given you a single real example. But it's the only one I can think of. Other than this example, can you list the ways in which you feel it's "simpler than possible" or went "too far"? I would really appreciate if you could be specific.
    - omaranto 9y ago
      I'll repeat my usual comment about what I found annoying in Go: It seems like strings are basically the only data type of unlimited size that is supported as map keys (or at least that seemed to be the case a few years ago). I think that only types for which equality is defined in the language could be used as keys. Those types where numbers, characters and all other "small" fixed-size types, structs all of those members had equality defined, arrays of a type with equality, and strings. The size of an array is part of the type, so in that list of types with equality the only source of unlimited sizedness are strings. I guess that cover most cases where you want a type of unknown size as a key, but I found it pretty annoying. If you want to use, say, polynomials with integer coefficients as keys in a map, you'd have to either choose a fixed maximum size (degree, for example, or number of monomials) for the polynomials or convert back and forth between strings. It's not the only language that forces you to convert things to strings and back for use as map keys (AWK and Lua come to mind), but I wish it didn't have that limitation.

>Nim, Dart, and C as a comparison) Could I ask about your thoughts regarding Go (which has much less syntax and fewer features than all of the above). Have you looked into it?

christophilus 9y ago

Yeah. It should have been in that list, actually. I wanted to like Go. It seems simple (which is what I like so much about Clojure), but honestly, I found it to be frustrating for all the standard reasons the Go team is tired of hearing (e.g. no generics, error handling littering my code and obscuring intent, etc). In fact, I think Go doesn't quite deserve the reputation it has as being a simple language. It's a familiar language, and it's a bare-bones language, but that's not the same thing as being simple. One last thing that was interesting: I got more null pointer runtime exceptions in Go than I expected (vs none in Nim, for example). Granted, I'm a Go n00b, but I'm also a Nim and Dart n00b, and didn't have nearly as much trouble with those two languages (aside from the aforementioned compiler bugs). I really wish modern statically typed languages would rid us of null pointer errors once and for all. This is totally possible with Option types, but seems to rarely be done. I wonder why?

lambda 9y ago
Have you looked at Rust? It uses Option types, has generics, also uses return values for error handling but has a lot more syntactic sugar to make it cleaner than in Go.
- christophilus 9y ago
  I have tried Rust in the past, though not on this particular hobby project (my Clojure interpreter). I found it hard to get into, and I've gotten into a lot of languages in my time-- some of which are considered challenging (e.g. Haskell). With Rust, I always felt I spent too much time wrestling with it, and not enough time being productive. I imagine that you hit a threshold at some point and that begins to change. But for my side projects, that bar wasn't worth jumping.
  - steveklabnik 9y ago
    Rust's major goals this year are around learnability and productivity; maybe come check it out again someday :)
    - theprotocol 9y ago
      Could you point to any materials (e.g. blog post, roadmap document...) that deal with this? Thanks.
      - steveklabnik 9y ago
        https://blog.rust-lang.org/2017/07/05/Rust-Roadmap-Update.html https://blog.rust-lang.org/2017/07/05/Rust-Roadmap-Update.ht... is our "the year is half over" update, and has a link to the overall goals right at the top.
        theprotocol 9y ago
        Awesome, thanks!
    - OoooooooO 9y ago
      Inferred lifetimes? A man can hope :).
      - steveklabnik 9y ago
        If it were always possible to infer all lifetimes, we'd do it. Unfortunately that's not the case. There are a number of RFCs in the pipeline to help with lifetimes, including more elision. In no particular order: https://github.com/rust-lang/rfcs/pull/2115 https://github.com/rust-lang/rfcs/pull/2115 https://github.com/rust-lang/rfcs/pull/2094 https://github.com/rust-lang/rfcs/pull/2094 https://github.com/rust-lang/rfcs/pull/2093 https://github.com/rust-lang/rfcs/pull/2093
      - dbaupp 9y ago
        Inferring lifetimes from the implementation of a function won't happen for the same reason that inferring types won't happen: it is really nice for the signature of a function to not automatically be changed if the body is changed, instead programmers should be told when they might be breaking their users. However, the compiler could (and did, I believe) run inference and suggest a fix that the programmer can explicitly include.
logicallee 9y ago
EDIT: this is getting downvotes for some reason even though it's just addressed to OP. OP, you could email me at the link on my profile if you didn't want to answer here. I'm not on the Go team or anything, just curious. --- Thanks for your answers! So I know you don't want to rehash what's easy to find elsewhere, but your perspective is different because you wrote a Clojure interpreter. It's not the same as what I can find from people who just use languages. You just list: >(e.g. no generics, error handling littering my code and obscuring intent, etc). But could you flesh out this litany of complaints, even if it's common? I just want to know your version of that list, without the 'etc'. It's not going to be the same as other people's - different things will bother you or come to mind for you. I'm trying to understand these from your perspective and background. (which is unusual.) Secondly, you write "but that's not the same thing as being simple". I don't really understand. Here on HN, people say you can pick up Go in an "afternoon" and become proficient in "a week". You write that it is not simple but I don't know what you mean in specific, even when you write as a "Go n00b". This reply will be particularly interesting to me, because, since you've literally written an interpreter, compared to an average user, everything is simple for you. Like, think of a standard designer who has first dabbled in Javascript and for some reason picks up Go. Whatever isn't "simple" for them would ordinarily be super-simple for you. So what's not "simple" for you is like obscure string physics to a person who is barely a programmer at all. I'm really curious what parts you didn't find simple. Thank you.
- cstrahan 9y ago
  I'll let the parent answer you (though I have similar sentiments as someone with language implementation experience, and FWIW, I have professional experience with Go, Ruby, JavaScript, Clojure, C#, and I've used Haskell, F#, and much more in my free time). I will, however, point out that you're likely using a different definition of simple ("easily understood or done; presenting no difficulty. ") than is often used in technical circles ("composed of a single element; not compound"). Simplicity and ease are distinct, and one does not necessarily imply the other; it's not hard to find convoluted designs that feel easy due to familiarity, while a much smaller, consistent design will feel difficult because the concepts (while fewer in number) are foreign. Rich Hickey (creator of Clojure) gave a great talk on easy vs simple: https://www.youtube.com/watch?v=rI8tNMsozo0 https://www.youtube.com/watch?v=rI8tNMsozo0 Here's something familiar to most professional web developers: JavaScript. But it's also complicated: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat Here's the spec: https://www.ecma-international.org/ecma-262/8.0/index.html https://www.ecma-international.org/ecma-262/8.0/index.html And here's something unfamiliar and often considered difficult: lambda calculus. And yet it's very simple. Here's the entire definition of lambda expressions (lifted from Wikipedia): --- Lambda expressions are composed of: * variables v1, v2, ..., vn, ... * the abstraction symbols lambda 'λ' and dot '.' * parentheses ( ) The set of lambda expressions, Λ, can be defined inductively: 1. If x is a variable, then x ∈ Λ 2. If x is a variable and M ∈ Λ, then (λx.M) ∈ Λ 3. If M, N ∈ Λ, then (M N) ∈ Λ Instances of rule 2 are known as abstractions and instances of rule 3 are known as applications. --- So, while JavaScript programmers might find the lambda calculus unapproachable, it would be difficult to argue that the former has fewer gotchas than the latter, as the former is wildly complicated and the latter is so simple that you could fit its definition on business card. Once you appreciate the difference between simplicity and ease you can better evaluate your options, as it might be worth investing time in learning an intimidating, foreign solution if you believe that it will provide better stability/correctness guarantees/etc. Also, simple things are generally easier to work with compared to complex things assuming a similar degree of experience -- so investing in unfamiliar-yet-simple things will often save you a lot of effort in the long run. Strictly adhering to familiar things is a recipe for being stuck in a local optimum. To take this full circle, Go being easy doesn't mean that it's simple.
TylerE 9y ago
I sometimes feel Go went to far, as in the classic quote "Make it as simple as possible, but no simpler".
- logicallee 9y ago
  I understand what you mean by your quote. I will give you a toy example, then show the single example I have from Go, and ask if you know of any more. Toy example, a language that is simpler than possible: - If a language does not have functions, you must copy and paste the code every time you call it. Such a language would be "simpler than possible". The only example I know from Go: - Many people feel that the lack of generic functions can be solved similarly - such as copying and pasting code or doing search/replace - but makes the language "simpler than possible". (in the exact sense you mean.) (A generic function is one that works on different types without knowing what they are when it is written, or similar behavior.) So I've given you a single real example. But it's the only one I can think of. Other than this example, can you list the ways in which you feel it's "simpler than possible" or went "too far"? I would really appreciate if you could be specific.
  - omaranto 9y ago
    I'll repeat my usual comment about what I found annoying in Go: It seems like strings are basically the only data type of unlimited size that is supported as map keys (or at least that seemed to be the case a few years ago). I think that only types for which equality is defined in the language could be used as keys. Those types where numbers, characters and all other "small" fixed-size types, structs all of those members had equality defined, arrays of a type with equality, and strings. The size of an array is part of the type, so in that list of types with equality the only source of unlimited sizedness are strings. I guess that cover most cases where you want a type of unknown size as a key, but I found it pretty annoying. If you want to use, say, polynomials with integer coefficients as keys in a map, you'd have to either choose a fixed maximum size (degree, for example, or number of monomials) for the polynomials or convert back and forth between strings. It's not the only language that forces you to convert things to strings and back for use as map keys (AWK and Lua come to mind), but I wish it didn't have that limitation.