[throwaway132417]

Yes, (and so is OCaml) but less than in the past, mostly for specialized and older projets. Most engineers at Meta will not encounter these languages. It's costly to integrate them with the internal tools and arguably not worth the effort. On the other hand, Rust is increasingly popular and well-supported and approved by the company.

[wyager]

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".

[kccqzy]

You aren't hiring good programmers if they are intimidated by syntax.

[nicoburns]

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.

[kccqzy]

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.

[dataflow]

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.

[lovich]

You’re on hacker news so Occam’s razor would pick the simplest explanation is which the latter

[perching_aix]

> I do not hire anything

Today's Freudian slip award goes to...

[revskill]

You do not need too much good programmers.

[hamandcheese]

I've encountered many otherwise solid engineers who are intimidated and/or put off by Nix (the language).

[IshKebab]

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.

[hamandcheese]

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.

[IshKebab]

> 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.

[instig007]

you're not solid, by what you've just written here and in above threads.

[IshKebab]

Care to point out something specific?

[dartos]

Nix is really weird and ugly tbf.

It’s great at being a declarative configuration language though…. Even if it’s ugly.

[wyager]

I agree, but most programmers unfortunately are not good, so this is the reality we must deal with