I personally like Neovim's defaults since it fixes a few rough spots in old school Vim defaults.
Bonus is once you get used to defaults, almost every server has a Vi installed whose basic features you can use.
5,648 karma · joined March 31, 2021
Bonus is once you get used to defaults, almost every server has a Vi installed whose basic features you can use.
Doesn't this techically happen with most of the modern allocators? They do a lot of work to avoid having to request new memory from the kernel as much as possible.
But the I took an arrow to the knee.
Not quite magic, but it just might be the case that developing independent acting capabilities would be the most efficient way to serve humans.
On a 640x480 screen, a terminal will probably render fine with low CPU overhead. On a HiDPI screen, CPU may have millions of pixels to render for a single terminal window.
It's not that different from other application programs IMO. DAWs and VSTs often offload rendering to GPUs to save as many CPU cycles as possible to get the latency down. I love having low latency in my terminals, so I prefer GPU accelerated emulators.
Arguably, Python is statically typed - it's just that it only has one type: object.
So your CPU can focus on doing useful computation instead of software-rendering the terminal.
There's no reason to assume that models trained to predict a plausible next sequence of tokens wouldn't eventually develop "understanding" if it was the most efficient way to predict them.
But they do close a big gap - they're capable of "understanding" fuzzy ill-defined sentences and "infer" the context, insofar as they can help formalize it into a format parsable by another system.
LLMs are a particular application of machine learning, and as such LLMs both benefit by and contribute to general machine learning techniques.
I agree that LLMs are not the AI we all imagine, but the fact that it broke a huge milestone is a big deal - natural language used to be one of the metrics of AGI!
I believe it is only a matter of time until we get to a multi-sensory self-modifying large models which can both understand and learn from all five of human senses, and maybe even some of the senses we have no access to.
Zig's *std.Io.Reader and Writer seem to be abstractions over many types, like Java's interface class, Go's interfaces, C++'s concepts or Rust's traits. However, it seems that abstraction itself is leaky - in that the length of the buffer is an implicit dependency which cannot be known from the type alone.
Admittedly, we don't know if there's a good explanation for the behavior - but then again, HN comments are as good a place to learn as any. Maybe someone will come up and explain.
This github issue comes to mind:
I managed to build Docker Daemon - one of the most widely used and complex Go projects - from source with a simple `go build`.
I've never figured out how to build Jenkins from source.
Do you know of any widely used Java project that has a simple build process? Maybe a positive anecdote could change my mind.
That's the thing - it "just works" if you're on a "modern" Java project, if it uses Gradle, and if it uses it properly. Most of the Java projects I've had pleasure on working profesionally were not on that standard of quality.
You may argue that it's up to developers to keep build system simple, but in that case C++ tooling also "just works" because you can build a modern C++ project that uses CMake in two commands.
Good tooling prevents the project build process from becoming an undocumented Rube Goldberg's machine.
To build an average Java software, you have to install a specific version of JDK, download a specific build system (Ant, Maven, Gradle, Bazel), hope everything works out on the first try - and if not, debug the most-likely-XML spec file searching for invalid dependency that's printed out on the 1000-line error output...
What Java is desperately missing is something like Python's `uv`.
---
Sibling comment mentioned that debugging Java itself is also a nightmare, which reminds me of the many Spring Boot projects I've had to debug. Stack traces containing 90% of boilerplate code layers, and annotations throwing me from one corner of the codebase to another like a ragdoll...
Admittedly, that's not inherently the problem of Java, but rather the problem of Spring. However, Spring is very likely to be found in enterprise projects.
Hope is a feeling of expectation of positive outcomes, therefore illogical by definition.
Modularity.
Each component in your system should be a (relatively) simple composition of other (smaller) components, in such a way that each component can be understood as a black box, and is interchangable with any other implementation or the same thing.
You can be certain that, if you've managed to get a piece of software running with Guix, you can also get it running identically on any other machine.
Is there a similar proof for structured concurrency - that it can express anything that unstructured concurrency can?
Because double negatives are confusing. Enable_AI = true is much clearer than Disable_AI = false.
Personally, I don't feel much difference between the two. I doubt that an average reasonable person would either.
GCC is still indispensable. I doubt it will be rewritten in Rust any time soon.
Which would incentivise doctors to refuse to treat patients who are more ill, lest they risk their ratings go down.
In real world, most things don't work out that way. What metrics do you use to measure surgeons' success? If you use fatality rate, then as a result surgeons will refuse to do more risky surgeries which will put their ratings at risk, which makes the healthcare worse, instead of better.
Of course we can. But can we do it in a meaningful way, such that the metric itself doesn't become a subject to optimization?
"When a measure becomes a target, it ceases to be a good measure"