urschrei

That hasn't really been the case for a while imo: Martin works at Google and is paid to work on jj (there are also other Google employees who contribute, not sure whether they're paid to). jj is in use (wide use? No idea) alongside Google's internal tool (piper) with which it can interact (and with which it has some features in common) because jj has a pluggable backend architecture.

While I hate to engage in speculation, tell spooky stories, or screech at people about the evil CLA you have to sign in order to contribute, my personal opinion is that if Google were ever to start throwing their weight around, the project would be forked in short order and development would continue as normal – it has momentum, plenty of non-Google contributors, and a community. It's also not a product per se, though as we're about to find out, you can certainly build products on top of it – that probably makes it less likely for its current home to suddenly become proprietorial about it.

(hi Andy!)

I resurrected the Rust Herbie lint (now using dylint) a while ago: https://github.com/urschrei/herbie-lint

My partner is an artist and she absolutely loves this.

For a start, it's a lottery. 2000 people who meet very broad but generally fair eligibility criteria (https://www.gov.ie/en/department-of-culture-communications-a...) will get no-questions-asked income regardless of their skill or importance as artists, these being qualities that are both highly subjective and not fixed in time.

So you can be anyone – rich, poor, or something in between – and still be eligible for it. All you have to do is meet the criteria, which were created in consultation with artists.

Also, what is an artist? Thankfully that's not for me to say, because I have quite a narrow view of what art is, and that view would certainly exclude some people who were successful in the pilot.

