Feedback about an experiment to embed Python interpreter with FFI API

[Maxim Karpov]

You are directing the inconvenience to a wrong place and wrong people. 
And comparison with Rust
is not a valid comparison exactly for that reason.

When you want to write unsafe code in Rust, you must explicitly enable 
it _in source file_.
When you want to use unsafe native code in Java, you must explicitly 
enable it _every
time you deploy code with it_. This makes a HUGE difference, because 
former affects only
source file with unsafe code (and creates inconvenience for library 
authors), and latter
affects ALL transitive uses of library (and creates inconvenience for 
everyone).

If tomorrow, say, Google will release library which uses unsafe native, 
all USERS will have
enable flag to allow the library to work. The fact that Google did 
extensive testing and library
is production ready will not matter - every USER of that library will be 
pushed to enable strange
feature flags just because.

And it will transitively affect anyone who will use that library. 
Everyone will have to change
their deployment files just because.

Creating extra inconvenience for USERS does not relates to safety at 
all. I'm completely fine
if unsafe features are guarded with SOURCE CODE feature flags, just to 
mark them explicitly in
source code. But not with command-line arguments or other means that 
break library encapsulation.
For example, Scala works this way - to use advanced features you have to 
import something like
`scala.language.experimental.macros`.

28.12.2021 14:11, Pedro Lamarão wriites:
> Em ter., 28 de dez. de 2021 às 09:07, Maxim Karpov <me at m-k.mx> escreveu:
>
>     Malicious (or poorly written) program or application can do much
>     more to
>     crash the JVM or whole OS. Throwing an Error without a stack
>     trace, calling
>     System.exit or just doing `rm -rf /` or `rm -rf ${HOME}`, just to
>     name a
>     few. So, what else should we expect? --enable-system-exit?
>     --enable-file-io?
>     --enable-process-builder? --enable-override-stack-trace?
>
>
> Yes, please!
> It is easy enough for application provider's to prepare launch scripts 
> with everything necessary to run.
> The inconvenience is not imposed on the user of the application but 
> the user of the programming environment.
> To alleviate this person from the inconvenience of explicitly enabling 
> unsafety leads to the effective negation of the protections.
> Example: https://www.infoq.com/news/2021/11/rudra-rust-safety/
>
> -- 
> Pedro Lamarão