Yeah, I find that a lack of a GC means that I don't reach for these languages unless I have a reason to think I really need that level of performance, you lose too many conveniences, the perf gains are usually not worth the investment of thinking through memory ownership. The only language of this class that I regularly use is D, in that lang I can remove all the GC parts for things that do have such perf reqs while reusing most of my GC code, but the things I can do with GC end up being really concise and easy to read, while still being faster than the equivalent python :shrug:.
To be fair to Jai, Odin and Zig, there are definitely software libraries/applications that the world would benefit from having, where this level of performance is basically required. The standard tends to be C++ these days (Rust is rapidly gaining ground, but it's still inconvenient in cases where you frequently need to abstract under the allocator), and I think everyone is looking for a way to not have to write c++ for this stuff.
For me Nim hits the sweet spot since 2.0 moved to ARC/ORC. All the benefits of GC for programming but it's much easier to control allocations and memory when desired. Plus I can run it as a script or compile to JS. I'd put Swift in a similar category too. Not compiling to JS but that it gives good control over memory while being automated via its ARC.
Interesting. I feel similarly but use Rust since I don't really have to think about GC or non GC, I use it more as a modern StandardML or OCaml but with much better performance.
There are multiple ways to read what the author said. I personally read it as urgency relative to other stages in the lifecycle, not other tasks you are balancing it against. So if you have five things you are slowly shaping into an executable state, with four of those in the requirements gathering/solution shaping phase, as soon as the fifth ticks over into a state where the solution is ready to implement, you should focus on implementing the solution over shaping other tasks.
To me this seems like a viable approach, and one that isn't obviously the correct approach (but what if busy stakeholder X only has time to discuss unrelated task Y 30 minutes from now? Do you still sit down to work on the shaped task to completion?). Choosing this approach isn't without its downsides, so choosing it is a deliberate decision with its own tradeoffs.
TIL that the duckdb REPL supports reading json files (https://duckdb.org/docs/current/data/json/overview). This might actually be useful the next time I need to investigate a massive json file (`jq` can only go so far).
Pareto frontiers are pretty commonly invoked to describe tradeoffs in computer science and have been for quite a while. I remember the term being used in one of my early algorithms courses to describe the tradeoff between data structures with fast writes, ones with fast reads and ones that tried to balance the two.
IIRC cognition boasted about hiring a lot of competitive programmers and algorithms experts back when they released Devin, so it tracks that they'd use the term.
It's interesting watching people throw about pareto frontiers sort of like how RF nerds approach the shannon limit (in a practical real world sense of the term, like charting possible modulations/data rates on a two way satellite modem's manufacturer datasheet).
Native applications ship as executable files. These files are basically a combination of machine code instructions (the program logic to be run) + a bunch of extra data that needs to be loaded into memory for the program to run + metadata so the operating system knows how to combine it all.
The first article noted that the file format for this can be thought of as a very specialised, antiquated database format. The author then managed to convert some real applications of theirs into sqlite databases of the necessary program data, and then taught the operating system how to treat those sqlite databases as programs to run.
The second article builds on this, by creating a program shipped as an sqlite database, and then making that program read and write itself (through sqlite code) to store its application state. So instead of having a web server application that loads an sqlite db table, it is just a database file that the operating system can run as a native application, that also stores user data in itself.
As someone who has been using D since about late 2024, I enjoy the following things about it:
- It has a type system that catches most category errors, without having to think too much about types
- It is quite easy to read and write, and code in it has a high signal to noise ratio
- It provides a GC, but also allows you to write idiomatic code that doesn't allocate a lot (missing from a lot of gc languages, it feels like most GC languages force you to allocate more for every abstraction you write)
- It supports GC style code for things that don't need to be efficient (>98% of the code I actually write)
- I can easily micro-optimize the inner-loop code that does need to be efficient, without having to switch languages or setup ffi. I can also be relatively certain that the GC isn't firing too often in those loops, since the gc only collects when you gc-allocate
- I can use all of the native libraries with C bindings on my system, with practically zero costs for bindings
- Metaprogramming in it is top notch, I feel like every time I needed to do some type level shenanigans, I could do so in a way that actually looked like code in the end, without needing to maintain a code-generator. The way the metaprogramming works also stays fairly readable, it's not like macro_rules! or #defines or templates.
Overall, it has superseded C for pretty much everything I previously used C for, and is a joy to use for a lot of other usecases as well, I've found myself reaching for it for programs that I would otherwise write in python recently. Only major weakness in my daily experience is that you can't compile it to WASM, so I'm still using rust for that. I've considered learning Zig or Odin, but I feel like I would miss the GC for simple tasks, and D is good enough on most axes that I stopped looking for a new one true programming language to write all my code in.
I wonder if there is a self consistent way to desire having your mind digitally uploaded into a computer, while detesting the idea of listening to the commands of the earring (and conditioning it to have all of my unconcious thoughts and desires). I guess I just discovered a bit of cognitive dissonance I didn't know I had.
mind upload is closer to the version in the comments, with gem learning to emulate brain and then brain gets removed
the difference is in targetted influence from outside aimed at changing you for its own goals and final form
consider the "accelerated version" of this earpiece - where you just get whackked with dose of heroine (making you "perpetually happy") and then taking over your body
To be fair to Jai, Odin and Zig, there are definitely software libraries/applications that the world would benefit from having, where this level of performance is basically required. The standard tends to be C++ these days (Rust is rapidly gaining ground, but it's still inconvenient in cases where you frequently need to abstract under the allocator), and I think everyone is looking for a way to not have to write c++ for this stuff.
reply