I'm really sad to see them waste the opportunity and instead build an nth managed cloud on top of AWS, chasing buzzword after buzzword.
Had they made deals with cloud providers to offer managed TimescaleDB so they can focus on their core value proposition they could have won the timeseries business, but ClickHouse made them irrelevant and Neon already has won the "Postgres for agents" business thanks to a better architecture than this.
The current situation is getting worse day after day because everybody want to ScRaPe 4lL Th3 W38!!
Verifying Ed25519 signature is almost free on modern CPUs, I just wonder why they go with an obscure RFC for HTTP signatures instead of using plain JSON Web Tokens in an header.
JWTs are universal. Parsing this custom format will certainly lead to a few interesting bugs.
That was my exact complaint on reading the article. "Seriously, you went through that entire article, and never gave people the ability to personally explore the cable connections themselves? Shame."
Also, bonus content from recent news. The two cables cut are:
> The telecommunications analytics agency TeleGeography maintains an addictive map of all the world’s undersea cables[...]
They weren't kidding, it is addictive! I'm surprised that zero undersea cables connect directly to the SF Bay Area, and how many cables there are in the bay around Seattle/Vancouver.
And the Far North Fiber connecting Norway, Ireland, Alaska (USA), and Japan, but none of the other countries it goes by on the way. I wonder why.
I (also like sibling comments) respectfully disagree.
Rust is aimed and focused as a safe C or a sane C++ substitute, and is meant to intermingle with both. It is not an application "high" level language. You can use it as such, which is great. For anything you would use C or C++ you can use Rust instead. As a cryptographer I find that great.
Regardless of all the lack of latency or other control -- beyond fine tuning -- a garbage collected language makes critical memory choices we want to make instead. There are times we want to swap or use our own memory allocator, never mind having to add a garbage collector in the mix. (There is a good number of languages that scratch that itch, and you can likely link and use your C/Rust code with them.)
As far as async: also respectfully disagree. Async is sugar for here is a Future<..>. If you want to poll it locally you can. You can scope it also. If you want to use a cross thread work stealing algorithm you can. But you need like memory management to consciously make these design decisions. This is similarly why a lot of things are not built in in C.
They wanted a systems language. A GC would be very appropriate for much of the code I write, but would not have been for an OS kernel. Green threads removed as well. I admit the GC version with green threads I would have preferred, but again, not appropriate for the domain they wanted. I still want my halfway between Go and Rust language.
A GC-free systems language isn't just for OS kernels.
Rust's main use case was to replace C++ components in firefox. This wouldn't have been possible with a language that brings along its own GC, as Firefox already has a JS GC. Multiple garbage collectors in the same process are a quick way to madness, especially if you have reference cycles stretching across multiple GC heaps.
This also comes up when writing Python extension modules, base libraries that are meant to be usable across languages, etc...
This is part of why Rust is so successful -- it's the first real alternative for this space since C++ came along.
For most application development, it's better to use a garbage collected language. But in the application space there is a much bigger choice of languages already available, Rust wouldn't have been a big deal over there.
I do wonder why there hasn't been more exploration in a series of languages that have a very similar style and toolchain but have different audiences. It would be great to have Rust, Rust with a GC, and then some sort of interpreted language that has a similar syntax. When jumping between languages I feel like half the battle is overcoming muscle memory.
This is my dream. An interpreted language, implemented in Rust which essentially boxes all data and can do message passing to the host language. This would then give a somewhat plausible upgrade path to port the interpreted code into Rust bit by bit as required.
The interpreted language even be slower than Python, so long as the escape hatch to Rust was simple and safe enough to implement the interfaces.
I heard this brilliant summary in a video from ThePrimeagen:
In Rust, lifetimes color your types, like async colors your functions.
It is a great condensed summary of what makes lifetimes a great difficulty of async Rust. It's a language that has the function coloring that is typically introduced by async (likewise in JavaScript), and on top of that the typesystem itself gets colored by lifetime annotations. You can have a well written and working program... then due to some new need or refactoring, wanting to add a 'static somewhere will cause it all to break down.
It's part of the language, nothing bad with that. But it is an extra layer of difficulty that needs to be mastered. To me it shows that Rust might only be the initial step towards future programming languages where this kind of issue doesn't lean so much on developer knowledge.
a. it never had a real corporate backer, until it was too late (and Rust already stole all of its mindshare)
b. It had a garbage collector, which meant that realistically it could not replace C++. Or rather, it could but you basically had two different Dlangs - one with GC and classes, and one without. It was arguably not necessary, because people already had GC languages that were fast enough and worked for their needs, and those who needed speed were better served by C++, which arguably isn't that bad of a language if you know how to use it.
Rust is arguably the first real contender to C++'s reign because it really brings to the table features you'd be a fool to pass on. D was nice, but it was not worth the switch. Eliminating whole classes of bugs instead is.
Lifetimes complicated. Having a proof of them at compile time is difficult. You can't prove everything for starters. A lot of patterns are just a no-go. Why not defer that to the runtime, and just observe which variables stick around (that's GC)
IO complicated. The cycle of doing code then waiting for IO is wasteful (sequentially you waste millions of CPU cycles waiting for the network to answer back). To max out usage of your hardware resources you could just aggregate IO requests with your compiler. Switching back and forth between code that uses IO, as IO request come back (that's async)
Problem is: switching back and forth between code that uses IO is recklessly hard wrt coming up with a proof of the lifetimes of the variables.
And a language/runtime _needs_ to have the trifecta of compiler/GC-or-memory-management/memory-model coherent and within the runtime.
compiler/GC-or-memory-management: the GC-or-memory-management needs to know who writes, who owns, who reads
GC-or-memory-management/memory-model: you need to know when and how you can read your writes, what are the rules
memory-model/compiler: you'll be managing memory barriers so that you can cram together sequences of writes that are compatible, for maximal performance
This trifecta dependence is foundation to a language/runtime, and a change to one affects the others quite deeply. Changing the compiler (bringing async here) affects the other ends and you can't do that when GC-or-memory-management is all over the place (as a lib, or god forbid in user hands)
I'm afraid async is just something unaffordable for a language that wants to be that close to the metal. And even then, async is just a bandaid for a costly threading IO model.
----
Come over to the dark side of Erlang, Go, and Java. We have small threads now. You can just block like there is no tomorrow, and the runtime will have a cheap back and forth. You can just forget about the lifetimes, as the GC will sweep after you (and concurrently, outside of the critical allocation path). Forget it all my friend. Java is love, Java is life.
Rather than those operators and how GC is done, I think the key aspect is how much easier async is in other languages that have easy automatic memory manage without ownership through garbage collection. Go and JavaScript/Dart are good examples.
But such models would also take away everything that makes Rust... Rust.
Plenty of GC enabled system programming languages have achieved similar feats, with bigger outcome than Rust has managed to on the desktop space, e.g. Xerox Workstations, across Smalltalk, Intelisp-D and Mesa/Cedar.
Redox is still not as feature rich as Mesa/Cedar was on the Dorado in 1981.
> Even better, AR/VR headsets with electrodes can not only record your brain activity, but they can also stimulate it with the screens and know exactly how you react to this or that image, this or that sound. What is your reaction to this politician? How you feel when you see this advertisement for this new car? What kind of man/woman you prefer (which can then be used to make tailored ads) and so on... In neurosciences, this practice is known as probing: analysing how your brain reacts to controlled stimuli.
C RTOSes are conceptually nice, but such as pain to use in the real world, a lean framework like embassy is the natural evolution.
The best thing is that embassy can actually be considered as a real-time "OS" (you can read more here: https://kerkour.com/introduction-to-embedded-development-wit...).
reply