12 ms·

so.. Haskell and Scala? Those would be the top two that come to mind for me when someone says "highly 'logical' and 'compose well'", "having sum types", 'more e

so.. Haskell and Scala? Those would be the top two that come to mind for me when someone says "highly 'logical' and 'compose well'", "having sum types", 'more expressive', etc. I've heard they're great languages (haven't used them much myself), but I probably wouldn't choose them for say an early-stage startup. Go's value is in being a mundane, repetitive, boring language. It makes it easy for any random kid to dive into an existing code base and become productive, that can be super valuable. There's a theoretical gradient of programming languages where one side is "has a single expression for exactly your problem, a single unique expression you've never heard of exists to solve every possible problem" and the other is "requires thousands of expressions to express your problem, but only a thousand are available" - or something like that. My point? There's no perfect language, yet people are always trying to find one. It's OK if you don't like Go and prefer another language, the real devil / tradeoff is in the fact that conformance to a single language (or set of languages) is such a strong social phenomena. I think that's why people end up so angry with viewed-as-subpar languages like Go gaining so much traction: it limits personal choice of which language to work in. I'm positive linguists aren't happy with English becoming the global language either, but you've gotta admit - having a global language is valuable.

halfmatthalfcat 4y ago
Having written a lot of Scala, I generally agree until you can form a team that knows what they're doing or has a background in Scala. After that, Scala shines as the codebase(s) scale.
- ttfkam 4y ago
  Substitute Scala for any other programming language and the statement still holds. Experienced developers and those with specific language expertise excel when implementing in that language. Who would have expected that? /s
  - halfmatthalfcat 4y ago
    The point is the barrier to entry for Scala is higher but once you have a skilled team working in Scala, you probably get more velocity than others due to the language ergonomics.
    - sidlls 4y ago
      I don't think there are any (many?) studies on this subject. Much less that confirm this particular bias you've shown.
Thaxll 4y ago
Scala and Haskell are pretty much "dead" language, I worked with Scala in the past, it was impossible to find poeple willing to work with it so everything was re-written in Java.
- pjmlp 4y ago
  I bet plenty of universities will keep using them beyond our lifetimes. From that point of view they are doing quite well.
  - blakebreeder 4y ago
    you can also take a Latin course in college. how "well" is Latin doing?
    - pjmlp 4y ago
      Good, it is still the official language in Vatican documents, has an updated dictionary, and some European countries see it as a CV requirement by most HR departments when hiring for top management positions.
      - cinntaile 4y ago
        > some European countries see it as a CV requirement by most HR departments when hiring for top management positions. This sounds utterly bizarre, I have a very hard time believing this. Which countries would that be?
        MereInterest 4y ago
        I can't confirm the specific example, but this sounds like a smoke cover for nepotism and/or classism. If you're not allowed to recruit solely from your personal friend group, requiring that applicants be able to speak a dead language let's you select that same group of people while giving a flimsy justification.
karmakaze 4y ago
An F# program can be about as mundane as a similar Go program, only concise.
- throwaway894345 4y ago
  This is like the C++ argument that you should just use C++ because it has almost every feature so you can just use the ones you want and ignore the others. Of course, in practice you still have to deal with colleagues and upstream packages that use features you don’t like. Same deal with F#—you could write F# in a Go-like style, but you’ll be swimming against the current. And the only advantage is a little less verbosity, which really isn’t anyone’s bottleneck—people over-index on minimizing localized boilerplate and ignore the costs of gratuitous abstraction.
  - karmakaze 4y ago
    Type-inference is a zero-cost 'abstraction' and any place you choose can make explicit narrowing of them. The libraries I needed to make a web application didn't have any mind-bending patterns, but rather did the most obvious things with the basic language features.
nu11ptr 4y ago
> so.. Haskell and Scala? Those would be the top two that come to mind for me when someone says "highly 'logical' and 'compose well'", "having sum types", 'more expressive', etc. I wrote Scala for years - it might be a bit too complicated but overall pretty decent, but I hear good things about Scala 3. I think the ML's, of which it takes inspiration from, are probably a better match. OCaml (EDIT: or F# as another comment mentioned) for instance is a pretty nice balance. Haskell is very nice and I think qualifies except that it is pretty hard core purely functional with no punches pulled (unlike ML), so is foreign enough for most people not to be deemed a candidate. I like Rust probably best atm as it is "imperative but with a functional flair", but doesn't qualify as easy I don't think, but is definitely highly logical and composes very well (even if obviously not finished yet). > I've heard they're great languages (haven't used them much myself), but I probably wouldn't choose them for say an early-stage startup. Go's value is in being a mundane, repetitive, boring language. It makes it easy for any random kid to dive into an existing code base and become productive, that can be super valuable. I would probably agree on the novice programmer and picking up Go quickly which is arguably the prime feature of Go. I just question the quality of that code, and honestly, don't feel Go is nearly as easy as touted. It is simple for sure, but not always easy. I always had to look up simple things like those magic comment compiler directives and is that interface{} param a pointer or a pointer to a pointer? I just remember the lack of expressiveness actually causing real world confusion (for me at least). > There's a gradient of programming languages where one side is "has a single expression for exactly your problem, a single unique expression you've never heard of exists to solve every possible problem" and the other is "requires thousands of expressions to express your problem, but only a thousand are available" - or something like that. While true, I would argue we have found a small amount of constructs that fit well 80% of the time, and is demonstrability better than half the constructs that fit well 40% of the time. Trying to solve every problem with a new construct is not worth it, but nor is the opposite extreme IMO. > My point? There's no perfect language, yet people are always trying to find one. It's OK if you don't like Go and prefer another language. A real devil / tradeoff is the prohibition of using languages that do not conform with past (company) choices. Honestly not sure we've found the ideal language yet, and agree there is subjectivity and trade offs at about every turn. In fact, the only thing I'm certain of is that Go missed what I would look for in just about every category except a few (but I agree it is easy to learn, but does it matter if you can't write good code with it?). That said, very intelligent and respected people disagree with me, so to each their own.
foolfoolz 4y ago
> It makes it easy for any random kid to dive into an existing code base and become productive, that can be super valuable professional developers are rarely “kids”
typesanitizer 4y ago
> There's no perfect language, yet people are always trying to find one. It's OK if you don't like Go and prefer another language, the real devil / tradeoff is in the fact that conformance to a single language (or set of languages) is such a strong social phenomena. I think that's why people end up so angry with viewed-as-subpar languages like Go gaining so much traction I hope my post didn't come across this way. To be clear, I think Rust and Swift (as two examples that I mention multiple times) have a lot of problems (slow compilation being a very big one), and are by no means perfect. I'm not angry at Go's popularity as much as wanting improvements to the developer experience.
uncomputation 4y ago
> I'm positive linguists aren't happy with English becoming the global language either Nit: Linguists do not hold prescriptive opinions about the "quality" of languages. They analyze languages to form descriptive theories about the structures and features of certain languages. I only nitpick this because, while having a lingua franca is certainly valuable and there is nothing "bad" about English any more than literally any other language, the closest thing to this in programming "languages"/notations is actually C, not Go. It's hard to overstate the invisible influence on C on basically every mainstream language and how we think of programming and computers in general. An interesting analogue to your example of English is the varying efforts to transliterate most languages into using the Latin alphabet, much like how many programming languages today need/greatly benefit from a compatibility layer with a C compiler/the C standard library.
erik_seaberg 4y ago
> mundane, repetitive, boring language These apply just as well to assembly, yet they are the reasons almost nobody tries to use it.
astrange 4y ago
> so.. Haskell and Scala? Those would be the top two that come to mind for me when someone says "highly 'logical' and 'compose well'", "having sum types", 'more expressive', etc. I don't think Haskell composes that well; monads don't combine well (not that I could do better) since you can only stick them together in an ordered way, the lazy evaluation makes it complicated to see how your program will run by reading the code, and so on. Btw, "sum types" means enums; it's not actually a super-complicated Haskell only feature.
- kaba0 4y ago
  Do you write imperative programs that execute statements — out of order? Ordering is precisely the point of monads, since they are monoids as well. And sum types are most definitely not enums, though Rust’s enums do use a bit strange terminology here.
  - astrange 4y ago
    > Do you write imperative programs that execute statements — out of order? Ordering is precisely the point of monads, since they are monoids as well. Sure do. After all, your superscalar CPU executes things out of order, and C is a pure functional language in the memory monad. http://conal.net/blog/posts/the-c-language-is-purely-functional http://conal.net/blog/posts/the-c-language-is-purely-functio... > And sum types are most definitely not enums, though Rust’s enums do use a bit strange terminology here. Swift's enums too. But sure, in C it's an enum with a union at the end.
    - kaba0 4y ago
      Well, being pedantic, sure almost every modern CPU uses OOE. But they must do so with the huge caveat that from the outside it should be equivalent to executing it in serial (notwithstanding CPU vulnerabilities). But this is an implementation detail only, we could just as well use an older CPU design.

