UDP and TCP are Layer 3 protocols, and so is ICMP. They all fill the same bits within network packets, like at the same level. So sending an ICMP packet (protocol 1) is not the same as sending a UDP packet (protocol 17).
Node.js and Go are both memory safe, as are Python, Ruby, and Java. "Memory safe" is a term of art referring to susceptibility to memory corruption vulnerabilities in code written by an ordinary practitioner of the language. Almost invariably, attempts to show languages like Go and Python as memory-unsafe involve a programmer deliberately working to defeat the language. But you can do that in any language, including Rust.
There are essentially just two mainstream memory-unsafe languages: C and C++.
I agree, and I personally wouldn't call golang memory safe for that reason. Thomas's semi-definition includes the word "vulnerability", which narrows the scope so much that golang fits under the bar, since the common data race that causes memory corruption hasn't been shown to be exploitable without being contrived.
My personal definition of memory safety for a language like golang would specify that you can't cause this sort of memory corruption without an explicit call to unsafe, but there's no real definition to fall back on.
The same thing happens any time a message board confronts a professional term of art. The same thing happened with "zero trust", where you'd have long wooly debates about what was meant by "trust", but really the term just meant not having a conventional perimeter network architecture. Sorry, but the term as used in industry, by the ISRG, and in government guidance refers specifically to vulnerabilities.
"Memory corruption vulnerabilities" != "concurrency bugs" or even data corruption. The last thread I was in about this, someone pointed to Go segfaults and said "see! memory corruption!" (obviously: no).
An easy response to claims like this: there's a huge tower of software written Go at this point, including the entire K8s ecosystem. Show me the memory corruption exploits.
The amount of Rust code using unsafe is a major issues for a language build around safety. And yes, the same argument can also be made about Go having a unsafe keyword.
The fact that there exist crates to detected the usage of unsafe in dependencies, shows that its a rather liberal used keyword. Geiger comes to mind.
Unsafe in a language like Go is very rare, mostly because people do not program at such low system level to get the max performance out of it.
Rust code with unsafe: 1.7M
Go code with unsafe: 400k
and for comparison, Go has about 2.3x the amount of repo's. So Rust has about a 10x more usage of the unsafe keyword.
While unsafe is always a risk in Rust, measuring the risk is not nearly as straightforward as counting lines of code. In particular, Rust focuses on encapsulating unsafe code behind safe wrappers that prevent misuse, so the better measure is determining which crates don't do this, and to what extent they can be easily patched to do so.
(Leaflet cofounder here) - sorry about that! Are you seeing that with 'canvas' pages, or multiple doc pages open side by side? What device / screen size? I haven't seen issues with horizontal scroll recently but lots of trickiness with slight differences across browsers and maybe things we can improve for particular cases.
Re: scrollbars honestly we just like the cleaner minimalist look and have gotten used to it but I hear you (+ others) that it can be annoying, we'll look into improving.
This looks like a (not even) thinly veiled advertisement for their Convex product: https://www.convex.dev/.
I am interested in knowing who would make a decision to pay for something like this when there are a gamut of open source options available. Like what is the compelling reason to use something like this.
if you don't want to manage your own infrastructure, you can use our hosted product, but otherwise it's totally fine to self-host the open source binary.
"Really cool" is not compelling enough for me to decide to build a product against something like this. Here is, at a minimum, I would require to even consider:
- Comparisons against other types of stacks, like laravel livewire or phoenix liveview
- Performance metrics/stats/benchmarks whatever. You need to be faster and more robust than the other things out there, or provide some other benefit
- First Class self-hosted on premise install version without dependency on any cloud provider. Kubernetes helm charts or docker compose stacks or whatever
- I do actually like that you have a time-windowed source available license. That is something that alleviates the concern if you go under
- Jepsen or similar analysis, need to make sure whatever consistency guarantees you are advertising hold up
I'll save you more of a marketing pitch, since you seem to have enough of my pitching Convex in the article:) The bullet points at the bottom of the article should be a pretty concise list - I'd call out the reactivity / subscriptions / caching. To learn how all that magic works, check out https://stack.convex.dev/how-convex-works
Author here- and yes as a disclaimer I work at Convex.
As a caveat to that disclaimer, I pivoted my career to work here b/c I genuinely believe it moves the industry forward b/c of the default correctness guarantees, along with other things.
To this question here, some of the things that accelerate full stack development:
1. Automatically updates your UI when DB data changes, not just on a per-document one-off subscription, but based on a whole server function's execution which is deterministic and cached. And regardless if the changes were made in the current browser tab or by a different user elsewhere. Not having to remember all the places to force refresh when a user updates their profile name, e.g., makes it way faster. And not only do the Convex client react hooks fire on data changes, the data they return for a page render is all from the same logical timestamp. You don't have to worry about one part of the UI saying that payment is pending when another says it's been paid.
2. End-to-end types without codegen. When you define a server function, you define the argument validators, which immediately show up on the types for calling it from the frontend. You can iterate on your backend function and frontend types side-by-side without redefining types or codegen in the loop.
3. Automatic retries for database conflicts, as well as retries for mutations fired from the client. B/c mutations are deterministic and side-effect-free (other than transactional changes to the DB and scheduler), the client can keep retrying them and guarantee exactly-once execution. And if your mutation had DB conflicts, it's automatically retried (up to a limit with backoff). So the client can submit operations without worrying about how to recover on conflict.
There's obv. a bunch more in the article about features like text search and other things out of the box, but those maybe are more conveniences on the backend, since maybe a frontend person wouldn't have been setting up Algolia, etc.
I don't consider this strictly open source if components it depends on (I.e, the LLM) is closed source. I've seen a lot of these Fauxpen source style projects around
Not quite certain about your meaning. Could you be more specific? RAGFlow does not have its own LLM model or souce code. RAGFlow supports API calling from third-party large language model providers, as well as local deployment of these large models. RAGFlow has open-sourced these two parts of codes already.
I use Darktable quite extensively for underwater photos, but keen to try Ansel out and see if it's less friction.
An example of friction in darktable:
- I have an external strobe which means I have to put the exposure down to its lowest when shooting, otherwise everything is washed out. Darktable in newer versions has "Compensate camera exposure" on by default, which washes out all the images until I click it off. I'm sure there's a way to make this checkbox disabled by default, but why can't it accept what comes out of the camera?
- No favourites: there used to be a way to have all your panels in a favourites tab. This was great as I usually only use a handful of modules that I use. It's gone in later versions
- The "color balance" panel, not to be confused with "color balance rgb", it's not in any of the default tabs but useful for saturation adjustments. Why are some of these useful modules hidden? Shouldn't all modules be available by default. The only way you can get to it is by searching.
- White balance: there are now two modules and it warns you if you adjust one or the other: "white balance" the standard one on the "base" tab and "color calibration" tucked away on the "color" tab. Both modules are turned on by default, but if you adjust one or the other without turning one off it has a big red warning.
- One upgrade decided to reset export settings, and so my EXIF data was stripped out when exporting. It took me way too long to figure it out.
You can create a preset for the exposure module and define rules when it kicks in. For example based on the camera manufacturer, focal length, iso, etc. I use that to increase the default exposure compensation with my Fuji. I deliberately underexposes to prevent highlights from clipping. So I usually want a +1.25 exposure compensation. Likewise, you might want denoising on for high iso files.
You can organize modules into profiles and simply hide all the ones you don't use. The default profile hides some of the deprecated or display referred modules. You can change this.
White balance indeed has a deprecated variant for display referred and a scene referred one that works completely different that you typically use together with color calibration (which is where you should do most of your color correction, including color temperature changes). The reasons are mathematical and beyond me to explain properly (Aurelian does a great job on his Youtube channel). It boils down to not throwing away the baby with the bath water in terms of rounding errors accumulating and switching color model (to the one used by your display) too early in the pipeline. It might look pleasing but then it bites you when you want to tweak tone or do other things. This is the whole point of working with the scene referred modules.
Having all the legacy modules around is indeed somewhat confusing and Aurelian solves this in Ansel by hiding all the deprecated modules now. They are there for legacy files still.
- Sony WH-1000XM4
reply