I think one of the most promising pitches for rust adoption is that it borrowed as much as possible from Haskell/ML without treading into the territory where it becomes "scary" for broadly-C-family language monoglots. A C++ or even Java programmer can look at Rust and think to themselves "this text has a comfortably familiar shape".
The differences between Haskell/OCaml and C-family languages are much more significant than syntax. Rust brings a lot (but not all) of the richness of these languages while staying within a broadly imperative paradigm.
That's neither my point nor OP's point. The soothing feeling of "this text has a comfortably familiar shape" is entirely about syntax, and indeed is only a soothing feeling because such programmer has not seen anything beyond it and is unwilling to get outside that comfort zone.
I do not hire anything who does not get outside of their comfort zone or who is intimated by syntax they haven't seen. If a programmer rejects Haskell or OCaml by giving me a good critique of say, Hindley Milner style type systems†, that's a good programmer I'm willing to hire even though I don't necessarily agree.
†: I've been asked exactly this question during an interview: to critique HM style type systems. As a candidate I felt this style of questions gave me a far better way to display my knowledge and experience than Leetcode style questions.
Do you put any weight on any factors beside the technical capabilities of the tools you're working with? Like, say, how easy they are to pick up or use, etc.?
The way your comment reads, it's like you're saying you'll never hire someone who rejects speaking to you in Esperanto unless they offer a good critique of its grammar.
I count myself among them. And I wouldn't say I am "otherwise solid". I am solid. Nix is just a weird custom footgun-laden language in a place where I don't want to have to learn a weird custom footgun-laden language. It has other serious issues too, like the fact that it is declarative makes discoverability extreeemely difficult. What does setting `foo: true` do? You can't go-to-definition on it. You can only hope it is well documented (it isn't) or try to find the place that reads that key ... somewhere... in all of Nix... Good luck.
Hell even if it were a perfectly designed language (it isn't) I still would be put off by it because I don't really want to be a professional full-time packaging engineer.
I think Bazel got a lot right by using a subset of Python. Basically nothing to learn language-wise.
This shallow dismissal pretty much proves OPs point.
For starters, you compared Nix the ecosystem to Starlark, perhaps the smallest aspect of Bazel. But Bazel (the ecosystem) has a horrendous documentation problem as well.
I grant that "Nix" is a very overloaded term, but it seems like you don't know which part of Nix you are even referring to. "Somewhere... in all of Nix" is not something that makes any sense.
I fully admit that Nix has a steep learning curve. Very steep. But I don't think you know enough to give a thoughtful critique.
> For starters, you compared Nix the ecosystem to Starlark
No I compared the Nix language to Starlark.
> but it seems like you don't know which part of Nix you are even referring to.
Incorrect. I was referring to the Nix language, as was hamandcheese. He literally said it explicitly. I don't know how you could miss that.
> I fully admit that Nix has a steep learning curve. Very steep. But I don't think you know enough to give a thoughtful critique.
You're proving my point here. The very steep learning curve and "you need to be an expert before you can use it" aspects of Nix (both the language and the package manager) are exactly the problem.
Let me put it another way. Imagine I gave you a vacuum cleaner, and you tried to turn it on but it had a very complicated startup sequence so you needed to read the manual... but the manual was written in Egyptian hieroglyphics. You take it back to the shop and they say "nah this is a perfectly good vacuum cleaner. Sure it has a steep learning curve but you just need to spend some time learning it before you can criticise it".
That's obviously stupid right? For most people package management is like vacuum cleaning. It's a necessary task they want to think about as little as possible.
Nix is written by a vacuum cleaner collection & restoration club, who assume that everyone in the world is as obsessively into vacuum cleaners as them.
> Incorrect. I was referring to the Nix language, as was hamandcheese.
I am hamandcheese. I replied to your comment. You didn't describe a single aspect of Nix-the-language. You wrote this:
> What does setting `foo: true` do? You can't go-to-definition on it. You can only hope it is well documented (it isn't) or try to find the place that reads that key ... somewhere... in all of Nix... Good luck.
It's appears (despite the wrong syntax, another clue that you are not particularly well informed) that you are referring to a NixOS module option. Or maybe a Home Manager module option. Either way, not a language feature.
The language feature I am talking about is that it is completely declarative. You can argue semantics if you want but Nix chose to use a completely declarative language for configuration and that was IMO a bad decision.
The fact that you say that haskell has operators and that you look for a distinction in syntax for functions and reduced values in the expression-driven language would be enough to say that you opine too strongly about things you don't have a solid understanding of. The same applies to your critique of Nix. If you ever tried recursive overrides of declarative definitions in, as you recommended, a subset of Python, you'd never claim that Nix is a footgun-laden language.
> The fact that you say that haskell has operators
Oh you mean the things that look like operator, behave like operators, and are commonly referred to as operators by Haskell programmers - even in the Haskell Wiki? Those operators?
You're a prime example of a person who reads a page on the Internet and takes it at a face value without understanding the meaning and the context behind the words:
> One of the most common operators, and source of initial confusion, is the $ operator. All this does is apply a function.
Did you miss the part that says "All this does is apply a function"?
whereas (+#) is defined as a bridge from unboxed ints provided by the runtime to their efficient low-level machine representation, accomodating all instances of a data type defined as `Int = I# Int#` (the left-hand side is the name of the type, the right-hand side is the name of a constructor that accepts a single value of type Int# - the low-level primitive provided by the GHC implementation).
The (+) in `I# x + I# y =` is a function definition in infix form. That's the same form you can use for any other infix function if you wish so:
ghci> a `iAmHelping` b = a b + b
ghci> :t iAmHelping
iAmHelping :: Num a => (a -> a) -> a -> a
> Oh you mean the things that look like operator, behave like operators
Let me see your regular operators do the following, then we talk:
plus = (+)
a = (2 +)
c = (2 `plus`)
c' = plus 2
d = (+) 2
d' = (+ 2)
e = 2 `plus` 2
f = 2 + 2
I'm glad that's the only thing you object to, though.
Ahah, if someone calls an infix function an operator it must be it, right? Do you also believe that Haskell functions return values because random articles on the Internet say that the functions return values via `return` "keyword"? Years of catering the invalid (but "familiar") terminology to outsiders so that they can land into the language must've done their job.
> I guess you're a prime example of someone that can't remember what the debate is.
There's no debate, you asked me why I said that you weren't solid. And I show you that you don't have a solid foundation in the tool that you opine on. You refuse the ground truth presented to you in code, and you opt to someone's verbal description of an infix function being an operator. You use a second-hand opinion to form your mental model about a thing, and then you opine on the thing with that invalid foundation that was made for you (by some believing individuals claiming it's the best approach), so that you don't feel intimidated from the get-go. No wonder you don't know why there's no distinctive difference between functions and reduced values in syntax. And that's not only Haskell, you also don't know Nix enough to understand how silly your take is about a subset of Python being better than a specialized language for the problem of cascading graph changes in build systems.
Wikipedia keyword search is the last resort of a mediocre engineer, thanks for confirming my words.
> Good to know you didn't have any real reasons to think I'm not a solid programmer anyway.
I'd easily demonstrate more reasons why you're not solid, I will probably do it in the future if I see more of your silly opinions on the things you don't know. But thankfully, in the context of Haskell the comments have already shown your true lack of any substantial knowledge. I hope you will at least obstain from commenting on Haskell and Nix in the future, don't embarrass yourself.
You are giving an extremely unfavourable impression of the Haskell community. If you care about the Haskell community, please stop interacting with people like this.
I don't care about Haskell community. If you've got anything to object to regarding my rebuttal of the OP's claims about Haskell and/or Nix (that are completely untrue and misleading), please state them instead of assuming that I speak on behalf of any community. I'm calling out someone's incompetence here, if you don't like it, that's on you.
You're right: I don't like it. It's on me? OK, fine by me. I'm glad if you're saying you don't believe your behaviour reflects on the Haskell community, and I hope everyone reading this thread takes that to heart. In my opinion this kind of superior, petty attitude is not welcome in the Haskell community.
