Haven't tried Reflux but I would recommend trying Redux before it. It is heavily inspired by Elm and has been very pleasant to work with. Reflux also bypasses the 'unidirectional data flow' part of Flux, which gives you added convenience for some things at the cost of more complexity.
Well this is pretty exciting. This opens up the door for PS4 games to be written in any language that uses LLVM as a backend, right? So in the future, PS4 games could be written in D, Rust, Ada, ActionScript...
Especially with the indie focus Sony has had, this could make it much much easier for people used to creating games with ActionScript to get their game on a console.
Is there something I'm missing? This seems too good.
Glad to see another language that has chosen to avoid NullPointerExceptions. Some of you might take issue with the way it is implemented (special syntax vs general type), but IMO it is still much better than having NPEs.
> Digressing, were there any discussions about using var like in Swift (instead of let mut)? What is the rationale for not making that more minimalistic?
I was interested in the answer to this too. I found these which helped me understand:
Here is a practical everyday example where languages that can represent emptiness in the type system come in handy.
He ends up using pointers and mentions: "Using pointers also means that clients of the library will need to perform their own nil checks where appropriate to prevent panics."
Ahh, now that makes sense, thanks! The HTML5Rocks article cleared up my concerns.
For anyone reading this later, it was the section starting with this paragraph:
Inline Code Considered Harmful
It should be clear that CSP is based on whitelisting origins, as that’s an unambiguous way of instructing the browser to treat specific sets of resources as acceptable and to reject the rest. Origin-based whitelisting doesn’t, however, solve the biggest threat posed by XSS attacks: inline script injection. If an attacker can inject a script tag that directly contains some malicious payload (<script>sendMyDataToEvilDotCom();</script>), the browser has no mechanism by which to distinguish it from a legitimate inline script tag. CSP solves this problem by banning inline script entirely: it’s the only way to be sure.
> How would you like to be largely invulnerable to XSS? No matter if someone managed to trick your server into writing <script>alert(1);</script>, have the browser straight up refuse it?
I don't quite get how this header makes you invulnerable to XSS, would someone mind explaining?
It seems like it only prevents XSS attacks from loading remote javascript files. What's to stop the attacker from just injecting the entire script inline? If you can get a small piece of javascript to execute you should be able to get a larger piece to execute just fine.
I can see how it makes XSS more inconvenient, but I don't understand how it makes you largely invulnerable to it.
I agree, it is! I did a light comparison[0] between a logic programming solution to sudoku (Prolog) and one using constraint programming (Scala + JaCoP). I thought Prolog was a little nicer because it was shorter and more declarative, but the JaCoP solution was still great compared to any non CP-solution.