Vale

Is this new language going to make Rust obsolete?

Attached: vale.jpg (179x175, 8.34K)

sounds like another useless trannylang that will remain obscure and irrelevant forever

X is a fast, safe etc etc language
here we go again...
just learn C++, Python and maybe some javascript and you can program computer to do anything wtf is wrong with people

FPBP

>"systems" programming language trying to compete with the Rust meme for the 8475934th time

No.

This is the first time I ever hear of it. Any nobody language would need serious backing to become competitive with Rust at this point.

As you already created the thread, you may elaborate why you think that one should consider worthwhile.

Runtime checks to prevent use-after-free sound weak. They say they're low-overhead, and I can believe that, but I like to find my bugs as soon as possible. Mitigations are good but a compile-time guarantee trumps all else.
I hope it succeeds but I'm skeptical. Then again, even if it doesn't reach its goal of C++ performance it can still be useful or at least advance the state of research.

>a new language a year keeps the coders in fear
There's a good reason most don't bother learning these new meme languages: they will be superceded by a newer meme language before they gain widespread use.

The main advantage of Vale comes from the fact that Rust uses either unsafe, reference counting, or RefCell in the cases where the borrow checker can't statically understand why the code is safe. In Vale, these methods are replaced by using generational references. Generational references are cache friendly and more than twice as fast as reference counting. They can also be optionally turned off for c-level fast code. This performance will improve even more when the regional borrow checker is introduced. In addition, you have all of your C++ patterns you can use like RAII, move semantics, and clasp. It's much simpler than Rust and the community at least for now is not insane. It'll probably be ready in 10 more years but it's nice to know that Rust is completely useless.

I'm mainly worried about it being the default instead of an opt-in fallback. Will the borrow checker be used for optimization only or will you regularly interact with it as a matter of course?
I like to know that use-after-free will merely lead to a crash, but I like even more to know that use-after-free won't happen, period. Can Vale give me that?

>Generational references are cache friendly and more than twice as fast as reference counting.
so you greenspunned a generational garbage collector. welcome to the 70s.

Are you the same guy who spammed zig a few months ago?
I feel like it has to be one deranged NEET spamming useless garbage with the exact same threads every day

Currently the borrow checker isn't complete. It's being developed right now and its inclusion is only for the purpose of boosting the performance of genref so that unnecessary checks can be avoided. You won't have to deal with lifetimes like in Rust and you can turn it off whenever you want. The main philosophy of Vale is that you are responsible for writing proper code. However, just in case there is a memory error, it will cause a crash or stack trace instead of resulting in undefined behavior. It's simple, fast, and safe. The only tradeoff is a 5-10% overhead and a small amount of extra memory usage. This is much faster and far more memory efficient than a garbage collector.
No, I'm someone else.

I like the logo. never heard of the language itself though

This is better.

Attached: 1657327893381.jpg (892x308, 61.23K)

When will it have a GCC front-end?

(checked)
I can respect that, but it seems that it will in practice lead to less reliable software than Rust, even if not necessarily more exploitable.
I don't think this is strictly worse. But nor is it strictly better.
>The main philosophy of Vale is that you are responsible for writing proper code.
Is it really? I see no mention of that in the pitch, but they like the word "easy" a lot. It wants to be "almost as easy as Javascript" and considers static typing to be the main obstacle to that. No mention of having to track memory lifetimes in your head to ensure correctness.

built for gcc

Wouldn't it be nice if C++ were less error-prone and Python were faster?
Both are possible without major concessions.

It's pretty good, deserves more attention
But Rust is still the best

It depends
Is it pronounced like "veil" or like "valet"?

>Python were faster
It's fast enough for its intended use case (being a glue).
Use PyPy if you need something faster.
>but muh scientific libraries
If you're going to use libraries to do the heavy lifting Python's own performance is irrelevant.

This is just poor cope. Python is "fast enough", but its slowness is still a problem. That's why core developers have been doing major work lately to improve performance. Do you think that work is wasted? I don't.

Python was never intended to merely be glue. This is in the README of the first release:
>Python can be used instead of shell, Awk or Perl scripts, to write prototypes of real applications, or as an extension language of large systems, you name it.
There are many things for which Python is a reasonable choice that are intensive enough that a script might take seconds or perhaps even minutes to run. I'd love it if that were cut in half.

I've also worked on large applications written in Python, hundreds of thousands of lines of code. Python got the job done but if it were faster and less memory-hungry then the user experience would be better and we'd need less expensive hardware. You could argue that Python shouldn't be used for that, but people do use it, and they would benefit from better performance.

>Use PyPy if you need something faster.
PyPy is cool, but it can't optimize everything, and some code (including code that I've written) runs slower in it.

>If you're going to use libraries to do the heavy lifting Python's own performance is irrelevant.
Have you done scientific computing? I've only done a little bit, in university, but that was enough to notice that not everything is easily expressed in numpy. You can very well end up with pure Python bottlenecks.