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?
Interesting. I started working on this same idea a couple of years ago as a way to bypass CGo. Eventually I moved on to something else. Glad someone else is working on this. How does the generated Go performance compare to the original WASM performance?