Earlier quoted context omitted.
One doesn't need to spawn a shell.
Injecting and executing code inside an unprivileged process is not very useful.
Microsoft is creating a new Rust-based programming language for secure coding
201–207 of 207 posts
Re: Microsoft is creating a new Rust-based programming language for secure coding
#202I'm surprised Microsoft didn't "invent" their own version of Go yet. Actually I'd use it in a heartbeat over Google's if they add generics to it. Just call it "Micro".
This so much! Go would be a great language if it had generics and no "interface {}". I'd use that over any flavor of Rust any day.
Re: Microsoft is creating a new Rust-based programming language for secure coding
#203Earlier quoted context omitted.
> a typesystem that can be entirely coded in the language itself The closest thing to this I can think of is Racket. It's supposedly powerful enough to embed Haskell in it https://lexi-lambda.github.io/hackett/
I would imagine something closer to rust in terms of base and then being able to put Haskell on top without loosing any safety guarantees. Or possibly even allowing an arbitrary type system as long as you can prove it's sound with the guarantees of the language.
Re: Microsoft is creating a new Rust-based programming language for secure coding
#204Earlier quoted context omitted.
I believe the next evolution will be to combine Rust and Lisp; a programming language as flexible as LISP without giving up the safety of Rust, including a typesystem that can be entirely coded in the language itself, safely.
> a typesystem that can be entirely coded in the language itself The closest thing to this I can think of is Racket. It's supposedly powerful enough to embed Haskell in it https://lexi-lambda.github.io/hackett/
Racket is special because its designers provide dedicated support of language-oriented programming. But that is about ecosystems, not typesystems.
Re: Microsoft is creating a new Rust-based programming language for secure coding
#205Earlier quoted context omitted.
I would imagine something closer to rust in terms of base and then being able to put Haskell on top without loosing any safety guarantees. Or possibly even allowing an arbitrary type system as long as you can prove it's sound with the guarantees of the language.
Types are closed terms of contracts encoded in a language within specific phases. If you really need any guarantees without further knowledge shaped before running, then, besides the typechecking, the typing rules should also be programmable by users (rather than the language designer) for the sake of providing proofs. The base system must practically have no mandated static type systems at all, which is far from Rus…
Re: Microsoft is creating a new Rust-based programming language for secure coding
#206Earlier quoted context omitted.
“Fool me once, shame on you. Fool me twice, shame on me” I try to be objective as much as possible, but having witnessed almost all of Microsoft’s behavior through history, we have been fooled 100s if not 1000s of times. How many times do you let the fox back into the hen house? The only thing I think when I read recent “Microsoft is so great” comments is that the person is either too young to have any real knowledge…
Name me any other big company with great ethics and all nice and fluffy. For example look at how Google had started and what it has become. Not really trying to protect Microsoft here but them companies are all the same, just different degree of "success".
Thanks goodness for Linux and the web (and later mobile computing which MS failed to dominate) to pull us away from the brink of an MS monoculture.
Re: Microsoft is creating a new Rust-based programming language for secure coding
#207Earlier quoted context omitted.
They could have ported ocaml to the clr instead of doing their own ms thing. They could have promoted ocaml instead of splitting the community interested in a practical ml derived language - with the consequence that today neither has a relevant user base.
And they did initially, but OCaml.NET had its own set of issues regarding interoperability with .NET code.