3 ms·

1. Some modern PLs and frameworks are making ffi easier, without requiring writing manual wrappers, or using a code generators. I can't recall project names now

1. Some modern PLs and frameworks are making ffi easier, without requiring writing manual wrappers, or using a code generators. I can't recall project names now, but they do exist. But yes, they're not widely used or supported. 2. BEAM (Erlang VM) has several native mechanisms to communicate with the outside world (both in-process and out-of-process). In-process ones: linked-in drivers (.so/DLL), NIFs (.so/DLL, like JNI), dirty schedulers. Out-of-process: ports (external executables), C-Nodes/JInterface (an Erlang cluster node interface can be written in any programming language, not just C or Java). See [1]. 3. Morphing into a Single Image System OS would be ideal evolution for the cloud vendors. I don't think Mainframe or Heroku-style PaaS are good directions, though. I have many ideas in this field, but they need to be fleshed out first. -- [1] https://www.slideshare.net/nivertech/erlang-on-osv-49278675#64 https://www.slideshare.net/nivertech/erlang-on-osv-49278675#...

viksit 5y ago
Do elaborate on (3)?
- nivertech 5y ago
  1. The first step would be to simplify and unify services. It's especially relevant to AWS, which has lots of overlapping services, built by independent teams. Just look on this flowchat ("Which AWS container service should I use?"): https://twitter.com/forrestbrazeal/status/1400639759215640577 https://twitter.com/forrestbrazeal/status/140063975921564057... 2. The longer term solution would be something like DarkLang, "deployless" single image system development environment. Of-course it will be opinionated. It should include all best practices by default. I.e. think 128-factor, instead of Heroku's 12-factor. 3. Another direction is cloud-native or web-services oriented programming languages.
rzzzt 5y ago
JNA looks reasonable for accessing native code from Java: https://github.com/java-native-access/jna/blob/master/www/GettingStarted.md https://github.com/java-native-access/jna/blob/master/www/Ge...
jandrewrogers 5y ago
I’ve written software for a few different Single System Image systems. They are uniformly terrible in my experience because they actively hide material information about the system architecture that is critical for software performance and robustness. I wouldn’t recommend them at all — the “benefits” are greatly outweighed by the downsides in real operational environments. There is a reason they disappeared even though they were popular at one time. I thought they were a great idea until I actually used them. It is very difficult to write scalable high-performance software on those types of systems, so many edge cases.
- nivertech 5y ago
  There are two different things called Single System Image systems: 1. LISP machines, Smalltalk dev environments, etc. A modern example would be the DarkLang. 2. Distributed OS with process migration like MOSIX - https://en.wikipedia.org/wiki/Single_system_image https://en.wikipedia.org/wiki/Single_system_image The (1) are a good direction, but they're usually not distributed. I guess you're talking about (2) which was never properly implemented, or maybe they were problematic by design. BTW, what do you think about Inferno and Plan9? They still have hobbyist communities around them, and some of their ideas influenced current mainstream SW like 9P protocol and GoLang channels.

viksit 5y ago

Do elaborate on (3)?

nivertech 5y ago
1. The first step would be to simplify and unify services. It's especially relevant to AWS, which has lots of overlapping services, built by independent teams. Just look on this flowchat ("Which AWS container service should I use?"): https://twitter.com/forrestbrazeal/status/1400639759215640577 https://twitter.com/forrestbrazeal/status/140063975921564057... 2. The longer term solution would be something like DarkLang, "deployless" single image system development environment. Of-course it will be opinionated. It should include all best practices by default. I.e. think 128-factor, instead of Heroku's 12-factor. 3. Another direction is cloud-native or web-services oriented programming languages.

rzzzt 5y ago

JNA looks reasonable for accessing native code from Java: https://github.com/java-native-access/jna/blob/master/www/GettingStarted.md https://github.com/java-native-access/jna/blob/master/www/Ge...

jandrewrogers 5y ago

I’ve written software for a few different Single System Image systems. They are uniformly terrible in my experience because they actively hide material information about the system architecture that is critical for software performance and robustness. I wouldn’t recommend them at all — the “benefits” are greatly outweighed by the downsides in real operational environments. There is a reason they disappeared even though they were popular at one time. I thought they were a great idea until I actually used them. It is very difficult to write scalable high-performance software on those types of systems, so many edge cases.

nivertech 5y ago
There are two different things called Single System Image systems: 1. LISP machines, Smalltalk dev environments, etc. A modern example would be the DarkLang. 2. Distributed OS with process migration like MOSIX - https://en.wikipedia.org/wiki/Single_system_image https://en.wikipedia.org/wiki/Single_system_image The (1) are a good direction, but they're usually not distributed. I guess you're talking about (2) which was never properly implemented, or maybe they were problematic by design. BTW, what do you think about Inferno and Plan9? They still have hobbyist communities around them, and some of their ideas influenced current mainstream SW like 9P protocol and GoLang channels.