Openly VS Vale

They don't mention that can write the rules yourself and also pick and choose from existing rules from github.

There is an attempt to build and open source version of grammarly using vale rules here.

https://github.com/testthedocs/Openly

Check out Openly (https://github.com/testthedocs/Openly) -- it's a "Vale linter style that attempts to emulate some features of the commercial, and closed source, Grammarly."

Grammarly Clone in Vale

There's even a project of someone trying to simulate Grammarly, although it looks a bit dead right now: https://github.com/testthedocs/Openly

According to their own benchmarks, Seed7 can run faster than C (it compiles to C, but it's entirely possible the emited code is better optimized than a human could write directly in C)... it doesn't have a GC BUT manages memory automatically (I didn't really follow the explanation in the FAQ, something about automatically freeing variables that go out of scope and keeping only one reference around?)... that's like a current pipe dream for language designers! From https://vale.dev/ to https://vlang.io/, no one has pulled that off yet, to my knowledge... has Seed7 done that all those years ago?!

Reminds me tha I need to check https://vale.dev/

This is another one that tries to attack the same surface area as rust but aims at being easier.

I wonder what he thinks of Vale.

> I've been wondering lately whether a new spatial approach can yet again simplify matters.

I've been closely following the development of Vale since I first saw it here. Though their approach is slightly higher-level than Rust and requires (some) runtime safety checks (though to be fair, so does GC).

https://vale.dev/

https://verdagon.dev/blog/zero-cost-memory-safety-regions-ov...

I think it would be tough to change the spatial model in a language as low-level as Rust, because that spatial model is just reflecting how your CPU actually works under the hood. If you try to hide that away, the programmer is going to end up losing some control.

Here's the full tab list: - https://tjpalmer.github.io/languish/ - https://blog.python.org/2022/10/python-3110-is-now-available.html - https://devblogs.microsoft.com/python/python-311-faster-cpython-team/ - https://github.com/tc39/proposals/blob/main/finished-proposals.md - https://devblogs.microsoft.com/typescript/ten-years-of-typescript/ - https://devblogs.microsoft.com/typescript/announcing-typescript-4-6/#cfa-destructured-discriminated-unions - https://devblogs.microsoft.com/typescript/announcing-typescript-4-9/#the-satisfies-operator - https://devblogs.microsoft.com/typescript/announcing-typescript-4-7/#go-to-source-definition - https://devblogs.microsoft.com/typescript/announcing-typescript-4-8/#build-watch-incremental-improvements - https://openjdk.org/projects/jdk/18/ - https://openjdk.org/projects/jdk/19/ - https://blog.jetbrains.com/clion/2022/07/july-2022-iso-cpp/ - https://en.wikipedia.org/wiki/C%2B%2B23 - https://en.cppreference.com/w/cpp/23 - https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2128r6.pdf - https://devblogs.microsoft.com/dotnet/announcing-dotnet-7/ - https://devblogs.microsoft.com/dotnet/welcome-to-csharp-11/ - https://devblogs.microsoft.com/dotnet/announcing-fsharp-7/ - https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/ - https://go.dev/blog/go1.19 - https://go.dev/blog/go1.18 - https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu - https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu#n3017---embed - https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu#n3006--n3007---type-inference-for-object-definitions - https://www.php.net/archive/2022.php#2022-12-08-1 - https://wiki.php.net/rfc/dnf_types - https://blog.rust-lang.org/ - https://blog.rust-lang.org/2022/01/13/Rust-1.58.0.html#captured-identifiers-in-format-strings - https://blog.rust-lang.org/2022/02/24/Rust-1.59.0.html#inline-assembly - https://blog.rust-lang.org/2022/05/19/Rust-1.61.0.html#more-capabilities-for-const-fn - https://blog.rust-lang.org/2022/08/11/Rust-1.63.0.html#scoped-threads - https://blog.rust-lang.org/2022/11/03/Rust-1.65.0.html#generic-associated-types-gats - https://blog.jetbrains.com/kotlin/2022/06/kotlin-1-7-0-released/ - https://stat.ethz.ch/pipermail/r-announce/2022/000683.html - https://dart.dev/guides/whats-new - https://medium.com/dartlang/dart-2-18-f4b3101f146c - https://medium.com/dartlang/the-road-to-dart-3-afdd580fbefa - https://www.swift.org/blog/swift-5.6-released/ - https://www.swift.org/blog/swift-5.7-released/ - https://www.swift.org/blog/swift-language-updates-from-wwdc22/ - https://www.ruby-lang.org/en/news/2022/12/25/ruby-3-2-0-released/ - https://www.lua.org/news.html - https://www.scala-lang.org/blog/2022/09/05/scala-3.2.0-released.html - https://tjpalmer.github.io/languish/#y=mean&weights=issues%3D1%26pulls%3D0%26stars%3D1%26soQuestions%3D1&names=solidity%2Chaskell%2Cjulia%2Celixir%2Cclojure%2Cperl%2Cgroovy%2Cocaml%2Cgdscript%2Ccmake%2Cnix%2Cvisual+basic+.net - https://blog.soliditylang.org/ - https://downloads.haskell.org/~ghc/9.4.1/docs/users_guide/9.4.1-notes.html - https://julialang.org/blog/2022/08/julia-1.8-highlights/ - https://discourse.julialang.org/t/julia-v1-9-0-beta2-is-fast/92290 - https://elixir-lang.org/blog/2022/09/01/elixir-v1-14-0-released/ - https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/ - https://clojure.org/news/2022/03/22/clojure-1-11-0 - https://godotengine.org/en/news/default/1 - https://ocaml.org/news/ocaml-5.0 - https://tjpalmer.github.io/languish/#y=mean&weights=issues%3D1%26pulls%3D0%26stars%3D1%26soQuestions%3D1&names=gdscript%2Czig%2Cpascal%2Cfortran%2Cnim%2Cf%23%2Ccommon+lisp%2Cwebassembly%2Ccrystal%2Ccython%2Cvala%2Cerlang%2Chaxe%2Cv%2Cd - https://ziglang.org/download/0.10.0/release-notes.html - https://ziglang.org/news/goodbye-cpp/ - https://nim-lang.org/blog.html - https://nim-lang.org/blog/2022/12/21/version-20-rc.html - https://www.erlang.org/news/157 - https://github.com/WebAssembly/proposals/commits/main - https://github.com/crystal-lang/crystal/releases - https://dlang.org/changelog/2.099.0.html - https://dlang.org/changelog/2.100.0.html - https://dlang.org/changelog/2.101.0.html - https://github.com/odin-lang/Odin/releases - https://gleam.run/news/ - https://gleam.run/news/gleam-v0.22-released/ - https://gleam.run/news/gleam-v0.24-released/ - https://github.com/idris-lang/Idris2/blob/102d7ebc18a9e881021ed4b05186cccda5274cbe/CHANGELOG.md - https://github.com/diku-dk/futhark/blob/master/CHANGELOG.md#02111 - https://grain-lang.org/blog/2022/06/06/new-release-grain-v0.5-durum/ - https://rescript-lang.org/blog/release-10-0-0 - https://www.roc-lang.org/ - https://simon.peytonjones.org/assets/pdfs/haskell-exchange-22.pdf - https://vale.dev/ - https://www.val-lang.dev/

I created the open-source language Vale [0] and this hits home for me. This is one of the bigger reasons I left my job at Google.

I created Vale just before coming to Google, almost a decade ago. For _years_ I repeatedly wondered whether I should hand it over to Google via go/opensourcing. It would mean I could work on it for 20% time, and maybe eventually full-time, which would have been my dream.

Every time, I came to the same decision: Google cannot be trusted with open source projects. Three reasons:

1. If at any point they thought that Vale competed with Golang, they would shut it down. It doesn't matter that they're different; if any person in the chain of command even had the _perception_ that it did, Vale would die.

2. If at any point they wanted the headcount for other things, they would shut it down. This happened to my first team (MyMaps) and second team (Earth) and hundreds of other teams across Google. Directors and VPs love to graciously collect existing projects just for their headcount.

3. I wouldn't be able to refuse if they told me to add tracking, analytics, or other lock-in mechanisms.

I knew that if I wanted Vale to have a solid future, I had to keep it as a personal project, and only work on it off-hours.

Eventually, after a lot of soul searching and burnout, I realized I couldn't do both. The world didn't need another person working on corporate chat systems, but the world does need a high-performance language that's easy to learn and focuses on developer productivity. I left Google a little over a year ago.

It was one of the best decisions I've ever made (though perhaps not financially, losing that FAANG salary hurts). And once we get to a certain level of donations, I'm planning to make a 501(c)(3) non-profit corporation for Vale. I even went to Portland to have a chat with Andrew Kelley (of Zig) about the burdens of running a foundation like that, and it seems pretty feasible, especially once the language gets to a certain level of resources and stability.

[0]: https://github.com/ValeLang/Vale

If you're unhappy with Rust but still want a bwck, you might want to look into other borrow-checked languages, like https://vale.dev/

So besides being a programming language you mean?

https://vale.dev/

Just kidding... A bit off topic perhaps.

On one hand, I feel there are so many similar languages out there {(Val, Vala, Vale, Corroded Iron, Beef, Zig, Carbon, cppfront, Jai)...}, that we don't need yet another, but also I encourage further thought because it may be inspiration for future improvements to C++ itself. The number one faux pas I see them make is trying to directly compete with C++ (inventing their own type system, their standard library, their build system, own package format...), whereas your (by its very nature as a transpiler) embraces C++.