The only way to have any idea of how long a language might be still around is to look at how long it's been already around. From this perspective , you can only use older languages. The benchmarks show that Lua (and the Luau and Lua+JIT variants) is actually very competitive, so I'd stick with one of those.
In the end, weight is a kind of strength, and popularity is a kind of quality. It looks promising but you can't expect long-term support until there's more contributors and users
At this point it is too early to know. Even JavaScript took like 20 years to catch on
> Never have I ever seen such a highly optimized Java codebase. Not before, not since.
That must be awful to work with. Why couldn't they just pick a more adequate language if they wanted performance? Or write bindings for performance critical parts?
Here's how I understand it: Previously, OpenStreetMap's tile endpoints would serve pre-rasterized PNG images, so zooming in on a tile could cause it to get blurry, until your client requests a new, zoomed in tile. Now, they can serve tiles in SVG format, which scale better
Someone please correct me if I'm wrong here, but I think there's an additional benefit.
Traditional process is:
OSM Database -> PNGs -> Your screen
The first arrow decides what data to pull out and how to draw it.
The new process is:
OSM Database -> Vector Tiles -> Your Screen
The first arrow decides what data to pull out. The second arrow decides how to draw it. So given your vector tiles, you can choose and tweak the style that it's drawn as, deciding how (and if) to display certain things. And you can tweak that in your browser. That's useful for devs and users. "Night Mode", "Show bike lanes" (maybe?), etc.
Also relevant is that the vector tile is not only in a couple formats (pmtiles, mbtiles) but conforms to a couple different schemas (Shortbread, OpenMapTiles) which determines what kinds of data shows up. For instance (I'm just making up this example) one schema might have "big" "medium" and "small" roads. Another schema might just have "big" and "small". The transformation process will decide which kinds of roads in the OSM database map on to which type of road in the schema. (I think it turns out that you can't realistically just pull out all of the OSM database data, you have to pare it down). And then certain styles (Americana, etc) work for specific schemas, deciding things like "big roads are black", etc.
The enormous difference from an infrastructure standpoint is where the arrows are happening and how much effort it is.
> OSM Database -> PNGs
This is a tile rendering farm. It takes a lot of compute power and has to be redone every time a style changes or data changes.
> OSM Database -> Vector Tiles
This is a relatively cheap data extraction process. It has to be redone when data changes.
> PNGs -> Your screen
This is extremely simple.
> Vector Tiles -> Your Screen
This is pretty complex and hard to do fast. Mapbox GL JS is the leader here and they have put a lot of resources into doing it well and fast. Maplibre GL JS is the fork, which is decent, and there are also Leaflet and OpenLayers options.
Source: This is basically my life for the last 10 years.
Rendering of Vector Tiles is not that hard as all the geometry is already processed, polygons assembled and data sorted. If you have good source of vector tiles renderer itself can be relatively dumb.
I was able to implement relatively straightforward renderer in Nim language[0].
I have encountered only three hard parts:
- rendering map labels on paths (this is really hard!)
- how to render labels not to be clipped by tile boundary (I had some ideas but did not implemented it yet)
- collisions between labels and symbols
I don't think anything's being executed here, in the same sense that both PDF (without JavaScript, at least) and JPEG are "data only", even though one uses vectors while the other only supports raster graphics.
The security surface area will be either the png decoder or webgl, both are pretty well scrutinized but if I had to pick I would the png decoder is less likely to have a security issue compared to webgl.
Does't really matter because both png or webgl are available to any website at anytime.
If you care about security implications of reading untrusted data, you may be interested in trying Qubes OS, which isolates apps by running everything in VMs. My daily driver, can't recommend it enough.
> so zooming in on a tile could cause it to get blurry, until your client requests a new, zoomed in tile. Now, they can serve tiles in SVG format, which scale better
They still are blurry, because openstreetmap.org uses a JS library that does not seem to support vector tiles :/
It seems to just not work in Firefox for me, it's the same for me on FF Android but in Chrome it's beautiful! Constant text size while zooming and it's super smooth.
Edit: It also weirdly doesn't work on Chrome on Linux for me either, only Chrome on android. Oh well, hopefully they can bring support everywhere eventually.
reply