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.
> 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.
> 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.
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.
> 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.
I've always thought it odd that we don't use ECC as a standard on all computers. I think people really downplay the impact of memory issues. They can be devastating, especially over time. They will slowly corrupt your file system, documents, binary files, code, everything. You notice when things like your compressed files start giving CRC/checksum errors or your downloads don't match SHA-512. You are then left with this "icky" feeling. What parts of your work are compromised? Obviously this is far worse with things like binary files and structures than those built on readable text. I have normally just rebuilt my system from scratch in these instances (after fixing the issue of course), but not all our files are replaceable, and you forever and always might have corrupted files you are unaware of that got written during this time. You might not find them until years later.
Not necessarily Java-flavored, but internally vs externally focused, yes. More difficult FFI assuming that is the exception not the rule, and that the language itself takes precedence. Write barriers are also not a given if using segmented heaps. Many ways to do this and no single right way. Memory allocation scheme isn't something that is just bolted on, but needs to be aligned to the rest of the language. For example, Java needs such fast allocations and good GC because it does almost no inline allocation whatsoever, so without the best GC on the planet, it would be a lot slower than it is. Contrast this with Go, which has a solid amount of inline allocations, and hence, can get by with a much slower allocator (~3-4x slower by my measurements) and a more basic mark-sweep allocator since the memory pressure is solidly less.
> why do languages like Crystal and D still use Boehm?
Languages use Boehm for exactly one reason: it is easy to shim into an otherwise manual memory system (it was designed for use in C/C++). I mean no respect to its authors, but using Boehm in production is the worst of all worlds: slow allocations (free list allocator), poor cache locality, and not precise (so you can expect memory leaks). If you are going to do a GC language you want: 1) precise 2) bump allocator 3) compacting collector 4) generations. Essentially you want to allocate fast, only touch live objects (most objects die young), compact them for locality, and only process objects each cycle of similar age. There is a huge amount of engineering that goes into a state of the art collector, but those are the basics.
> A nil check is suspicious when it silently handles a state the program claims should be impossible.
If only that could be expressed in the type system. Instead, the programmer is now forced to think about these things everywhere over their entire codebase.
This looks interesting and useful (I haven't tried it yet), but it is important to realize that every single useful Rust program has unsafe. Every single one. Why? Stdlib usage is full of it, and it must be by definition of what it does. In the same way you can't have a useful program without some side effects, so also you can't really have a useful program without doing some level of I/O and FFI, and I/O/FFI is always going to use unsafe under the covers.
That said, there is value in limiting your own unsafe use, and there might be value in limiting unsafe in the crates you use. However, this is really a question of "who do I trust to use unsafe? How much? Under what circumstances?" and NOT "is okay to have any unsafe?" because any useful program will contain a lot of unsafe if traced far enough in its call paths.
I'm a little unclear as to when and under what conditions this results in non-heap objects, now (<= 64-bits?) and in the future (???). I thought that was the _ENTIRE_ point of this project, so I was surprised to see they can be null (did that change from before?). If it is always and forever limited to 64-bits, I fail to see the point of this entire project, as it would have been far simpler to add syntactic sugar (simply pass primitives underneath the covers) as Scala did to create value types vs. JVM changes.
Not only that, but asking it to do a security vulnerability assessment of your own project is a very valid and important thing, and there is no way for it to know what is yours vs someone else's, so we just lose this capability?
You are assuming I'd only get it for that. That would probably just be the straw that broke the camels back, but I'm already thinking about a purchase even if that doesn't work out.
Still trying to understand if a Macbook Pro M5 Max with 128GB is likely going to be able to run coding models well enough that I can cancel my Codex, or even go down to the $20/month plan.
Ultimately it comes down to your entropy source. I always generate and insert in a loop for this reason, if there is a collision, I therefore handle that gracefully.
It isn't about the code (they probably don't even know what that is), they focus on the fact that my daily job tasks have changed entirely (iow, I used to do 'something', 'what' doesn't matter, and now I dictate to an AI to do it). Most people can't fathom this unless they change to a completely different profession/job.
People are blown away when I tell them that, in the last 6 months, my job of coding has changed entirely, and that I now write very little code, but instead manage agents who write it. It is still engineering, and I still very much care what that code is, it's interfaces, how it interacts with the world, how it is tested, etc. etc., but it has taken me a while to get used to the idea of me not writing the code. I'm still not sure how I feel about it, although I am getting more done, and it has helped me keep better focus on "the big picture". That is tough to do when your day is spent in the weeds.
Have they made a way to move those tiny icons in the lower left (aka "activity bar") to larger icons on the upper left like VsCode? As it stands, I can barely see them on my 4K screen and selecting them with a mouse cursor is like a pixel hunting contest. No go for me until they offer a way to change that. Beyond that it seems like a decent editor, but if I can't switch modes back and forth, that is a deal breaker.
UPDATE: Looks like they haven't yet, bummer, and doesn't seem to have much traction either. They redirect to discord, but AFAIK that doesn't have a way to make a feature request directly?