vos VS rust

The creator of V made some big claims that raised a few eyeballs, they've gained a reasonable following over the years, have a pretty serious looking website (https://vlang.io) a beer-money level Patreon following and some corporate partnerships/sponsors. However have experienced some pretty brutal takedowns over the years, with some of the bolder claims about the language/compiler being exposed as being.

A word I keep seeing in relation to V is "aspirational" - the project aspires to be a serious language with some major features, so I think it's fair to approach it with a more critical eye than one would a kid's side-project. I think HN would have been pretty understanding if they were open about the state of the various features and were a little less defensive when they encounter articles that treat it like a Real Language and review it as such. If the authors don't want this kind of feedback they can just say front-and-centre (or on their FAQ @ https://github.com/vlang/v/wiki/FAQ) "this is a toy" or "this is pre-alpha"

Autofree has existed for years and can work. Here is a demo. It is used in V's Vinix OS, Ved, and other applications. Part of the issue is there are detractors who purposefully spread misinformation nor know about its other memory options, and the other part is understanding how to use it.

Another option is to write the kernel in V. Vinix is an OS written in V. You can use it for reference when building your project.

And that's why vinix [1] is full of manual free call? That tells how good autofree is, isn't it? Can you compile v compiler with autofree? Last time I checked, you can't.

[1] https://github.com/vlang/vinix/search?q=free&type=code

vweb, volt, and ved are not a "little more than alpha"

yes, the os is being developed in V, and it can already run bash, GCC, G++, and Doom.

https://github.com/vlang/vinix

It's a great concept, but languages like Rust (https://www.rust-lang.org/), Zig (https://ziglang.org), Vlang (https://vlang.io/), etc... are already running with a similar idea to being easy to interact with C and are viable alternatives to it as well. Vlang even created its own OS, Vinix (https://github.com/vlang/vinix), to show its capabilities in this regard.

Seems to me, Cello would be more for those C programmers that didn't want to try the various alternative languages that are now out, and happen to agree with its developer's interpretation of what high level constructs would look like. The point of these alternative languages is to offer features that C doesn't have or to implement them in easier or clearer ways.

Vinix shows the capabilities of V on bare metal, in additional to it being useful for high-level programming as well. https://github.com/vlang/vinix

Almost fixed the compiler: https://github.com/rust-lang/rust/pull/123325

Rust: A secure, efficient, and modern programming language (omitting ten thousand words). You can simply follow the installation instructions provided on the official website.

Recently did something similar in Rust but for generating SVGs. We've adopted it for snapshot testing of cargo and rustc's output. Don't have a good PR handy for showing Github's rendering of changes in the SVG (text, side-by-side, swiping) but https://github.com/rust-lang/rust/pull/121877/files has newly added SVGs.

To see what is supported, see the screenshot in the docs: https://docs.rs/anstyle-svg/latest/anstyle_svg/

We strongly believe in Rust as a powerful language for building production-grade software, especially for systems like ours that run alongside Kubernetes.

The above Assert<{N % 2 == 1}> requires #![feature(generic_const_exprs)] and the nightly toolchain. See https://github.com/rust-lang/rust/issues/76560 for more info.

Another week, another dive into Rust. This time, we're delving into structs. Structs bear resemblance to interfaces in TypeScript, enabling the grouping of intricate data sets within an object, much like TypeScript/JavaScript. Rust also accommodates functions within these structs, offering a semblance of classes, albeit with distinctions. Let's delve into this topic.

There’s also other reasons. For example, take binary search:

* prefetch + cmov. These should be part of the STL but languages and compilers struggle to emit the cmov properly (Rust’s been broken for 6 years: https://github.com/rust-lang/rust/issues/53823). Prefetch is an interesting one because while you do optimize the binary search in a micro benchmark, you’re potentially putting extra pressure on the cache with “garbage” data which means it’s a greedy optimization that might hurt surrounding code. Probably should have separate implementations as binary search isn’t necessarily always in the hot path.

* Eytzinger layout has additional limitations that are often not discussed when pointing out “hey this is faster”. Adding elements is non-trivial since you first have to add + sort (as you would for binary search) and then rebuild a new parallel eytzinger layout from scratch (i.e. you’d have it be an index of pointers rather than the values themselves which adds memory overhead + indirection for the comparisons). You can’t find the “insertion” position for non-existent elements which means it can’t be used for std::lower_bound (i.e. if the element doesn’t exist, you just get None back instead of Err(position where it can be slotted in to maintain order).

Basically, optimizations can sometimes rely on changing the problem domain so that you can trade off features of the algorithm against the runtime. These kinds of algorithms can be a bad fit for a standard library which aims to be a toolbox of “good enough” algorithms and data structures for problems that appear very very frequently. Or they could be part of the standard library toolkit just under a different name but you also have to balance that against maintenance concerns.