No doubt it’ll be an open source app you’ll be able to recompile for your non Android/iOS computers. Otherwise I really hope to government gifts me an ID computer.
Another great example of the HN mindset. How can you say "their safety layer clearly failed" without being able to acknowledge that they should be held responsible for that failure and that we should work to reduce the likelihood of similar failures in the future? If a car, rope, or drill had some sort of failure in their manufacturing that killed people, those companies would be held responsible. Why can't we do the same with OpenAI?
This isn't a desire for "the digital world to be devoid of risks", it is a desire for people and companies in the digital world to be held responsible for the harm they are causing. Yet, people here seem to believe that no one should ever be held responsible for the damage caused by the software they create.
I remember doing that for some custom installer I wrote. It felt like a good idea for 5mins until it got flagged by a bunch of anti virus software… had to sign the installer in the end and spent a lot of time reporting false positives.
I’m surprised it’s that big to be honest. I was expecting it to be smaller or half the size to be taken by some app icon. I remember writing this kind of stuff back in the days and it was smaller.
> The video stream is encoded as one single JPEG2000 picture per frame. Each frame is encrypted with the same static AES key.
Is this not a problem? It’s not a good idea to reuse the same key to encrypt very similar files. Similar to ECB. See the famous penguin https://words.filippo.io/the-ecb-penguin/
I’m surprised they don’t use something like XTS commonly used for disk encryption. It derives a unique key for each block/frame and allow you to access each individual blocks/frames non sequentially.
> Every Frame is using a unique IV (Initialization Vector), which ensures that the AES Block Cipher generates always different cipher texts and makes brute force harder. This works similar to a Password Salt.
Checking for errors after every line (like in Go) is the worst. Used to do that in c/c++ calling win32 APIs. Know what happened when sloppy developers come along? They don’t bother checking and you have really bizarre impossible to debug problems because things fail in mysterious ways. At least with an exception if you “forget” to catch it blows up in your face and it’ll be obvious
Sure monads are cool and I’d be tempted to use them. They make it impossible for forget to check for errors and if you don’t care you can panic.
But JS is not Rust. And the default is obviously to use exceptions.
You’ll have to rewrap every API under the moon. So for Monads in JS to make sense you need a lot of weird code that’s awkward to write with exceptions to justify the costs.
I’m not sure the example of doing a retry in the API is “enough” to justify the cost. Also in the example, I’m not sure you should retry. Retries can be dangerous especially if you pile them on top of other retries: https://devblogs.microsoft.com/oldnewthing/20051107-20/?p=33...
Monadic style or not, the `if err != nil return err` pattern destroys critical information for debugging. `try/catch` gives you a complete stacktrace. That stacktrace is often more valuable than the error message itself.
> the `if err != nil return err` pattern destroys critical information for debugging.
Funny enough, your code looks like it is inspired by Go, and Go experimented with adding stack traces automatically. Upon inspecting real-world usage, they discovered that nobody ever used the stack traces, and came to learn that good errors already contains everything you'd want to know, making stack traces redundant.
Whether or not you think the made the right choice, it is refreshing that the Go project applies the scientific method before making a choice. The cool part is that replication is the most important piece of the scientific method, so anyone who does think they got it wrong can demonstrate it!
I code Go professionally. I like the language. However, I vehemently disagree with the stance that error messages > stack traces. Error messages are in no way as helpful as stack traces. Ideally, you'd have both.
The scientific method doesn't care about your feelings, but it does care about your replication efforts. Under what circumstances did your research found stack traces to be necessary?
The idea that you need to run a study to criticize a design decision is stupid. A stack trace is ground truth, natural language is interpretative. The implications are plain to see.
> The idea that you need to run a study to criticize a design decision is stupid.
Not at all. Fundamentally, you do need understanding in order to criticize. "Criticizing" without understanding is merely whining. If your intent is to whine, you are certainly welcome to until your heart's content, but it will be fruitless. Without you having an understanding – and being able to articulate it – progress cannot be made. This should be obvious.
> A stack trace is ground truth
But a costly truth. Even languages that do pass around stack traces are careful to avoid them except under special circumstances, which is kind of nonsensical from a theoretical point of view. If you find them to be useful, you'd find them useful in all cases. However, it is a necessary tradeoff for the sake of computing efficiency.
With a few small changes to your codebase you can restore the automatic attachment of stack traces like the original experiments had. Stack traces are made available for you to use! But, it remains that the research showed that the typical application didn't ever use it, so it wasn't a sensible default to include given the cost of inclusion. "But, but I wish it were!" doesn't change reality like you seem to think it does.
You come off extremely rude, and for someone so enamored with the scientific method you make a lot of baseless assumptions about what I think and understand.
Understanding comes from all kinds of places. When a child touches a hot stove, they come to understand the consequences. That child doesn't gather 30 participants and record their reactions as they take turns burning their fingers. I'll leave you to extrapolate.
How I come across has no bearing on what is said. This is irrelevant and a pointless distraction.
> Understanding comes from all kinds of places.
If you have an understanding then you've studied it. All that is lacking, then, is the communication of what is understood. Strangely, after several comments, still crickets on the only thing that would add value to the discussion...
This is the arrogance of language designers with limited experience developing real-world applications. Maybe it works as a replacement for C building low level apps, but it won't fly in enterprise codebases.
Go recognizes the arrogance of language designers (Pike is a team member, so it was hard for such a thing to go unnoticed!), hence why they put their theories to the real-world test instead of just guessing. Most languages seem to pack in feature after feature because some random nobody on the internet thought it would be a good idea without ever seeing if their thought could be proven as a good one, but Go tries to actually show it first.
Which is also why it draws so much ire. It speaks the truths developers don't like to admit.
"Enterprise" being a euphemism for low-quality developers who don't know how to write quality software (the sloppy developers referenced in an earlier comment)? Perhaps not. Go does seem to scare off anyone who relies on crutches to work around shoddy work and inability.
But it doesn't really matter which codebases they used, does it? Replication efforts will reveal anything they got wrong. No need to make guesses.
I have written, and continue to write at another org, Go that drives line of business software that makes billions of dollars and runs the real world. Check a random email you have and if you see a header X-EID, it was processed with Go.
Individual codebases can already include stack traces as they see fit, so studying only a single codebase would be rather pointless. If an individual codebase benefits from stack traces, it will use them! The study looked at how often they were used to determine if it would be a useful default. It found, by looking at many different projects that had stack traces included by default, that it would not be useful to include by default. Especially in light of the cost of inclusion. Adding stack traces is definitely not free.
"Enterprise" traditionally refers to code that is full of bad practices. Like, when Java was all the rage, FooFactoryBuilderFactory was the embolism of enterprise. In other words, where sloppy developers are found. Glad we were able to clear up that isn't what you meant.
So you are meaning – with respect to the code – the same as all other software? What, then, is "enterprise" trying to add? It is not like you would write code that makes billions any differently than you would a code that makes a dollar.
An advantage to the Monad approach is that it sugars to the try/catch approach and vice-versa (try/catch desugars to monads). JS Promises are also already "Either<reject, resolve>". In an async function you are writing try/catch, but it desugars to monadic code. You could write an alternative to a library like "neverthrow" that just wraps everything in a Promise and get free desugaring from the async and await keywords (including boundary conditions like auto-wrapping synchronous methods that throw into Promise rejections). You could similarly write everything by hand monadically/pseudo-monadically directly with `return Promise.reject(new Error())` and `return Promise.resolve(returnValue)` and everything just works with a lot of existing code and devs are quite familiar with Promise returns.
It might be nice for JS to have a more generic sounding/seeming "do-notation"/"computation expression" language than async/await, but it is pretty powerful as-is, and kind of interesting seeing people talk about writing Monadic JS error handling and ignoring the "built-in" one that now exists.
This is also where I see it as a false dichotomy between Monads and try/catch. One is already a projection of the other in existing languages today (JS Promise, C# Task, Python Future/Task sometimes), and that's probably only going to get deeper and in more languages. (It's also why I think Go being intentionally "anti-Monadic" feels like such a throwback to bad older languages.)
Moving from try:catch to errors as values was so refreshing. Same company, same developers, but suddenly people were actually _thinking_ of their errors. Proper debugging details and structured logging became default.
I assert that try:catch encourages lazy error handling leading to a worse debugging experience and longer mean time to problem discovery.
RIPA notices do indeed assume you’re in possession of the keys of anything encrypted and you must disclose when asked nicely.
You just need an airtight provable way of showing you have a way to destroy that key when you push a button and do that before the notice arrive. I suspect that’s after they seize your stuff.
Could not agree more! I have 20+ years experience and use Cursor/Sonnet daily. It saves huge amounts of time.
But I can’t imagine this tool in the hands of someone who does not have a solid understanding of programming.
You need to understand when to push back and why. It’s like doing mini code reviews all the time. LLMs are very convincing and will happily generate garbage with the utmost authority.
