We (https://basil.net) are not new and not a startup, but our main language is Clojure and each new project is written in it. Very satisfied with our choice.
I don't like the prefix idea: besides the duplication of information, it also becomes a liability if you ever rename things.
Imagine you prefix all customer IDs with `cus_`, but at some point decide to rename Customer to Organization in your codebase (e.g. because it turns out some of the entities you are storing are not actually customers). Now you have some legacy prefix that cannot be changed, is permanently out of sync with the code and will confuse every new developer.
I wouldn't worry about that - I still think its worth it. I've had systems which during development we thought the Contact page was going to be called 'Contact' in the UI but at the end it got re-labelled to 'Individual' but in all the code it was still called Contact and the IDs all started with a C - but you know what? It was still useful to look at an ID, see the C and know that it was an Individual.
Reddit prefixes their IDs with t1_ for comments, t2_ for accounts, etc. That sidesteps the renaming issue.
Though I believe they mostly do it because their IDs are sequential, so without prefix you wouldn't easily notice if you use the wrong kind of id. They also only apply prefixes at the api boundary when they base36 encode the IDs, the database stores integers
I have that exact issue with a couple different identifiers, and it's not a big deal. Usually it goes along with some data model change you already have to write compatibility code for, the new and old names tend to be related, and the old name tends to stick around other parts of the code anyway. Opaque IDs don't reduce the confusion there, documentation in appropriate places does.
"under a weighty combination of commercial and political pressure, foreign companies are beginning to pluck up the courage if not to leave China entirely, then at least to look beyond it for growth. Chinese labour is no longer that cheap: between 2013 and 2022 manufacturing wages doubled, to an average of $8.27 per hour (see chart). More important, the deepening Sino-American techno-decoupling is forcing manufacturers of high-tech products, especially those involving advanced semiconductors, to rethink their reliance on China."
"This alternative Asian supply chain—call it Altasia—looks evenly matched with China in heft, or better (see map). Its collective working-age population of 1.4bn dwarfs even China’s 950m. Altasia is home to 155m people aged between 25 and 54 with a tertiary education, compared with 145m in China—and, in contrast to ageing China, their ranks look poised to expand. In many parts of Altasia wages are considerably lower than in China: hourly manufacturing wages in India, Malaysia, the Philippines, Thailand and Vietnam are below $3, around one-third of what Chinese workers now demand. And the region is already an exporting power: its members sold $634bn-worth of merchandise to America in the 12 months to September 2022, edging out China’s $614bn."
"Altasia will certainly not replace China soon, let alone overnight. In January, for example, Panasonic announced a big expansion of its Chinese operations. But in time China is likely to become less attractive to foreign manufacturers. Chinese labour is not getting any cheaper and its graduates are not getting much more numerous. America may yet realise that reducing its reliance on China in practice requires closer ties with friendly countries, including membership of the cptpp, the precursor of which collapsed after America pulled out in 2017. And as a budding alternative to China, Altasia has no equal."
I see some Clojure examples in the article. We use Clojure almost exclusively and this would be a great replacement for line-based Git diffs, providing much more insight in actual changes.
Is there any chance such an alternative differ could be used in Git (and adjacent tools like GitLab), or are we stuck with line-based forever?
We adopted it in 2017 and got rid of it in 2021. It introduced a lot of complexity, while still leaving a lot of issues up to us to figure out. E.g. deployment strategies.
Also: our main reason to adopt Kubernetes was to stay cloud-agnostic, but we soon realized that this is as unrealistic as writing a complex app's SQL in a vendor-independent way.
Instead, we decided to embrace our cloud (AWS) by using their CDK tooling and leveraging their features as much as possible. If we ever need to switch to another cloud we will bear the cost then, but for now it is clearly YAGNI.
I started a website for charitable gift vouchers where the recipient can choose from a very large and varied list of causes to donate to. It turns the receiver into an active participant. The nice thing is that both giver and receiver are left feeling good and generous, which increases the appeal and hopefully leads to even more vouchers being donated in the future.
It’s a local project though (https://www.goodgift.be). Feel free to steal the idea. Just be transparent and preferably don’t take any commissions on the donated amounts.
HN could allow the submitter to optionally configure up to 3 multiple choice questions about the article.
A user would need to answer all of them correctly before being able to comment. An incorrect answer would add a delay of ~1h before they can comment (without needing to do the quiz again).
Even though it’s fairly easy to cheat or work around, it might be enough to tilt the incentives towards just reading or at least skimming the article.
It would be unfair to people who only wish to comment on one aspect of it without the need to have an encyclopædic understanding of the content, to those with reading difficulties, for poorly-formatted content, for videos (which present their own accessibility issues) rather than text articles, and plenty of other scenarios.
Imagine trying to comment on a comment without reading the article. The article would be irrelevant but obligatory.
This idea discourages discussion rather than promote it. One can guarantee any submission with such questions would never make it to the front page.
