Hacker Newsnew | past | comments | ask | show | jobs | submit | noahlt's commentslogin

> The thing that makes hashcards unique: it doesn’t use a database. […] Your performance and review history is stored in an SQLite database in the same directory as the cards.

Man I was really looking forward to seeing how they stored review history in plain text.


The OP says that he doesn't want _cards_ be stored in opaque format, because they are valuable. The review history he doesn't care about.

But, yeah, phrasing could've been a bit more precise.


Absolutely the same here. It seems weird to have 'no database' as the selling option for the main system, but then use SQLite for that slice of it.



Where I'm from there's no concept of using public space to store your personal belongings without paying for it.


Care to elaborate, as that sounds rather extreme?

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.


What about e-scooters?


Yes, this is why language hype has largely died down among all but the truly myopic.


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.


You can encode mutex holding into the type system in C++ in a very similar way as Rust. E.g., APIs can take folly::Synchronized<T>::RLockedPtr: https://github.com/facebook/folly/blob/76f81836a2ccb6cd3bc7d...


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.


I see now. Thank you for clarifying. I thought this about ElevenLabs Conversational API.


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).


There's a similar scene in "For Whom the Bell Tolls" by Ernest Hemingway.


I think this is basically the final scene from "The Bridge on the River Kwai" movie as well


array.length


They want to be able to write logic to operate on the DOM elements rather than on Jinja2/Twig/etc template tags.


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.

https://symfony.com/bundles/ux-live-component/current/index....


The end of this road is React's Server Side Rendering and Next.js.

This approach only really has one major benefit over string-based templating, namely, it lets you re-use code across server and client side DOM logic.


Type-checked template application is a benefit.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: