4 ms·

Regardless of the language, if it had a closed source runtime interpreter and/or VM that you forbade you from performing various sequences of operations on hard

Regardless of the language, if it had a closed source runtime interpreter and/or VM that you forbade you from performing various sequences of operations on hardware that you "own", actively fought against you seeing what it was doing, etc - then you would no more be able to "trust" it than back-doored cryptography. (I'm getting sleeping, so that may sound wrong. Though it's been a popular troll/advocacy touch point since at least the mid 90s, so there should be plenty of resources out there if your are more curious. ie FSF for starters.)

DannoHung 11y ago
That is not what either Rust or Haskell are. It would behoove you to have a passing familiarity with what someone says before responding to them combatively
- eru 11y ago
  Thanks! > That is not what either Rust or Haskell are. Nor even Python.
eru 11y ago
I assume you are sleepy. What I am talking about is that some languages make writing safe code easier, that is code that behaves well as a program when compiled to machine language (or interpreted as is). Especially in the face of hostile inputs. As an example, it is pretty hard to make your Python interpreter crash with a segfault using just pure Python code. (It is, of course, easy to generate a Python exception.) Even though, this safety doesn't come at the expense of power: it is easy to tell the interpreter to get out of the way and let you muck around with raw bytes (ie by calling into C). In the case of Python, the safety-by-default comes at the expense of performance. In the case of Haskell, it is either performance or program complexity. (Ie you can write fast Haskell code, but it looks weird.) If you do call into something low level, it will be clearly visibly in your code that something potentially dangerous is going on. Safe and correct behaviour by default is good. Profiling can help you find the few spots where you want to take over safety obligations from the automatic systems in return for extra performance.

DannoHung 11y ago

That is not what either Rust or Haskell are. It would behoove you to have a passing familiarity with what someone says before responding to them combatively

eru 11y ago
Thanks! > That is not what either Rust or Haskell are. Nor even Python.

eru 11y ago

I assume you are sleepy. What I am talking about is that some languages make writing safe code easier, that is code that behaves well as a program when compiled to machine language (or interpreted as is). Especially in the face of hostile inputs. As an example, it is pretty hard to make your Python interpreter crash with a segfault using just pure Python code. (It is, of course, easy to generate a Python exception.) Even though, this safety doesn't come at the expense of power: it is easy to tell the interpreter to get out of the way and let you muck around with raw bytes (ie by calling into C). In the case of Python, the safety-by-default comes at the expense of performance. In the case of Haskell, it is either performance or program complexity. (Ie you can write fast Haskell code, but it looks weird.) If you do call into something low level, it will be clearly visibly in your code that something potentially dangerous is going on. Safe and correct behaviour by default is good. Profiling can help you find the few spots where you want to take over safety obligations from the automatic systems in return for extra performance.