halfmatthalfcat 4y ago

Having written a lot of Scala, I generally agree until you can form a team that knows what they're doing or has a background in Scala. After that, Scala shines as the codebase(s) scale.

ttfkam 4y ago
Substitute Scala for any other programming language and the statement still holds. Experienced developers and those with specific language expertise excel when implementing in that language. Who would have expected that? /s
- halfmatthalfcat 4y ago
  The point is the barrier to entry for Scala is higher but once you have a skilled team working in Scala, you probably get more velocity than others due to the language ergonomics.
  - sidlls 4y ago
    I don't think there are any (many?) studies on this subject. Much less that confirm this particular bias you've shown.

Thaxll 4y ago

Scala and Haskell are pretty much "dead" language, I worked with Scala in the past, it was impossible to find poeple willing to work with it so everything was re-written in Java.

pjmlp 4y ago
I bet plenty of universities will keep using them beyond our lifetimes. From that point of view they are doing quite well.
- blakebreeder 4y ago
  you can also take a Latin course in college. how "well" is Latin doing?
  - pjmlp 4y ago
    Good, it is still the official language in Vatican documents, has an updated dictionary, and some European countries see it as a CV requirement by most HR departments when hiring for top management positions.
    - cinntaile 4y ago
      > some European countries see it as a CV requirement by most HR departments when hiring for top management positions. This sounds utterly bizarre, I have a very hard time believing this. Which countries would that be?
      - MereInterest 4y ago
        I can't confirm the specific example, but this sounds like a smoke cover for nepotism and/or classism. If you're not allowed to recruit solely from your personal friend group, requiring that applicants be able to speak a dead language let's you select that same group of people while giving a flimsy justification.

