vincentdm

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.

Here's a relevant article about it: https://www.economist.com/business/2023/02/20/global-firms-a...

Some quotes:

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

Cool!

We built something similar for on-premise data sources, in Clojure. https://basil.net

No they are a genuine lab with scientists; but I agree that the homepage is misleading.

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.

Thanks for sharing this, I had no idea about the existence of these things!

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.

Rich Hickey made a similar (but more clear) case against semantic versioning in his Spec-ulation keynote https://www.youtube.com/watch?v=oyLBGkS5ICk

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.

Edit: I asked the above question also on Clojure Reddit and got an interesting response: https://www.reddit.com/r/Clojure/comments/8p3d5s/datomic_ion...

DocSolver | Clojure(Script) developer | 100% remote | full-time

Check our vacancy for details and instructions to apply:

https://www.docsolver.com/vacancy.html

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

We found a great remote developer using Github. For a while I had been keeping track of high quality repos which mentioned that the author was for hire. When we finally needed to hire a developer, I reached out to the first guy on the list, and he's been working with us for more than a year now. I think a good open source track record is the best resume.

Funny thing is that they publicly own up to their performance problems in an unusual way: in their comparison with GitHub (https://about.gitlab.com/comparison/) they list "Fast page load" as a feature that GitLab lacks and GitHub has.

Nevertheless, the slowness is really annoying, especially because their product is so good on all other accounts. If scaling their database can help speed things up, I bet they will be glad to remove this embarrassing "missing feature".

In marketing terms, having fast page load would be called a "qualifier". For example: you expect a hotel to provide toilet paper. You won't pick any hotel because of it, but you will surely avoid one that doesn't.

Nice. Does anyone know their policy about following major new versions of Postgres?

I want to launch an app using the new partitioning features of Postgres 10. I hope Aurora Postgres won't be indefinitely tied to a specific major version, as is the case with Redshift.

Interesting article. I used to market such a CIS system to utilities, and indeed we considered them to be the most conservative of all. Nevertheless, their needs are very similar to those of energy utilities, but we found out how much they like to hear that water is different...

Despite the points made in the article, I still believe they are a bit too conservative, despite the nature of their product. I think it's mainly the fact that privatisation has hardly happened in the water sector, and the fact that many of them are still run like government bureaucracies. Just interact with the customer service of a water utility monopolist vs that of an energy supplier in a free market. A huge difference!

But it would have been interesting to try the approach he notes... Thanks for sharing!

Mine is also Arq > Amazon Cloud Drive for online, but I also use Arq for backup to external drive. Online backup is hourly, HDD backup once every day.

We built our (niche B2B) app on Bootstrap and keep getting compliments from customers about how good it looks. I don't mind that lots of graphic designers hate it; Bootstrap has provided tremendous value for us. I bought the templates just as a way to thank them :-)

I really like this addition. We store a lot of data for different customers, and most of our queries are only about data from a single customer. If I understand it correctly, if we would partition by customer_id, once the query planner is able to take advantage of this new feature, it will be much faster to do such queries as it won't have to wade through rows of data from other customers.

Another common use case is that we want to know an average number for all/some customers. To do this, we run a subquery grouped by customer, and then calculate the average in a surrounding query. I hope that the query builder wil eventually become smart enough to use the GROUP BY clause to distribute this subquery to the different partitions.

Do you mean something like Datomic? It has been intriguing me for a while...

Me too!

This! A local mock of AWS is sorely lacking for most services. The best one I know are Amazon's own DynamoDB and the independent FakeS3 tool which exposes an http api and saves the blobs and metadata as local files in a transparent way.