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.
"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.
Something I never understand when defence spending is compared: how do they account for differences in PPP and different levels of grease/corruption?
E.g if the US spends twice as much as X on fighter planes, but they are built in an uneconomic place because of politics and wages there are double than the average of X. I would say it might mean it actually spends only half, no?
This obituary turns an anonymous "Muslim victim" into the portrait of an admirable, wholesome human being, whom I can eerily relate to, despite being an atheist who is weary of Islam.
I applaud that The Economist wrote this weekly obituary. It puts a crack into the us-vs them narrative that the perpetrator undoubtedly wanted to exploit by murdering Muslim worshipers.
As a Clojure user I very much agree with Rich's careful way of designing software.
But in case of the Clojure language itself, I'd personally prefer a big-bang version 2.0 with significant backwards-incopatible changes to clear up some accumulated inconsistencies, over a fork into yet another language with a new name. Such a fork risks splitting the community in two, each below a critical level, and also makes the decision to upgrade more open-ended (i.e. a 2.0 release explicitly supersedes 1.x and thereby communicates that it is supposed to be better and recommended. A fork is much more open-ended and provides more arguments to part of the community to stay behind).
But there is obviously a point where the original is sufficiently unrecognizable that a new name is more fitting.
He advocates talking about "breakage" and "accretion" instead of the vague term "change".
His most controversial point, as far as I remember, was that any breaking change (i.e. a major version bump in semver) might as well be considered another product/package/lib and should better choose another name instead of pretending to be the same thing with a bumped number. For me that is taking it too far in most cases (e.g. when the intent of the software remains the same), since it would also have very disruptive effects on the community, documentation, reputation, ... of the package.
Another thought about semver: a bugfix requires only a minor version bump, but IMHO this could also be breaking if people were relying on the buggy behavior. I see the value of semver, but I guess it will always be a too-neat abstraction over something that is inherently too complex to communicate in a simple version string.
Yes, I understand that, but it doesn't account for all the moving parts of the Lambda service (like container re-use, warmup time, deployment steps...) that have no local equivalent AFAIK. But maybe I'm overestimating their importance...
Can someone explain the benefits of Datomic Ions? What problems is it supposed to solve and how does it compare to existing solutions?
Also, what is the story regarding local development? (I also have this concern about AWS Lambda; it seems you can only realistically run code in the actual cloud environment)
We are investing heavily in the Clojure-ecosystem (but not yet Datomic). It seems Cognitect is strongly headed into a direction which involves some kind of holistic vision about a new stack, but they don't seem to explicitly communicate this vision anywhere.
My experience is the reverse: I started a company with my 10+ years best friend, and it has been great. We even hauled another friend on board (he bought some shares, but we still have most of them).
Most people I know complain that they don't see enough of their friends due to increasing family commitments, but I'm spending most of my working time in the office having fun with my best friends. It's absolutely great and all the shared experiences also nurture the friendship.
I guess it all boils down to being really really honest about your assessment of each other's character. I couldn't have done it with most of my other friends. We also wrote out rules up front about all kinds of possible issues and determined who would arbitrate, so that we would have clarity before everyone is entrenched in a POV that coincides with their interest.
And our #1 rule is: if anything bothers you, you have to be explicit about it or accept your grievances will be ignored.
We're developing "boring" business applications intended for long (~10y) use:
- Kubernetes: provides a good abstraction for running multiple apps and services in a cloud, without vendor lock-in.
- Postgres: proven reliability, best (free) relational db with lots of functionality
- Clojure: expressive language with huge ecosystem of libraries (since all JVM packages are available)
- ClojureScript: also a huge ecosystem (JS interop). Because it is Clojure's sister language, we reduce training need an mental ovehead. It also enables code reuse between server and client in some situations (using .cljc files and reader conditionals).
- React + Reagent + Carry framework: sane view rendering and state management
- API format: RPC-style HTTPS requests, with payloads in Transit format (so that custom types can seamlessly travel over the wire between CLJ and CLJS)
- Our own `devops` automation software which lets us deploy K8S clusters and apps inside of it. It also provides abstractions around AWS services like S3, which should allow us to move to Google Cloud ifneedbe. We also wrote it in ClojureScript and run it using Lumo.
- Minikube + some standin apps like Minio (to run an S3-compatible service in a local container). This enables us to develop and test all of our apps locally without deviating much from our prod stack. We also support a `hybrid` mode where you can run your app locally (using a REPL) but let it connect to other services which all run in AWS. This further ensures similarity with prod env.
I'm aware some components of our stack might turn out to be wrong choices, so we try to limit blast radius by trying to prevent leaky abstractions where possible. (e.g. our apps are not aware of K8S in any way, and could just as well run on a non-virtual machine, with all related services like DB also running as a local daemon).
Our biggest gamble is Clojure(Script), but because of its Java(Script)-interop, the greatest risk there is language stagnation.
Here's a great movie illustrating how the grid is balanced when a popular tv show ends and millions of people want a cup of hot tea: https://www.youtube.com/watch?v=slDAvewWfrA