My partner has been struggling to make an income from her art for over a decade. As she is a working artist under the pilot definition, she qualifies for the lottery even though she runs a small business (to be precise, she's self-employed – making and selling her art full time. There is a reasonable chance that you have seen it). She also thinks that the government could take many other practical steps steps to make life easier for artists, but that taking a small amount of money and giving it to random artists has a huge potential upside: practically no effort, many benefits.

I know several artists whose paintings will genuinely be hanging on walls for hundreds of years. Or prints. Or photographs. Most make ends meet, and one or two are comfortable. Their work ranges from truly amazing to decidedly mediocre (in my opinion). Did any of them get this magic lottery? Yes, some did. Others (including my partner) did not.

Hexagons do tile the Euclidean plane perfectly. They are the largest of the three n-gons that do so.

Another approach is to teach Claude Code how to use your Zotero library's full-text search: https://github.com/urschrei/zotero_search_skill.

> A side effect of the geometry simplication is that there are some very small gaps between states. Based on your use case, you'll need to handle the case of the point not being within any state borders. In these rare cases, you could fall back to a different method, such as distance checking centroid points, adding an episilon to all state borders, or simply asking the user. (The user may also be in another country or in the ocean...)

If your pre-simplification input geometries form a coverage[0], you can use e.g. ST_CoverageSimplify[1] or coverage.simplify[2] to simplify them without introducing gaps.

[0] http://lin-ear-th-inking.blogspot.com/2022/07/polygonal-cove... [1] https://postgis.net/docs/ST_CoverageSimplify.html [2] https://shapely.readthedocs.io/en/2.1.0/reference/shapely.co...

I wouldn't say it's correct to say that GEOS isn't particularly sophisticated. A lot of (certainly not all) GEOS algorithms are now ported from JTS, the primary author of which is Martin Davis (aka Dr JTS), who works at Crunchy Data, who provide the PostGIS extension. So the chain (again, mostly) goes JTS -> GEOS -> {PostGIS, Shapely} -> … . Martin's work is at the cutting edge of open-source GIS-focused computational geometry, and has been for a long time (of course, industry has its own tools, but that's not what we're talking about).

I can sort of see your point about the merits of global, spheroidal geometry, certainly from a user's perspective. But there's no getting around the fact that the geometry calculations are both slower (I'm tempted to say "inherently"…) and far more complex to implement (just look at how painful it is to write a performant, accurate r- or r*-tree for spherical coordinates) along every dimension. That's not going to change any time soon, so the projection workflow probably isn't going anywhere.

I'm not a regular Zed user, but this isn't true: I simultaneously ran the Ruff and Pyright LSPs when I used it last week.

You are confused or wrong, and you are making incorrect assertions about a system "lying" to you on that basis: you can see this for yourself by typing `jj git init` (or just `jj init`) in an empty directory, touching some files, then running `jj status`. You will see a listing of the added files. The same happens if you commit these files, then make some changes to their contents: `jj status` will show the changed files, and `jj diff` will show the diff per file.

!!Con (pronounced “bang bang con”) 2024 is the last ever !!Con event, featuring two days of talks to celebrate the joyous, exciting, and surprising moments in computing. It takes place on the weekend of August 24-25, in the courtyard of the Baskin School of Engineering at UC Santa Cruz, in Santa Cruz, California, United States.

Agreed. As someone who often advocates for the use of Rust to speed up perf-sensitive Python functions (and in particular, in the GIS domain), this sounds like they haven't fully understood the problem or thought about how to solve it more efficiently with a spatial index (which is easily done in Geopandas, let alone PostGIS). However, the post is a bit vague on details so who really knows.

I see two sibling comments with reports of patchy reliability, so I'll note that it's been rock-solid for me (multiple daily deploys every weekday) since I last commented on it (about a year ago?)

From the site:

UPDATE: Previously, Apple announced plans to remove the Home Screen web apps capability in the EU as part of our efforts to comply with the DMA. The need to remove the capability was informed by the complex security and privacy concerns associated with web apps to support alternative browser engines that would require building a new integration architecture that does not currently exist in iOS. We have received requests to continue to offer support for Home Screen web apps in iOS, therefore we will continue to offer the existing Home Screen web apps capability in the EU. This support means Home Screen web apps continue to be built directly on WebKit and its security architecture, and align with the security and privacy model for native apps on iOS. Developers and users who may have been impacted by the removal of Home Screen web apps in the beta release of iOS in the EU can expect the return of the existing functionality for Home Screen web apps with the availability of iOS 17.4 in early March.

These are the Mesa drivers linked from the blog post: https://gitlab.freedesktop.org/asahi/mesa, so not Rust AFAICS

The one on Ireland’s Eye also has a rope btw

Being annoyed at articles that will have little or no impact on Rust's adoption in Linux are an unusual choice to spend your hard-earned credibility on. Why not simply let people enjoy things (speed, memory-safety, ergonomics)?

A statistically significant result without something like a Hedges G (or Cohens D if comparing means) measure would be called out by even a moderately attentive reviewer as a matter of course (especially if small sample sizes are involved), and many reputable journals actually require effect sizes to be stated, so you run the risk of being desk rejected for leaving it out.

(Fly customer for the past 12 months: small web app (three machines across two regions plus replicated Postgres across two regions, on a paid plan)). Fly has been extremely stable for us, with the sole exception of deploys: once a month or so, deploys from CI start failing for a couple of hours. That doesn’t result in any downtime (I have never experienced any downtime due to a failing machine on Fly), just that new code doesn’t end up on prod until it’s fixed. If it’s urgent I email support (highly competent), or wait it out.

I would describe myself as “extremely happy with the service, yet also annoyed by this aspect”. Fly allows me to manage my resources in a way that isn’t really possible elsewhere (from standard Python web apps in multi-hundred-mb containers to specialised Rust apps in < 10mb containers), and in a way that is (now) extremely simple to reason about, and the support has been excellent when I’ve needed it (they were very patient and understanding when I screwed up a region move and managed to somehow break my db leader beyond repair), but I’d like them to address this, because it’s a widespread issue. Given the evolution of their architecture, I suspect they will. But I’d also like them to talk about it more.

crossbeam was created by Aaron Turon (who has – inevitably – also left the Rust project): https://aturon.github.io/blog/2015/08/27/epoch/

No, it isn’t risky in the least. The analysis makes no use of proprietary data and illustrates potential problems which arise from choices made in the algorithm’s design in an abstract way, using a different word list from the claimed proprietary one that W3W use. The legal threat in question was made because W3W claimed that Andrew Toponce was linking to a product which used their allegedly proprietary word list in a series of tweets. Please don’t make unfounded fear-mongering comments about academic research – they cumulatively have the same effect as the threats you claim to be drawing attention to.

The problem is probably not cibuildwheel. That having been said, the maintainers are knowledgeable and responsive, so I would try to open an issue first. Speaking from personal experience, they were able to help me to solve my problem in a couple of hours.

GEOS will be available in WASM sooner or later (if it isn’t already, and if the licence works for you), rust-geo (under active development, I’m one of a few core contributors who work on it) is available compiled to WASM today (you can see a demo from a core contributor at rgis.app). Those are both vector only. For a more mature product that “only” leverages JS, placemark is the state of the art, and is amazing.

I’m not a raster or EO person so I can’t speak to GDAL’s availability, but I’m dubious that the browser is a good interface for that kind of work, or for a full GIS more generally.

The best thing to read is Eden Medina’s “Cybernetic Revolutionaries” (https://mitpress.mit.edu/9780262525961/cybernetic-revolution...). There’s also a good Tech Won’t Save Us episode featuring the author: https://podcasts.apple.com/ie/podcast/tech-wont-save-us/id15...

The classic post about this phenomenon is James Hague's "The Silent Majority of Experts" from 2012: https://prog21.dadgum.com/143.html

Previously discussed here: https://news.ycombinator.com/item?id=31767890

QGIS isn’t bloated, it’s a big tool for a big problem space. You can’t use “simplified command line things” for a vast majority of GIS tasks, if only because they require visual interactivity.

That having been said, why on earth would you want to use a GUI application to generate raster tiles? The only input required is an extent and a zoom level. Use GDAL or any of ten other free and open-source command-line tools readily available.

It sounds like you’re leaving a dismissive drive-by comment rooted largely in your misunderstanding of a large and complex field with use cases which are largely disjoint. Analysts need GUIs and a lot of different analytics tools. People making web maps don’t.

cibuildwheel (which is an official, supported tool) has made this enormously easier. I test and generate wheels with a compiled (Rust! Because of course) extension using a Cython bridge for all supported Python versions for 32-bit and 64-bit Windows, macOS x86_64 and arm64, and whatever manylinux is calling itself this week. No user compilation required. It took about half a day to set up, and is extremely well documented.

> an experienced dev honestly take to learn a mid-level amount about e.g. Kubernetes or Go or Rust? at least months and months of common usage, not something that is comparable with someone who already knows stuff and can get cracking on day one

I'm not sure how this is relevant? You seem to be trying to make a point about hiring people with specific skills vs candidates with proven ability in the field, broadly speaking, before committing an apparent non-sequitur in which someone (it's not clear who) is "pretending that the internet is a replacement for education". Do you often interview candidates who learned K8s (or Rust!) as part of their education? I assume (given your apparent strong feelings on the issue) that you have some familiarity with CS curricula, but perhaps not.

As a related issue, you're certainly sending a strong signal to the candidates you're hoping to attract, judging by your profile. Whether it's a positive one is left as an exercise for the reader.

In the context of Hacker News and the parent comment’s lack of interest in GUI-based tools, I’m pretty confident in my definition.

R and Python both have state of the art mapping tools and libraries that you can either script or use interactively in a notebook to accomplish literally any conceivable task using vector or raster data, from a simple choropleth map to geographically weighted regression to analysing satellite imagery using pre-trained models. Making publication-quality maps using point data is absolutely trivial, and there are a number of high-quality learning resources available (https://geo-python.github.io/site/, https://automating-gis-processes.github.io/site/)

I started working with spatial data on the Mac platform before Python 3 had gained much traction, and I can assure you that Python 3 really didn’t break much to speak of. Every major library and tool works as well as ever, and in most cases is vastly improved.

I am not claiming otherwise, having been a Shapely user since…2012? I’m talking about the work done by Sean et al while they were at Mapbox.