I wasn't sure how I would feel about my newish MBP M5 Max when they released this, but given the price increase, and the fact that I have zero interest in a better screen since I dock most of the time, I am happy I paid $2K less for the same horsepower earlier this year.
Update: The one nice thing I noticed is the weight of the 16" is only 4.1lb vs. 4.7lb from the previous model. I guess OLED is a lot lighter. THAT would be nice.
AI is the correct term because it describes "what" it is (artificial, not natural intelligence). SI describes the magnitude and is no doubt meant as marketing, which then invites different prefixes over time ("ultra intelligence", etc.), creating consumer confusion.
The correct term is "chatbot" in most cases. I've witnessed people make dumb decisions somewhat blindly because "AI" recommended it. If they had called it a chatbot maybe some skepticism would have kicked in.
... and it has never meant "just anything that could be called AI", or even "just anything that could be called AGI".
What we have here with Trump is properly known as "superstupidity": a degree of stupidity that is at best metastable in any physical system, and eventually collapses upward to the intelligence ground state, which is roughly the intelligence of the vaccum.
I don't know why you're being downvoted. Here is his exact quote:
"The use of the word 'artificial' makes intelligence fake. It makes it sound fake and it is not fake. It’s actually amazing, but we have to be careful. In fact, it is exactly the opposite of what it purports."
I see people just skip over the part where "intelligence" is uncomfortably difficult to define and may not be a generally coherent concept to begin with.
> Why do they insist on every new phone being bigger than the phones before them?
Folded, I get, I want it to be a "regular size", but the only reason I don't like big devices is because they are clumsy to store in my pocket and use/grab one handed. If I can use it BOTH ways, now I have a choice. One handed for quick usage, and two handed for extended sessions. For $2K, yeah, I'm going to want a full fledged computer in my pocket.
Mojo is much faster than Rust, but slower than Go. I don't have much experience with Zig.
Mojo is designed to be very fast to compile, so many decisions were made to keep the core language simple, one example is in `where` clause, the checking there happens entirely in the parser. It can be stupid in situations where other languages are smart, and make you explicitly do checks that could be inferred in other languages. But on the other hand, it can be very fast since it doesn't have to do all the complicated resolving.
Another reason is how LLVM is used, Modular found ways to parralize LLVM code generation by introducing novel techniques that'll likely become a lot more popular with other languages.
I think they had a good dive here
https://www.youtube.com/watch?v=SEwTjZvy8vw
The gist is that MLIR (unlike LLVM) was designed to be multithreaded so the whole stack above LLVM IR is parallel, and then LLVM is used as a per-function codegen tool in parallel, so although LLVM itself is single threaded there are multiple seperate contexts of it. also I think they wrote their own linker.
Well, LLVM itself is still single-threaded; they just designed Mojo's compiler in such a way that the code generation part can be parallelised, which is something you can do if you understand LLVM from top to bottom. As far as I can see, no other production-grade LLVM consumer has been able to make it parallel; the single-threaded nature remains a major performance bottleneck.
> Modular found ways to parralize LLVM code generation by introducing novel techniques
> The novelty is in parrelizing LLVM, which is traditionally a single-thread code generator.
You said they parallelized LLVM with novel techniques, but then claimed the novelty is the very act of parallelizing it. That's circular, you still haven't explained what are the novel techniques?
Here is a presentation talking about the parallelization techniques, I skipped to the relevant part but the entire presentation is helpful in understanding how Mojo's compiler works: https://youtu.be/yuSBEXkjfEA?t=813&si=MlB7IsBDsj3o-PTX
From experience, Zig compile times are at least as fast as Go for debug builds that don't need to do linking with C libraries, etc. It does have to use LLVM for release builds however which is a lot slower.
Mojo compiles with O2 by default, it is similar to Go here. Release build is the default, debug is something you opt into. It is still very fast nonetheless
> It’s the language behind Kubernetes admission policies, Envoy’s RBAC rules, Google Cloud IAM conditions, and gRPC’s protovalidate
Very small nitpick, but AFAIK protovalidate comes from Buf, not Google. While protovalidate DOES work with gRPC via backward compatibility (but also Buf's ConnectRPC), saying "gRPC's protovalidate" probably makes people think it came from Google.
Disclaimer: I have no affiliation with either Buf or Google.
Very fair point that protovalidate comes from Buf, not Google.
But it's worth noting that protovalidate can also work with plain gRPC - it's an independent library, and anyone can write a gRPC interceptor that uses it. Here's a community-supported example in Go: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middlew...
I think its more important that protovalidate is not affiliated with grpc in any way. One needs a custom middleware to implement the protovalidate rules for your language used.
Checked exceptions were actually the "right way" to do exceptions (if there is such a thing), the problem was just that developers hated them, but I think that draws the wrong conclusion. That tells me their syntax/usage was seen as too much forced boiler plate making code unwieldy, not that they didn't have benefits for correctness (something often not appreciated until years later).
Unchecked exceptions lead to unhandled exceptions at runtime. We've all seen screens with Java programs running with tons of exceptions in the log, or worse, that crash with unhandled exceptions. This is the result of the unchecked exceptions mess, which is why I won't use languages that use them for routine error handling for anything more than trivial programs.
> developers hated them, but I think that draws the wrong conclusion
Exception handling is just annoying from a syntax perspective. Also checked Exceptions have the problem that they bubble up types that a different layer shouldn’t even be aware of due to exception chaining (cause of a cause etc), unless you carefully re-throw them, which nobody did.
Lower ceremony errors are just better to deal with.
> When I write new code in Fil-C, I just lean into the GC all the way, which makes programming in C and C++ so much nicer. I don’t ref count, I don’t use smart pointers, I don’t free and I don’t delete. It makes these languages so much nicer!
Sure, GC's are nice which is why so many langs have them, but that removes the deterministic allocation performance which most C/C++ programmers want (and many times need). Why not just use something like Go then? You have a much richer stdlib available out of the box.
I don't have a horse in this race, but to me this makes GPT-5.6 Sol Max look better. It is about half the cost for nearly the exact same performance. It just goes to show how expensive Fable really is when Opus 5 is still this expensive relative to GPT 5.6.
Update: The one nice thing I noticed is the weight of the 16" is only 4.1lb vs. 4.7lb from the previous model. I guess OLED is a lot lighter. THAT would be nice.
reply