SedonaDB builds on libraries in the Rust ecosystem, like Apache DataFusion, to provide users with a nice geospatial DataFrame experience. It has functions like ST_Intersects that are common in spatial libraries, but not standard in most DataFrame implementations.
There are other good alternatives, such as GeoPandas and DuckDB Spatial. SedonaDB has Python/SQL APIs and is very fast. New features like full raster support and compatibility with lakehouse formats are coming soon!
You seem to be implying that it is bad because it is marketing, and marketing is bad. But not all forms of marketing are bad. This is a classic association fallacy[1]. In this case, Deno can both improve perception of their brand and reclaim "JavaScript" -- it's a win-win.
It is literally association fallacy. And it is bad because it doesn't lead to a good discussion. Instead of actually talking about whether Deno is doing a good thing, the only way I can respond to "Nah, all forms of marketing are bad." is by saying "no they aren't", which won't change either of our minds and isn't a particularly interesting discussion.
You seem to be saying that Deno reclaiming JavaScript is a bad thing? Why?
>Letting people know you have a product is marketing
Google Summer of Code is bad. I don't want a trillion dollar monopoly influencing FOSS.
Sponsoring the Linux Foundation can be bad, depending on who does it. Individual people with their donations?
Releasing libraries as Open Source is not bad. But if you release them as a corporate behemoth, who employs the people who work of them, and have them assign copyright claims for their contribitions to your corporate entity, it is worse than a community drive FOSS project.
Google SoC gives legitimacy to working of OSS to equal terms of having a paid internship. Many of the projects probably don't even meet your description of FOSS.
The Linux foundation would not exist if only individuals donated to it.
Most OSS suffers from a lack of maintainers with time as they rarely are paid and can't make a living from working on it. Company backed OSS doesn't suffer from this. Most popular "community" projects are held together by an assortment of company backed developers.
FOSS barely existed in 2005 compared to what it is today. Communities rarely stay the same as they grow larger, but that doesn't mean they are worse. Change is inevitable.
>FOSS barely existed in 2005 compared to what it is today.
On the contrary: it barely exists today.
FOSS in (roughly speaking) 2005 and before was about a larger vision and a community. Not about mere access to code with specific licenses, or how many trillion dollar companies are depending on it.
>Communities rarely stay the same as they grow larger, but that doesn't mean they are worse. .
I'm not speaking about how communities in change in abstract (in which case doesn't mean necessarily for the worse). I'm speaking about what specific FOSS communities have had happened to them, and which I, and others, do find worse.
I think you misread the comment you're replying to as "I think their chances are good", rather than "I think it speaks well of their character". The latter was how I read it, and I believe the intended meaning.
I have had my share of compiling Rust programs, pulling in thousands of dependencies. If people think it is good practice, then well, good for them, but should not sell Rust as a safe language when it encourages such unsafe practices, especially when there are thousands of dependencies and probably all of them have their own unsafe blocks (even this ACME support does), which affect the whole codebase.
I am going to keep using certbot. No reason to switch.
This is a problem I'm pretty invested in so let's take a look.
If we add the list of dependencies from the modules this is what we get
anyhow = "1.0.98"
base64 = "0.22.1"
bytes = "1.10.1"
constcat = "0.6.1"
futures-channel = "0.3.31"
http = "1.3.1"
http-body = "1.0.1"
http-body-util = "0.1.3"
http-serde = "2.1.1"
hyper = { version = "1.6.0", features = ["client", "http1"] }
libc = "0.2.174"
nginx-sys = "0.5.0-beta"
ngx = { version = "0.5.0-beta", features = ["async", "serde", "std"] }
openssl = { version = "0.10.73", features = ["bindgen"] }
openssl-foreign-types = { package = "foreign-types", version = "0.3" }
openssl-sys = { version = "0.9.109", features = ["bindgen"] }
scopeguard = "1"
serde = { version = "1.0.219", features = ["derive"] }
serde_json = "1.0.142"
siphasher = { version = "1.0.1", default-features = false }
thiserror = { version = "2.0.12", default-features = false }
zeroize = "1.8.1"
Now vendoring and counting the lines of those we get 2,171,685 lines of rust. Now this includes the vedored packages from cargo vendor so what happens when we take just the dependecies for our OS. Vendoring for just x86 linux chops our line count to 1,220,702 not bad for just removing packages that aren't needed, but still alot. Let's actually see what's taking up all that space.
Coming in at 12MB we have linux raw sys which provides bindings to the linux userspace, a pretty reasonable requirement. LibC and tokio. Since this is async Tokio is a must have and is pretty much bound to rust at this point. This project is extremely well vetted and is used in industry daily.
Removing those we are left with 671,031 lines of rust
Serde is a well known dependecy that allows for marshalling of data types
Hyper is the curl of the rust world allowing interaction with the network
I feel like this is an understandable amount of code given the complexity of what it's doing. Of course to some degree I agree with you and often worry about dependencies. I have a whole article on it here.
I think I'd be more satisfied if things get "blessed" by the foundation like rustls is being. This way I know the project is not likely to die, and has the backing of the language as a whole.
https://rustfoundation.org/media/rust-foundation-launches-ru...
I do not think it is the language to blame for it anyways. That said, I just compiled Zed with release mode and it pulled about ~2000 dependencies, I do not think that this is "normal". Perhaps it is if one is coming from npm, but come on, we should know better.
The problem is definitely real, I'd hope that as the ecosystem matures we come to better solutions. Microsoft and google are pretty heavily invested these days so I'd expect they'd be able to provide some clarity here.
I think we just need to push a culture of writing your own code for small things you're pulling in. (of course that just is pulling alot of weight :) )
I just get tired of everyone trying to burn down crates.io as an inherent evil.
A few days ago they were identifying as “FaceBot” (not "FacebookBot").
When that began to be blocked, they switched to reusing the “Facebookexternalhit” user agent they also use for redirects; one people are less likely to block.
reply