No. It is a fairly static language, with whole program compilation and optimization. The dynamic loading the parent refers to is like a new VM instance, very different from class/function (re)loading.
Even though this just showed up on HN (for the 10th time?) the Lobster project started in ~2010. No LLMs on the horizon back then.
And while Lobster is a niche language LLMs don't know as well, they do surprisingly well coding in it, especially in the context of a larger codebase as context. It occasionally slips in Python-isms but nothing that can't be fixed easily.
Not suitable for larger autonomous coding projects, though.
That is tricky with raytracing, since rays would need to be curved, and at least in this raytracer, ray steps are not all equal in size so doing that correctly could be very expensive.
But is generally a cool idea.
Fog is good too, though. It helps with a sense of scale, and it helps colors and distance noise not be too busy.
While Voxile has off-grid blocks of voxels for monsters etc, it is much more serious about being on-grid for everything else. The entire world is entirely on-grid, single size voxels, you can only place aligned objects, and rotate in 4 directions. These voxels only every exist as voxels, never as polygons.
In contrast with most voxel-looking games, which are actually meshes converted from voxel inputs, placed at arbitrary locations with arbitrary scale.
When I started this project, I actually prototyped what it would take to have moving objects in-world as aligned voxels, but the animation was too jerky and it was too limited. Would have been an interesting "style" suitable for some games (strategy games?) but none with fast paced realtime combat.
Lobster is meant to be a more high level language than Rust, so encoding what you want 99% of the time in the type made sense. It also makes it easier for people to read, knowing that common types like int2 are always by value.
That said, it be easy to have annotations to force the other use case, just so far that has not been needed :)
Yup you could blur, but it is not cheap, and it doesn't feel very satisfying to look at blurry stuff in the distance.
We have a "depth of field" implementation for when you're in dialog with an NPC. There it looks nice, because you're focused on one thing. But when looking around its not that great.
Ideally you want it close to native res in the distance, but without any wobble produced by noise as you move. This is really hard.
It's not intended to be a Minecraft clone.. if you look a bit closer than the initial visual impression, you'll see there are many differences in gameplay.
As for the rating, yes we had a rough initial launch, but we're fixing all these things. Note that it is 65% out of only 63 user reviews, so statistically not set in stone yet.
With raytracing having a far render distance is actually fairly cheap and simple compared to polygonal worlds (good looking LOD is hard).
Some reasons why we don't have a super far render distance, in order of importance:
The biggest is GPU memory. The octree that holds the world gets gigantic at large sizes. We'd have to swap parts out as the camera moves. We can do that but haven't gotten there.
Noise: raytracing looks incredibly noisy if you simply cast rays far into small geometry. Hence we even have LOD for blocks, even though they're not needed for efficiency, they're needed for visual stability.
If you're unlucky and a ray has a lot of near misses with geometry, it does more work than other rays and it causes GPU performance degradation. It's rare but to raytrace far you have to optimize for a certain amount of ray steps, we actually put a bound on this.
We find having fog gives some visual unity and sense of scale. With far away fog, the world looks VERY busy visually.
Yes, that is a downside, but when you write very generic code being limited in what code you can write because it has to typecheck even for types that it doesn't apply to is one of the more frustrating things of doing this in C++ and other languages.
In Lobster, this is `for(m) i: print(i)`
Or simply `for(m): print(_)`
The syntax comes from the observation that even in C-like languages, 99% of the time I want to iterate over the range (0..m-1), so that's what it is optimized for.
I don't enjoy writing the same boilerplate over and over. Moreover, because it is so verbose, it is hard to spot `for (int i = 0; i <= m; i++): print(i);` being a special kind of loop since it looks so similar to the common `<` case. I'd rather that looks entirely different to alert me we're also iterating over the bound.
I am not sure what you mean by "Initiating `i` right before every loop"
In Lobster you must initialize a variable declaration. Now you can produce your bad case with `var x = nil`, but that is undesirable because nil types must be explicitly checked at compile time, so typically you want to use as few nils as possible. More likely thus is `var x = ""` if you must initialize later.
I admit this was mostly out of simplicity/convenience/familiarity.
If you're a Rust person, you'll appreciate that Lobster lets you use similar exhaustive switches to Rust's enum instead: https://github.com/aardappel/lobster/blob/master/tests/types...