5 ms·

The post was written in 2017. How far along was the project in 2017. Also, I am a bit confused about the gatekeeping implied here (it's not a serious language

The post was written in 2017. How far along was the project in 2017. Also, I am a bit confused about the gatekeeping implied here (it's not a serious language because it's not used to build an operating system) is really toxic.? Which line in the e-mail stated that?

jcranmer 6y ago
The gatekeeping is strongly implied by this statement: > As a general trend the only things being written in these new languages are new web-facing applications, quite often proprietory or customized to narrow roles. Not Unix parts. Which I read in the tone of "go play with your toy language somewhere else, and let the real programmers program with real languages. Additionally, there's the allusions to the fact that the ls/grep-replacements in Haskell aren't POSIX-compliant, which I again read in the tone of "they can't be taken as serious replacement efforts."
- protomyth 6y ago
  That tone seems more you than Theo. OpenBSD isn't known as a first mover operating system for new technologies. If the utilities are rewritten and not compatible then it really isn't a rewrite, its a new program with the same name as a previous program. Frankly, if they don't implement that standard, they aren't serious replacement efforts. They could be useful and maybe the options omitted aren't important to the person implementing it, but they are not suitable to replace the current utilities.
- rootlocus 6y ago
  > As a general trend the only things being written in these new languages are new web-facing applications, quite often proprietory or customized to narrow roles. Not Unix parts. That doesn't imply "real programmers program with real languages". It implies they're not used to enrich the UNIX / open source ecosystem, which might imply there's not a real need for them in the official repositories, since they're not used to build anything else in the repository. > Additionally, there's the allusions to the fact that the ls/grep-replacements in Haskell aren't POSIX-compliant, which I again read in the tone of "they can't be taken as serious replacement efforts." There is real value in being "POSIX-compliant". It means programs respect an interface. If I write a script that uses "grep" or "find", I have strict requirements from them. I expect them to take certain arguments and interpret them in a certain way. If I can't simply replace "grep" with "haskell-grep" and get the same results (with stronger safety guarantees or performance), I may not have a use for them in certain scenarios. The critique that "They are completely different programs that have borrowed the names." doesn't imply "they can't be taken serious", it implies they can't be used to replace the existing ones.
- jerf 6y ago
  There is gatekeeping here... but it's not implied, it active and out in front. The entire conversation here is whether Rust code is going to be permitted through the gate of the OpenBSD base system. You don't have to parse through implications to find the gatekeeping, it's the topic of the conversation.

jcranmer 6y ago

The gatekeeping is strongly implied by this statement: > As a general trend the only things being written in these new languages are new web-facing applications, quite often proprietory or customized to narrow roles. Not Unix parts. Which I read in the tone of "go play with your toy language somewhere else, and let the real programmers program with real languages. Additionally, there's the allusions to the fact that the ls/grep-replacements in Haskell aren't POSIX-compliant, which I again read in the tone of "they can't be taken as serious replacement efforts."

protomyth 6y ago
That tone seems more you than Theo. OpenBSD isn't known as a first mover operating system for new technologies. If the utilities are rewritten and not compatible then it really isn't a rewrite, its a new program with the same name as a previous program. Frankly, if they don't implement that standard, they aren't serious replacement efforts. They could be useful and maybe the options omitted aren't important to the person implementing it, but they are not suitable to replace the current utilities.
rootlocus 6y ago
> As a general trend the only things being written in these new languages are new web-facing applications, quite often proprietory or customized to narrow roles. Not Unix parts. That doesn't imply "real programmers program with real languages". It implies they're not used to enrich the UNIX / open source ecosystem, which might imply there's not a real need for them in the official repositories, since they're not used to build anything else in the repository. > Additionally, there's the allusions to the fact that the ls/grep-replacements in Haskell aren't POSIX-compliant, which I again read in the tone of "they can't be taken as serious replacement efforts." There is real value in being "POSIX-compliant". It means programs respect an interface. If I write a script that uses "grep" or "find", I have strict requirements from them. I expect them to take certain arguments and interpret them in a certain way. If I can't simply replace "grep" with "haskell-grep" and get the same results (with stronger safety guarantees or performance), I may not have a use for them in certain scenarios. The critique that "They are completely different programs that have borrowed the names." doesn't imply "they can't be taken serious", it implies they can't be used to replace the existing ones.
jerf 6y ago
There is gatekeeping here... but it's not implied, it active and out in front. The entire conversation here is whether Rust code is going to be permitted through the gate of the OpenBSD base system. You don't have to parse through implications to find the gatekeeping, it's the topic of the conversation.