Here is a snippet of code from the Verse screencast (linked elsewhere in thread) that demonstrates a new idea (or at least a new variant) with new power. Basically, you set up a bunch of constraints for the do clause, and if any of the constraints fail for any reason (including array index of out bounds), then the do clause is simply not invoked for that parameter space.
Thanks for posting this. When I looked at the linked page, my immediate complaint was, "Just show me a small example!" I don't really have the time or inclination to dig into all those links to see the syntax for code-blocks, comments (for gods' sake!) or expressions, none of which will give me a feel for the language anyway. (My interest is very casual, prompted only by my interest in improving software tooling (languages particularly) and it's a fairly low priority for me in the first place.)
So mcbrit's quick snippet to the rescue! :D
eta: I do wish programming language pages would all just put a small code sample right there on their landing page, at least as a supplement to whatever else they want to say. Mostly it's going to be experienced developers who look, and we don't want/need a lot of fluff; we're reasonably likely to fairly quickly grok most of what's interesting about a language from a well-crafted example, and that's more likely than anything else to prompt us to dig deeper if it tickles something inside us.
After reading those, how can you say no to nim or crystal?
I didn't even understand the Verse sample, I'd need to see the equivalent c++ (or other common language) to really get what made it appealing. Maybe also more explanation on why. A good learnxiny page might have done that for me.
> I do wish programming language pages would all just put a small code sample right there on their landing page
Seconded. As someone who doesn't work with Fortnite/UE5 development I suspect this page isn't really meant for me. But I would at least have assumed they'd want to have a few little standalone examples front-and-centre to entice any potential users
Note the current Verse style guideline is to capitalize variables rather than types. Seems pointlessly contrary to established practice. Makes the code read like the author is shouting.
Let me make a prediction: this is because types in Verse will be just (failable?) functions that validate values. Notice that types are lowercase.
I said failable above, but they might be some other kind of functions. They have a total effect type (functions that are guaranteed to terminate), which could be safely called by the type checker.
> The ability to do speculative execution within failure contexts, meaning you can try out actions without committing them. When an expression succeeds, the effects of the expression are committed, but if the expression fails, the effects of the expression are rolled back as though the expression never happened. This way, you can execute a series of actions that accumulate changes, but those actions will be undone if a failure occurs in the failure context.
Yeah, I’d like to know more about this. Sounds like transactions baked into the language.
How does that square with performance? To implement transactions there has to be a copy of whatever state is manipulated by the transaction. That is potentially a huge amount of state that has to be copied.
STM suggests keeping at minimum the state of whatever operations are applied within a transaction (the transaction log). Allowing developers to create transactions with an unbounded number of operations sounds like a very bad idea, without knowing the details.
That or the compiler has to reorder side effects to occur after the decision point. Not sure how feasible that is in the general case, but should be a practical optimisation in many cases
Right. AFAIK most games are essentially a loop which applies transformations to a huge number of items in a very short amount of time. Games have a lot of state and work with large amounts of data. Any kind of transaction (locking or copying) sounds like it would be bad for games.
... they don't. Most games contain gigabytes of static data, a whole bunch of ephemeral data that is recreated and discarded every frame, and the actual mutable state that persists across frames is rarely more than a few hundred kB, unless you are making a huge open-world game (in which case it's still probably less than tens of megabytes.)
This persistent data is what you use transactions on, and there are past experiments of doing things like fully double-buffering this state (Each frame, recreate the full state into a different buffer, with the code doing so only touching the previous frame, never reading from the current one. Great for multi-threading!)
It goes well beyond experiments- network multiplayer often keeps multiple copies of various pieces of state in order to support things like interpolation and rollback.
ECS systems are gaining a lot of popularity for games and those are pretty similar to having some SQL database in your engine when you think about it. So it's actually not that surprising to see efficient snapshot/rollback/transaction features creeping in.
I know for example that EnTT, a C++ ECS project has snapshots available to allow you to save the game state in the background without blocking gameplay as an example.
Thanks for this link, very helpful in understanding the Verse language!
Verse-as-a-scripting-language-for-a-game-engine is an interesting experiment. The million script writers who use it are not going to have any understanding of the functional language underpinnings. They're going to copy-and-paste until things work. There's going to be a lot of superstition and cargo cults.
I guess Tim Sweeney has a long history of successfully using exotic custom scripting languages in game engines, from ZZT to various generations of UnrealScript. So he probably knows what he's doing.
"There's going to be a lot of superstition and cargo cults."
I'm willing to hedge my bets that an immutable functional language has a much higher tendency to remain legible than something else. But it will be a very interesting experiment in the history of computer languages IMO.
I also felt Tim was tempting fate when he said "You can import directly from a self published URL. Of course it's the responsibility of the publisher to never change the semantics of that code in an incompatible way."
I just can't imagine that working at scale. I bet they add semantic versioning support pretty quickly.
This looks great. Bit confused as to why they seem so reticent to put it in the mainline engine - unless they don’t really consider it fully baked. Does anyone have any insight on this?
I haven’t watched the Simon Peyton Jones presentation yet (wasn’t even aware of it until yesterday) but seeing that he’s involved lends it some serious credibility. I had misunderstood that this was going to be a lightweight scripting language a la GDScript, but I’m now wondering whether they see this long-term as standing shoulder-to-shoulder with C++ in UE.
The presentation I was half paying attention to last night seemed to say that they consider this a beta version of the language and they intend to include it as an option when it gets to be more mature.
They're also aiming to release the language with a permissive open source license so others can add it to their software.
They don’t have a finished VM yet for it so it does live on too of the Blueprints evaluation engine. It will probably come to the engine when the VM is in a good state. Ultimately Blueprints and Verse could/would run on top of it, making them interchangeable.
There's a lot of good stuff here, effects, transactional memory, a concurrency story without colored functions (don't be fooled by the documentation mentioning async over and over, it's different stuff), a completely novel way of dealing with failure, planet-scale repl (not yet available), etc.
But I feel like they had a list of features and a specific syntax that they wanted to give to game developers, and they then had to shoehorn "the good bits" (the semantics) into these arbitrary features. Some things are truly bafling, like it has both significant indentation and {}, at programmer's choice. Wat.
Also I think the documentation is not great. It says reference in the title, but as a reference is not very thorough, in fact it's more like a tutorial, but the sequencing is not very pedagogical to be a tutorial either. In general the concepts are explained at a very basic level, but then sometimes it throws very technical concepts at you out of the blue, like type polarity. Also a lot of the links are 404 and they hijacked middle click. Ugh. They also publish memes in the documentation. In fact all images published as part of the documentation are kinda pointless.
I suppose I'm not the target user here, but I really wish there was a way to play with the language outside the Unreal editor. Surely this has to be possible, if anything, just for their own developing team's sanity. (Edit: after watching the video linked in the thread, apparently this is coming, they are going to release it as open source!)
In any case, I am really excited about this new language, quirks at all, and I am really waiting for the next papers the team will publish. The first paper was really great!
In fact I think that `class` and other constructs are some sort of compile-time macro. I suspect some syntactic idiosyncrasies are about making the language homoiconic.
Verse has effects, but not algebraic effects. The set of effects is finite and fixed, and there's no way to define arbitrary handlers. All effect processing happens in language constructs like if and for (which might be macros, so maybe there will still be some user-level support for handlers after all). Because it does not have a full blown effect system, concurrency and monadic composition had to be baked into the language, with an effect system these features could have been implemented in a library instead.
Notice how effects are negative types. They are a promise about what a function will not do, not an indication about what a function might do. This is the opposite of other languages with effects.
defer is not needed if you have linear types. I suspect they considered linear types too difficult for the average programmer, so they went with what they consider a good-enough solution.
The type system is probably very novel, I suspect it is the most interesting part of Verse but so far has not been explained or talked about at all. I suspect it might have some form of dependent types.
I think most people will have concerns about whether they can pull it off from a performance perspective. I am hoping that, just as UEs lead over unity, at least in the 3D space, is because it was developed as a consquence of creating games, rather than as a means to create games (if that makes sense), perhaps Verse will enjoy that same advantage in that the impact of memory management, automatic or otherwise, will be constantly evaluated with the end goal in mind, they won't lose sight of the woods for the trees, so to speak.
why in the world would you do that? even going out of your way to _call it boolean_ in the description, and then :fu: in the actual language
> indented comment: Anything that appears on new lines after <#&> and is indented four spaces over is part of the code comment. The first line that isn't indented four spaces over is not part of the code comment and ends the code comment.
Yes, I've seen this behaviour on quite a few sites recently, like they're running a bitcoin miner or something. Here's another example: https://zed.dev/
I have no idea what they're doing to slow my machine down to a halt.
Verse has nothing to do with SkookumScript. It was built from the ground up, although my understanding that some of the same people who worked on SkookumScript are also working on Verse.
Ya i'm trying to think where on earth I used a programming language that has the same concepts such as race, sync and about 500 other things i recognize in verse. This forgotten language also just so happened to compile down to blueprints.
Sweeney totally bought skookum and threw it away and then just so happened to reinvent all the same keywords.
Not yet. All of that stuff will come (and it will eventually be open source), but in these early stages they’re keeping it focused on a single use case.
It's pretty elegant.