I don't know of a country that requires all bicycle parking in any non-private location to be paid, nor a country that requires payment for roadside parking on country roads outside cities. Heck, even within cities, only the very dense ones seem to require paid parking on smaller roads.
Public space does not imply free of any use, but rather that it is freely used by all. The purpose of paid roadside parking is to reduce demand on what quickly becomes a limited resource in dense cities.
That, and all languages more or less converged to the same functionality with different syntax/naming conventions. They also all offer similar toolchains with similar frameworks for nearly all problems. The remaining places where one language dominates often has it doing so due to extreme network effects and extreme toolchain investments.
The main problem I hear in deep systems work is that it’s harder to find qualified and interested candidates to work on older components. Recoding these in rust is a reasonable way to overcome this issue and build up junior staff. Many large systems shops are also of the opinion that fixing C/CPP to do what they want going forward is impossible, and are simply tired of keeping *hundreds* of engineers on staff to fix sig11 crashes and other C/CPP specific issues.
If the number one problem for your business is dealing with c/cpp specific crashes, or you desperately need threading/async - then perhaps rust is right for you? Maybe ai will enable this conversion.
while CPP offers exceptions/threads/coroutines, the interaction of these features can lead to undefined behavior. Requiring that the entire code base follows your convention. Older code bases often use older patterns like forking, global variables, making modern patterns incompatible. See the callouts on object destructors for try/catch as an example https://en.cppreference.com/w/cpp/utility/program/longjmp
> That, and all languages more or less converged to the same functionality with different syntax/naming conventions.
That is not even close to true.
In Go or C or C++ I have to respect comments that say “make sure to hold mutex foo before calling this function!” In Rust I don’t, the type system enforces it at compile time. That alone is a huge difference and there are many differences like that.
Fair enough — you can do that, which is nice, but in Rust it happens automatically. A program that attempts to concurrently mutate the same object without taking a mutex will always fail to compile (unless you hack around this restriction with unsafe) whereas in C++ you have to intentionally build the API that way.
it is funny. I wrote a C# app last week. We mostly do PHP, which I like to call "Runtime Java" these days when using in a enterprise setting. Just as many factories and footguns but hey we slapped a decent OO system on it
And the inexperienced. I got hyped over golang a while back because of go routines. Then I discovered any remotely recent .net version already had what I needed. (I'm a c# dev by default)
Python makes me want to pull my hair out though. Full blown virtual machines make running it tolerable, but the language's inconsistencies... though, I keep trying because I'm hoping theres patterns I don't see.
> ...I keep trying because I'm hoping theres patterns I don't see.
Python's popularity is an accident of timing. If you're digging deep for wisdom and gold nuggets you're not going to find any. The gold of python is the surface level stuff. Easy to type for hunt-n-pec typers. Press tab to indent is easier than {}.
That's all it took for an army of noobs who wanted to be "hackers" to choose Python. Then they grew up, got real jobs and brought Python with them.
I think it was simply the rise of machine learning frameworks. Python was always advertised as good to prototype, test ideas etc. Then the network effect compounded recently: https://youtu.be/ZTPrbAKmcdo
I’d even risk saying Python’s popularity is one symptom of the AI bubble we’re in.
You end up standing in line with a bunch of delivery drivers who all know the drill and are on the clock, and you quickly learn you cannot be polite if you want to get your food.
What ElevenLabs and OpenAI call “speech to speech” are completely different.
ElevenLabs’ takes as input audio of speech and maps it to a new speech audio that sounds like a different speaker said it, but with the exact same intonation.
OpenAI’s is an end-to-end multimodal conversational model that listens to a user speaking and responds in audio.
This entire deep dive is great. I feel compelled to call out this heroism:
> 1st Lieutenant de Wispelaere had prepared the bridge for demolition ... De Wispelaere immediately pushed the electrical ignition, but there was no explosion... Wispelaere now left his shelter and worked the manual ignition device. Trying to get back to his bunker, he was hit by a burst from a German machine gun and fell to the ground, mortally wounded. At the same time, the explosive charge went off.
This is also mentioned in the ConeOfArc video linked on stackexchange. However, at 4:17 in the video, the speaker shows a sign describing two versions of the event. In the first version, Wispelaere died due to a German shell (not a machine gun). In the second version, he was killed by the explosion of the detonating device after shortening the fuse (“l’explosion du dispositif de mise à feu”; not sure how to translate this exactly).
Twig has what it calls 'Live Components', which extend its HTML templating engine to update elements live over automatically linked AJAX calls. Basically turning its static templates into more of a react type system.
I think this sounds more like what the author means.
I love all these attempts because I read the introductions nodding my head in agreement—yes traditional notation is annoying, yes we can use software to make better notations, yes it should be intuitive—and then I get to their actual proposal and it's just as inscrutible as traditional notation, and, often, uglier.
`git blame` lets you identify the commit that changed the line you’re looking for, but doesn’t make it easy to then view further details. The author might prefer GitHub’s blame view because it has these features:
• each hunk has a link to the commit that changed it, as opposed to needing to copy a line’s SHA and then run a new `git show …` command
• each hunk has a link to view the `blame` as of that older commit, as opposed to needing to copy a line’s SHA and then run a new `git blame … path/to/same/file` command
• the code is syntax highlighted by default, without you needing to configure your local Git install to use https://github.com/dandavison/delta
These features lead to a better experience than `git blame`. Various IDEs, editor plugins, TUIs, and GUIs provide similar features.
