I work for Google now on an open source project, and have worked on open source language projects for them before.

This is just not how things happen. At all.

There's a lot of fear in our post about things that _could_ happen, but haven't actually happened in Google's history, or aren't unique to corporate sponsorship.

> 1. I wouldn't be able to refuse if they told me to add tracking, analytics, AI "learning", or lock-in mechanisms.

Google just doesn't do this with OSS projects. I've never seen on mine, or heard about it in others, or heard news of problems. I did work near a CLI that sent some usage analytics back (so they could see crash reports, etc) and some people complained, and it was removed. It was never nefarious and the idea that Google is trying to make better ad profiles or somesuch via OSS projects is frankly ludicrous.

> 2. If at any point they thought that Vale competed with Golang, they would shut it down. It doesn't matter that they're completely different (Vale doesn't even have a GC); if any person in the chain of command even had the _perception_ that it did, Vale would die. > 3. If at any point they wanted the headcount for other things, they would shut it down.

How is Google stopping funding a OSS project any worse than Google never funding it in the first place? They can't "shut down" the project any more after paying you to work on it than before paying you to work on it. If you want to work on it for free, just do so.

Yes, you _might_ have to fork the official repo if it got moved to under Google's GitHub orgs, but contrary to your fears, Google has a good track record of handing off OSS projects they don't want to maintain. There's a whole OSS office to help with this and an official process for transferring ownership and copyrights.

You're also allowed to work on non-Google OSS projects for 20% if it fits in the spirit and goals of 20% time, so if Vale is even vaguely in-line with Google work and goals, you could have just... worked on it. Did you actually talk to anyone at Google about this?

You're speaking in general. I can't be specific on a public forum like this, but you should make sure there are no exceptions in the policies for certain kinds of projects. Respectfully, I went through this personally, and had a lawyer review the situation, so I know what I'm talking about here.

> How is Google stopping funding a OSS project any worse than Google never funding it in the first place?

Think this through. Let's say they spin up a team to work with me on it (which honestly is the only point of giving them Vale at all). Then suddenly, they shut down the entire team and harvest the headcount for some other project. That's devastating, projects don't survive that kind of sudden exodus. I could quit and work on it solo, but then I'm one person trying to pick up the pieces and work through the technical debt and missing knowledge of an entire team. It would take _years_ to recover from that.

The alternative is to keep it open-source, work with volunteers, and eventually do what Zig did: make an open-source-centric 501(c)(3) and hire people to help.

What you say makes sense if I just want to keep this a side-project. This isn't a side project, it's my life's work at this point.

> The alternative is to keep it open-source

I can't imagine that there would be a reason to close it to work on it at Google. That would be a very unusual situation.

> This isn't just a side project for me.

Then you probably made the right decision to work on it full time, but only as an alternative to working on it part time. If Google would have paid you to work on it full time, there really isn't any risk. If they ever tell you to work on something else, you can still quit.

Can you guarantee this in four dimensions? i.e. after new management takes over?

Yes: new management can't un-open-source something. If it's out there, it's out there. They could close future work, but not existing work.

If they employ the core team, and own the immaterial rigths, they could

1. Make next version propietary, or particially propietary

2. Keep updating the closed version, no more core team for open version

3. After some time the open version is too oudated, too far behind the propietary version

4. Ambiquity on lisencing also deteriorates intrest

For examples see, Qt, MySql, Java

It's true that the health of an open source fork isn't guaranteed when there's a split, but OpenJDK looks healthy? I haven't been following Java much.

Yes, and could damage the product/brand in the process. mysql, openoffice, and oracle come to mind. It is survivable but often not a win in the long term for the original author. Seems like a personal decision however.

> Google just doesn't do this with OSS projects.

So, android being an open source project, how does one turn off these nefarious repeated connectivity checks (phoning home)?

Or how does one modify `/etc/hosts` like we do on Linux?

Why do we have to go all the way to root the device or use a different OS to achieve these?

- https://android.googlesource.com/platform/frameworks/base/+/...

Android has a lot of open source parts to it, but nearly all users are running a commercial version and it's not managed as an open source project, so I don't think it counts.

Developer tools are different.

My comment was in response to "Google just doesn't do this with OSS projects."

Also the source code link I provided was to vanilla Android, not to a commercial version running on someone's phone.

Good for you, but I don't quite get the reasoning. I wouldn't expect any guarantee that Google will fund work on an experimental open source project indefinitely, or to pay for work they no longer care about. But why not accept funding on a temporary basis? When they get bored with the experiment and funding dries up, or they want to go in a direction you don't like, the source is out there and you could keep going on your own.

Question about Vale's positioning, where does it exist relative to Zig and Nim? At a brief glance Vale seems closed to C than C++, which seems to put it in some of the same use cases as Zig, but perhaps a bit higher level. Is that an accurate assessment?

Zig is great for low-level use cases like embedded, especially where performance is a high priority and memory safety doesn't offer as much benefit as in other domains [0].

Nim's also geared towards systems programming, though it does so with an RC foundation. It's features are well-designed and complement that pretty well.

Vale's more geared towards the higher-level cases (games, apps, servers) where memory safety, performance, and developer productivity are all priorities. It's meant to be more of a "software engineering" language, focusing on keeping things loose and decoupled in the large, while offering tools like regions [1] (not done yet) to eliminate overhead everywhere it can.

[0] https://verdagon.dev/blog/when-to-use-memory-safe-part-1

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

Rust will probably encompass most of these use cases eventually. Features like e.g. RC with efficient cycle collection as found in Nim, or generational regions as found in Vale, will simply be implemented as add-on crates in Rust, complementing the existing borrow checker.

There are some design decisions mean Rust can't work with generational references and regions, unfortunately. They're incompatible with their form of borrow checking.

In Vale, each struct has a generation in theory, but they are often merged with their parent struct. It requires some pretty interesting logic which can't be implemented in Rust.

Regions require truly immutable references, which Rust doesn't have. Their shared references are unfortunately foiled by the RefCell escape hatch.

Additionally, the rest of Vale's future design prioritizes developer productivity more than Rust has, in my opinion:

- A coroutine-like mechanism instead of Rust's async/await function coloring, and structured concurrency which doesn't involve the Sync/Send "data coloring" problem.

- Vale's borrowing is done on the region level and on an opt-in basis, so users can decide to only use borrow checking where it makes sense.

- Linear typing ("Higher RAII") which allows for different static checks which aren't quite as infectious as aliasability-xor-mutability.

I love Rust, but it has some quirks that make it much more suited to low-level development than these higher user cases. I don't see how Rust can fix them, but there are some smart people working on it and I hope they figure out a way, because the world needs a fast and safe language that's easy to learn and focuses on productivity, even if it's not Vale ;)

I don't disagree that Rust's developer productivity story is still far from mature, especially wrt. async and its ecosystem (and the Rust design team agrees that this is a concern) but if you're going to argue for Vala as a "future design", we should similarly assess Rust's long-term potential. The language is improving quite fast and adding major new features (consider GAT and improvements in const evaluation) despite being quite stable and reliable in other respects. Very different from most "corporate"-focused languages.

(Don't get me wrong, I'm quite fine with also focusing on hobbyist, proof-of-concept languages for potential improvements to developer productivity. But then I'll probably want a Pony.)

That's a fair perspective. I don't have the same faith in Rust's dominance for high-level use as these problems seem inherent to their kind of borrow checking, but its possible they can compensate for it with improvements like the ones you mentioned.

I'm not sure that'll be likely. If anything Rust gets more complicated with GADT's and such. While GADT's makes sense, Rust's fundamental philosophy lends toward verbosity and low level semantics in my opinion.

Don't get me wrong, it encourages very memory efficient code but its also tedious to write. Take RC for example, but you can already do efficient RC in Rust. It's just not as pleasant or easy as in Nim. Rust Rc's still require a fair bit of details about using and borrowing the memory, passing references to non-rc functions, etc.

Also Nim could just compile to Rust as a backend. ;)

I find myself only replying to people who disagree with me. That is sad.

I've added Vale to my blog post. It looks very interesting.

Congratulations on taking a stand for what you believe in.

First time I've seriously looked at Vale. Looks pretty great. One thing that I didn't see in the guide, probably toward the end (maybe in "Patterns") is some discussion about error handling.