571 karma · joined September 26, 2012
Then nVidia's moat begins to shrink because they need to offer their GPUs at a somewhat reduced price to try to keep their majority share.
UTF-32 would be a fair comparison, but it is 4 bytes per character and I don't know what, if anything, uses it.
And the flippant response from the parent here that they don't really care that they're muddying the waters and just want the crate name is irksome.
Netflix and Disney+ trained me to not even watch a show until it's concluded because it could get cancelled and I don't want to invest my small amount of free time on entertainment that might not even finish. It does produce a self-fulfilling prophecy where people with the same mindset as me on this do the same, and then the rating for something I (and probably they) are interested in aren't high enough and it gets cancelled.
What should worry them, though, is that it also led to the final step for them; I cancelled my Netflix and Disney+ subscriptions with no intention of renewing them around a year ago. The end result is that "TV series"-style shows are effectively dead to me; I've shifted my time on them mostly to novels (that are basically behind-the-curve on this trend, hopefully forever), followed by single-player video games, and finally movies. (Why didn't movies take the first slot? Because I'm only willing/able to give 30-60 minutes of continuous time to entertainment most of the time, and it's very unsatisfying to pause a movie to resume later.)
The continuous, immediate feedback on series performance coupled with a reputation of acting on that feedback immediately is killing the traditional television medium.
On top of all of that, Apple TV+ has the added albatross of requiring their hardware for the shows, as if they were somehow a siren song to get people more tightly nestled into their ecosystem, and therefore dooming their shows to failure, at least amongst people who don't want to pay for overpriced hardware running software of degrading quality over the years (I switched to Linux in 2016 because it was more reliable than my MacBook Air; being better than Windows isn't good enough anymore, especially when Linux has a greater catalog of software these days).
The needs of Apple, Inc weigh on their Apple TV division, they don't help it, and the sins of the streaming services against actually finishing a story further increase the trust deficit with Apple TV+. No amount of marketing is going to turn that around.
Btw, Python also has unsafe APIs[1, 2, 3, 4] so this doesn't even differentiate these two languages from each other. Some of them are directly related to memory safety, and you don't even get an `unsafe` block to warn you to tread lightly while you're using them. Perhaps we should elevate Rust above Java and Python because of that?
[1]: https://docs.python.org/3/library/gc.html#gc.get_referrers
[2]: https://docs.python.org/3/library/ctypes.html
You can absolutely opt-out of lifetime management in Rust. It's not usually talked about because you sacrifice performance to do it and many in the Rust community want to explicitly push Rust in the niches that C and C++ currently occupy, so to be competitive the developer does have to worry about lifetimes.
But that has absolutely nothing to do with Rust's safety, and the fact that Rust refuses to compile if you don't provide it a proper solution there means it's at least as safe as Python and Java on the memory front (really, it is more as I have already stated). Just because it's more annoying to write doesn't affect it's safety; they are orthogonal dimensions to measure a language by.
Rust won't let you do the wrong thing here (except if you explicitly opt-in to with `unsafe` as you note is also possible in other languages). The Rust compiler, when writing normal Rust code will prevent you from compiling code that uses memory incorrectly.
You can then solve the problem by figuring out how you're using the memory incorrectly, or you could just skip out on it by calling `.clone()` all over the place or wrapping your value in `Rc<T>` if it's for single-threaded code, or `Arc<Mutex<T>>` for multi-threaded code, and have it effectively garbage-collected for you.
In any case, this is orthogonal to safety. Rust gives you better safety than Python and Java, but at the cost of a more complex language in order to also give you the option of high performance. If you just want safety and easy memory management, you could use one of the ML variants for that.
Much harder to write Rust than Python, but definitely safer.
(Rust vs Java is much closer, but Java's nullable types by default and errors that are `throw`n not needing to be part of the signature of the function lead to runtime errors that Rust doesn't have, as well.)
[1]: https://www.tomshardware.com/reviews/cpu-hierarchy,4312.html...
...why do I feel nostalgic for a cyberpunk dystopia?
Production is not some place you're supposed to cowboy code, but instead have a reasonable expectation that you will be able to continue supporting it for as many years as it operates, and it's impossible for anyone to responsibly use technology with known limitations that have bitten other real engineering teams that they can find zero workarounds for.
If you don't consider that an impossibility for a production environment, then I certainly wouldn't want to work with you on a team with production responsibilities.
Elm's value proposition is mostly being a functional language with an opinionated MVU library baked in, so you can reproduce that value with a better functional language and selecting a similar MVU library in that other language, which means it should never actually cross the value bar above the risk it brings if you need a browser feature it doesn't support and actively prevents you from accessing.
I would recommend to steer clear of a language that makes these sorts of decisions -- that certain features are off-limits to the regular developer because they can't be trusted to use them correctly -- because if you find yourself in a situation where you need that to solve your problem, you're trapped. I included Go in the set of languages I would recommend steering clear of for years, due to their decision to allow their own `map` type be a generic[2] type but no user-defined types could be[3], leading to ridiculously over-verbose codebases, but they have finally corrected course there.
If you're looking for something kinda like Elm but not likely to break your own work in the future, I'd recommend checking out ReasonML[4] instead.
[1]: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ [2]: https://go.dev/blog/maps [3]: https://go.dev/doc/faq#beginning_generics [4]: https://reasonml.github.io/
I don't think that has to be the case, though. Protocol negotiation is a thing; SSL negotiating the version of the protocol to use, HTTP 1.1 -> 2.0 negotiation, etc.
You could imagine a mail protocol that starts at an encryption level, then during the negotiation process when the mail-to-be-delivered provides a public key, the recipient server can check that key against a listing of keys accepted by the user, and if not included, attempt to negotiate down to an unencrypted version of the email.
The sender of the email could choose to not allow that downgrade and get an undeliverable mail error, or they could choose to allow the downgrade to plain text/html email. This could then be run through the standard spam/malware filtering as usual and the spam eliminated, while email that came from already trusted email can skip those filters because the user has already judged them worthy of accepting and keeping the communication private.
So I don't think that's an intrinsic difficulty of all encryption schemes for email, but...
> If it can be done with E2EE messaging apps, sure it can be done with email. Long-term storage is a really difficult problem anyways.
So first I'll state that I don't think all E2EE messaging apps reach the following bar, either, but the difference between an ephemeral SSL-encrypted communication channel and an email, fundamentally, is that the ephemeral channel won't be written to a disk somewhere, while the email will.
The window in which it is possible to get a copy, and the difficulty in obtaining it, is much more in favor of secrets staying secret in the ephemeral channel than it is in encrypted email. The data payload persists longer, and is likely encrypted by the same private key across many emails, so getting the emails and getting the keys are much easier than with the ephemeral channel that generates a temporary set of keys on each connection and never persists any of it to disk (so storing the communication with the hope of eventually grabbing the keys from the user's machine by virus or social engineering or just plain ol' physical theft doesn't even make any sense the same way GPG-encrypted email does).
On top of that, GPG and S/MIME's support of encrypted-at-rest email is, imo, a fool's errand. Handing a payload of data to a third party that the recipient can eventually query to retrieve makes it much easier to grab a hold of and try to decrypt in the future. The same is true of SSL to an extent, but SSL traffic is much more voluminous, such that saving all of it to eventually crack and decide if there's anything worthwhile in it is unlikely.
The only real way to transfer private data between two users is to do it live with an ephemeral channel, whether that's in-person or via SSL or etc. The only value I see in GPG and friends is in verifying authenticity of the contents - signing the email - not encrypting those contents. Email has, and always will be, an open protocol, for better or worse.
[0]: https://en.wikipedia.org/wiki/S/MIME#Obstacles_to_deploying_...
We were talking about obfuscating what the user did wrong and giving them a misleading message to somehow improve security. Saying that giving them information they can't actually use (like the path to a configuration file in a proprietary web service) is what we're discussing is moving the goalposts.
I think this is probably taking the advice about not letting people on the sign-in window know if a username/email exists in the service or not (to determine whether or not it is worth spending the time trying a list of potential passwords for another user and access data they shouldn't) and expanding it without understanding the nuance. Before they have signed in you don't know who or what is accessing the login path and therefore there's much less confidence that it's a legitimate user. Once the login is successful and that auth token is being used, though, the confidence is much higher and obfuscating details of the relationship between the company and that particular user is pretty strictly anti-user since the user can no longer be certain if the implicit contract of services provided will continue as expected or not. (Couple that with network effects, migration costs, etc, and the relationship becomes even more lopsided.)
These teams are incentivized to eliminate fraudulent accounts that cost the company money and are pressured/punished when their tools produce false-negatives (fraudulent users that are considered okay), but get no such pushback on false-positives (okay users that get flagged as fraudulent), and accounts that are triggering errors in the backend service(s) can look a lot like someone actively trying to hack it. Basically any sort of anomalous behavior that correlates with negatives for the business get flagged by these tools, and doing so unjustly is not an explicit goal, but it isn't really punished within the corporation.
(The false-positives do get negative feedback in the rare instances when it blows up on social media, so these teams often include a whitelist of high profile accounts to just skip over but still impact the regular users capriciously, only "solving" the false-positive problem insofar as it impacts the business.)
The presence of an error at all is a tell for the hacker as they search the surface area of the service's API, making the wording unclear is simply anti-user (sometimes quite literally when these errors are used as part of anti-fraud measures and shut down accounts without informing the user of what they even did wrong).
If a user who is not you uses a browser using WEI (implicitly approving of this attestation tech) and connects to a website that uses WEI, that's entirely up to third-parties and there's nothing legal that you can do.
The most you can do is protest this with:
1. Using a browser without WEI or with WEI disabled.
2. Modifying your own site to talk the WEI protocol but for any browser that can talk that protocol, you ban the user from using your site (or redirect them to a site explaining how WEI is DRM of the entire internet, etc)
Moving beyond White Hat to Grey Hat and Black Hat, you get things like:
1. Modifying your own hosting company to apply this WEI-blacklisting mechanism to your clients' websites.
2. Convincing (or "convincing") owners of core backend libraries in popular programming languages to introspect connections and blacklist WEI-compatible browsers.
3. Take advantage of XSS vulnerabilities to interfere with WEI operations on other tabs within the same browser on the user's machine if they happen to be using your website.
4. Take advantage of vulnerabilities in the WEI protocol to corrupt the underlying attestation system so it fails to function in all future WEI requests for that physical machine.
5. Hack/Crack attestation system security and publicly release the keys, making any hardware using that version suspicious/blacklisted by users of WEI.
6. Probably some other things I haven't thought of, but as you can see they quickly go from dubiously legal to straight-up illegal. It would be best to nip WEI in the bud before such measures are deemed necessary.
> 1) A series of instructions to do a task, which can be unambiguously mapped into a series of instructions in another format.
> or
> 2) A series of instructions to do a task, which is mapped non-deterministically into a series of instructions in another format.
You're a bit too black-and-white on this situation. Floating point calculations often suffer subtle differences in behavior based on optimization flags[1] or CPU architecture[2]. I would not consider C non-deterministic, but this is a situation where differences show up without changes to the code being compiled.
> It could do anything; the P value of it doing something crazy might drop, but it's not zero; and fundamentally, how can you rely on a system where the instructions you give may or may not map to the machine code output?
>
> You add tests? Sure... but, those are generated too right?
>
> You have to dance through a series of tighter and tighter hoops to try to reduce the P value of "crazy hallucination and chaos", but I see no meaningful insight here about how you plan to mitigate that problem completely?
1. Marsha in the here-and-now definitely does have a small probability of actually generating junk tests that it can also somehow generate working code for.
2. Different tools for different scenarios, so if that is a huge problem, don't use Marsha as it currently is.
3. Since LLMs are trained on human generated code explained by humans, the code it generates is human readable, so you can always review the generated output before you rely on it, right now. Human still in the loop, but the amount of work significantly reduced.
4. Trivially, you can get determinism in output by setting temperature to 0, though that also means if it fails to generate an output it will always fail to generate an output.
5. A fully predictable output requires a formalism essentially equal to existing programming languages. The purpose of Marsha is to explore relaxing that for development velocity and simplicity, but it is intended to be a gradient you can choose from so I agree it should be possible. Nothing solid figured out now, but simply dropping into your target language of choice would be an "easy" patch, though it defeats the purpose of the language. Something like Rust/Haskell pattern matching or Lean/Coq constraints informing you of missing definitions would be better, but honestly unsure how to get there.
> Given the context length (and nature of large contexts in general) in LLMs, I also ponder whether it's even possible to do this beyond the trivial form, because it seems like as the constraint set scales, the capability of any LLM to address those constraints (and to be confident that it has) seems like a difficult problem to solve.
This one doesn't seem as hard to me, because of the divide-and-conquer nature of programming. Each individual function gets its own context, and if that function is too big, break it into chunks and generate those independently. Definitely more of a Lisp-y style instead of a big blob of old school PHP.
May also become effectively irrelevant if useful context size exceeds the length of something massive like a novel.
> However, I would like to say that I see this domain as an interesting area of research; and most certainly neither a) a solved problem, or b) a dead end. There's definitely stuff here worth playing with and exploring.
Fully agree. Marsha of today doesn't "solve" it (and depending on your acceptance level of C floating point changes, may never do so) but I say pretty confidently that it is further along than Copilot, and I don't see why it won't improve in the future.
[1]: https://stackoverflow.com/questions/7517588/different-floati... [2]: https://stackoverflow.com/questions/64036879/differing-float...
Software engineering is about trade-offs, for LLM-based code generation in general the trade-off is speeding up the writing of code at the expense of precision in what is generated. When you use something like Copilot it uses the comment or function signature to "guess" what you intend to write, and sometimes it right, sometimes it's not.
Marsha is exploring that trade-off space. Copilot finishes in 5-20 seconds, usually, while Marsha's slower, sometimes as fast as 20 seconds, but usually a little over a minute. The syntax requires you to provide more information up front than just a comment or a function signature and also uses that up front information to generate a test suite to improve the reliability of what it outputs, which increases iterations with the LLM and therefore slows it down.
Only when the code generated passes the test suite will it actually return an output to you, so the code it generated passes the cases that you were able to think of, which should make it much more precise than Copilot. That may still fail, but probably in ways your own code would have failed for cases you hadn't considered, so this particular trade-off feels closer to "free" versus writing it up by hand, in my opinion.
But again, when to use the tool is a decision you must make. You can see from our own examples that we've only used it so far on toy problems or problems small enough that manual review is feasible. Since the test suite always passes at the end (or it simply fails to generate if not), that makes it better than many Eng I and some Eng II level engineers I have worked with in the past. ;)
This is where the claim that it's tested code comes from, because it is literally tested.
One of the examples we added is a simple tool to get headlines from CNN.com[1]. We don't commit the generated python to the repository because we're treating it as a compiler artifact, but here's a gist[2] of one of the runs, including the test suite it created to validate proper behavior. It's not just relying purely on the LLM's ability to string tokens together, but goes through a validation phase to make sure what it built is real.
[1]: https://github.com/alantech/marsha/blob/main/examples/web/cn... [2]: https://gist.github.com/dfellis/a758a7321b4f62f820ddbad57aac...
First, a programming language is just a syntax to describe functionality that could be turned into an actual program. Lisp[1] was defined in 1958 but didn't have a full compiler until 1962. Was it not a programming language in the intervening 4 years? Marsha does not fall into this, since it can already generate working code, but the bar for what is a programming language, I believe, is lower than most would immediately think.
Second, a programming language does not need to be imperative to be a programming language, or languages like Lean[2] that have you write proofs that the compiler then figures out how to generate the code to fulfill would not be programming languages. Lean, Coq, and other such languages are much more technically impressive than Marsha, true, but they share the property you describe the properties a function should have and then the compiler generates the program that fulfills those properties.
Marsha differs from these Proof-based languages in that poor specificity still produces some sort of program instead of a compilation error, which makes it sort of like Javascript that will do something with the code you write as long as it is syntactically valid. This is not a desirable property of Marsha, but it is a trade-off that in practice makes it more immediately usable to a larger number of people than Lean or Coq, because the skill level required is lower.
This is also, as you allude to, the current state of the world in most software development -- project managers come up with high-level requirements for new features, technical leads on engineering teams convert this into tasks and requirements for individual contributors who then write the code and tests which are then peer reviewed by the team as a sanity check and then committed. This process may or may not cover all situations and the specifications at all levels are likely not as rigorous as what Lean would require of you.
Marsha mimics this process, starting from the tech lead level and bleeding into the individual contributor level. The type and function descriptions are analogous to the tech lead requirements and the examples are analogous to the test suite the individual contributor would write. Just like in real world development, if these are not well specified, the resulting code will likely have logic bugs that would need to be addressed with a stricter definition and improved test cases.
The compiler consumes this definition into an AST[3], walks the tree to generate intermediate forms, and generates an output in a format that can be executed by a computer. Some use "transpiler" for a compiler that targets another language, but that is a subset of compilers, not a separate kind of tool, in my opinion, or the Java compiler would be a "transpiler" for the JVM bytecode format that is also not directly executable by a computer.
We are still in the very early stages with Marsha and agree that more syntax could be helpful -- we already have 4 different syntactic components to Marsha versus the fully open-ended text entry behavior of Github Copilot or ChatGPT. But what makes Marsha interesting (to me) is that it makes it possible to explore a totally new dimension in programming language design: the formalization of the syntax to define a program itself. In many papers on new algorithms, the logic is often described in a human-readable list of steps without the hard specificity of programming languages, improving the ability of the reader to understand the core of the algorithm, rather than getting bogged down in the implementation details of this or that programming language. There is still a formalism, but it differs from that of traditional programming languages, and Marsha lets you work with your computer in a similar way.
Are there cases where this is a bad idea? Absolutely. Just like there are cases where writing your code in Python is a bad idea versus writing it in Rust. There is no perfect programming language useful for all scenarios, and probably never will exist. But there will be a subset of situations where the trade-offs Marsha provides makes sense. By being more forgiving than even the most forgiving interpreted languages out there, Marsha is in a good position to fill that niche if the primary barrier is difficulty.
[1]: https://en.wikipedia.org/wiki/Lisp_(programming_language)#Hi... [2]: https://en.wikipedia.org/wiki/Lean_(proof_assistant) [3]: https://github.com/alantech/marsha/blob/main/marsha/parse.py...