karmakaze 4y ago

An F# program can be about as mundane as a similar Go program, only concise.

throwaway894345 4y ago
This is like the C++ argument that you should just use C++ because it has almost every feature so you can just use the ones you want and ignore the others. Of course, in practice you still have to deal with colleagues and upstream packages that use features you don’t like. Same deal with F#—you could write F# in a Go-like style, but you’ll be swimming against the current. And the only advantage is a little less verbosity, which really isn’t anyone’s bottleneck—people over-index on minimizing localized boilerplate and ignore the costs of gratuitous abstraction.
- karmakaze 4y ago
  Type-inference is a zero-cost 'abstraction' and any place you choose can make explicit narrowing of them. The libraries I needed to make a web application didn't have any mind-bending patterns, but rather did the most obvious things with the basic language features.

nu11ptr 4y ago

> so.. Haskell and Scala? Those would be the top two that come to mind for me when someone says "highly 'logical' and 'compose well'", "having sum types", 'more expressive', etc. I wrote Scala for years - it might be a bit too complicated but overall pretty decent, but I hear good things about Scala 3. I think the ML's, of which it takes inspiration from, are probably a better match. OCaml (EDIT: or F# as another comment mentioned) for instance is a pretty nice balance. Haskell is very nice and I think qualifies except that it is pretty hard core purely functional with no punches pulled (unlike ML), so is foreign enough for most people not to be deemed a candidate. I like Rust probably best atm as it is "imperative but with a functional flair", but doesn't qualify as easy I don't think, but is definitely highly logical and composes very well (even if obviously not finished yet). > I've heard they're great languages (haven't used them much myself), but I probably wouldn't choose them for say an early-stage startup. Go's value is in being a mundane, repetitive, boring language. It makes it easy for any random kid to dive into an existing code base and become productive, that can be super valuable. I would probably agree on the novice programmer and picking up Go quickly which is arguably the prime feature of Go. I just question the quality of that code, and honestly, don't feel Go is nearly as easy as touted. It is simple for sure, but not always easy. I always had to look up simple things like those magic comment compiler directives and is that interface{} param a pointer or a pointer to a pointer? I just remember the lack of expressiveness actually causing real world confusion (for me at least). > There's a gradient of programming languages where one side is "has a single expression for exactly your problem, a single unique expression you've never heard of exists to solve every possible problem" and the other is "requires thousands of expressions to express your problem, but only a thousand are available" - or something like that. While true, I would argue we have found a small amount of constructs that fit well 80% of the time, and is demonstrability better than half the constructs that fit well 40% of the time. Trying to solve every problem with a new construct is not worth it, but nor is the opposite extreme IMO. > My point? There's no perfect language, yet people are always trying to find one. It's OK if you don't like Go and prefer another language. A real devil / tradeoff is the prohibition of using languages that do not conform with past (company) choices. Honestly not sure we've found the ideal language yet, and agree there is subjectivity and trade offs at about every turn. In fact, the only thing I'm certain of is that Go missed what I would look for in just about every category except a few (but I agree it is easy to learn, but does it matter if you can't write good code with it?). That said, very intelligent and respected people disagree with me, so to each their own.

foolfoolz 4y ago

> It makes it easy for any random kid to dive into an existing code base and become productive, that can be super valuable professional developers are rarely “kids”

typesanitizer 4y ago

> There's no perfect language, yet people are always trying to find one. It's OK if you don't like Go and prefer another language, the real devil / tradeoff is in the fact that conformance to a single language (or set of languages) is such a strong social phenomena. I think that's why people end up so angry with viewed-as-subpar languages like Go gaining so much traction I hope my post didn't come across this way. To be clear, I think Rust and Swift (as two examples that I mention multiple times) have a lot of problems (slow compilation being a very big one), and are by no means perfect. I'm not angry at Go's popularity as much as wanting improvements to the developer experience.

uncomputation 4y ago

> I'm positive linguists aren't happy with English becoming the global language either Nit: Linguists do not hold prescriptive opinions about the "quality" of languages. They analyze languages to form descriptive theories about the structures and features of certain languages. I only nitpick this because, while having a lingua franca is certainly valuable and there is nothing "bad" about English any more than literally any other language, the closest thing to this in programming "languages"/notations is actually C, not Go. It's hard to overstate the invisible influence on C on basically every mainstream language and how we think of programming and computers in general. An interesting analogue to your example of English is the varying efforts to transliterate most languages into using the Latin alphabet, much like how many programming languages today need/greatly benefit from a compatibility layer with a C compiler/the C standard library.

erik_seaberg 4y ago

> mundane, repetitive, boring language These apply just as well to assembly, yet they are the reasons almost nobody tries to use it.

astrange 4y ago

> so.. Haskell and Scala? Those would be the top two that come to mind for me when someone says "highly 'logical' and 'compose well'", "having sum types", 'more expressive', etc. I don't think Haskell composes that well; monads don't combine well (not that I could do better) since you can only stick them together in an ordered way, the lazy evaluation makes it complicated to see how your program will run by reading the code, and so on. Btw, "sum types" means enums; it's not actually a super-complicated Haskell only feature.

kaba0 4y ago
Do you write imperative programs that execute statements — out of order? Ordering is precisely the point of monads, since they are monoids as well. And sum types are most definitely not enums, though Rust’s enums do use a bit strange terminology here.
- astrange 4y ago
  > Do you write imperative programs that execute statements — out of order? Ordering is precisely the point of monads, since they are monoids as well. Sure do. After all, your superscalar CPU executes things out of order, and C is a pure functional language in the memory monad. http://conal.net/blog/posts/the-c-language-is-purely-functional http://conal.net/blog/posts/the-c-language-is-purely-functio... > And sum types are most definitely not enums, though Rust’s enums do use a bit strange terminology here. Swift's enums too. But sure, in C it's an enum with a union at the end.
  - kaba0 4y ago
    Well, being pedantic, sure almost every modern CPU uses OOE. But they must do so with the huge caveat that from the outside it should be equivalent to executing it in serial (notwithstanding CPU vulnerabilities). But this is an implementation detail only, we could just as well use an older CPU design.