ptttr

what great answers could look like here?

A one way to address that is via tooling (e.g. to visualize state across time) but maybe there’s something more fundamental to be solved here? Or is it more about current tooling capabilities?

What? Does the idea of employment seem kinda novel in this take?

You can gain significant impact multipliers by focusing human attention on a single goal. And not many things do that better than throwing money at a problem.

However with individual's reach extended, the complexity and frequency of collaboration only increases so naive approaches get overstretched and, eventually, break.

> you should really use a well designed layer between yourself and FDB. A few are out there.

Any recommendations? All I could find is https://github.com/FoundationDB/awesome-foundationdb#layers - not sure how complete and up-to-date that list is.

If a person belongs to the society, then sick, suffering people are not a value but a cost and killing them becomes net gain for society. It's very dangerous to give away body autonomy freedom to the collective as it could be potentially weaponised to target not only sick, old and poor but political opponents as well.

I understand your worry, but I've had a quite opposite take on this.

I think we can agree that it's not that hard to find ANY job as an experienced developer. However it's much more difficult to find a great, satisfying job. For that you need to navigate around a lot of corpo-bullshit type of projects, and Clojure has served me well as a useful filter in doing that. My reasoning is that Clojure is niche enough that when company is using it, you can assume that it's due to a deliberate technical choice, and not just because of its popularity. That tells me two things that are symptomatic, in my opinion, of a healthy tech company culture: - tech decisions are made by engineers, not by top-level executives, - their conclusions and bets align with mine because we all see and agree on Clojure's edge over more popular solutions.

Admittedly, there's always a risk that someone just followed the hype and got out of their depth but I think this risk is relatively small, because Clojure's no longer a new kid on a block and choosing a tech stack is a major decision and usually done by senior tech leadership, hopefully less hype driven.

Of course, Clojure is no silver bullet and it's just a tool that gives you enough rope to hang yourself. Messy codebases are just as possible as in other languages, especially when the team is new to lisps that are very different from mainstream languages, but that's a nature of software development - you learn with the experience. I do cringe when I look at the Clojure code I wrote when I was just starting and wasn't fully grasping Clojure's way of thinking, but the more I use it, the more I come to appreciate how powerful it is.

Great intro that made it click for me: https://www.youtube.com/watch?v=vK1DazRK_a0 (Solving Problems the Clojure Way - Rafal Dittwald, 2019)

Having said that, no software project is ever complete and so isn't Clojure as an ecosystem. The tooling is constantly evolving and new patterns are emerging. What's great about Clojure open-source community is that everyone seems to share the desire to harness complexity and Rich Hickey has convinced each one of us at some point that the way to do it is through simplicity https://www.infoq.com/presentations/Simple-Made-Easy/

Even within Clojure's community there's a diversity of approaches, and I think it's necessary to improve and evolve. The more recent trend, I've noticed is that the community is converging at Data Oriented Programming that's applicable in other languages as well, but has always been at the core of Clojure's mindset that is especially well suited for it.

Dropping some links relevant about DOP: https://youtu.be/8Kc55qOgGps?t=4175 (Rafal Dittwald, “Data Oriented Programming” 2022) - whole talk is valuable, but long so I'm linking to the most juicy snippets) https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.ht...

Moreover, Clojure has already grown past the threshold of being just a niche toy and has sufficiently big market that it won't die off anytime soon. When you study history of programming languages, you'll notice that it's enormously difficult thing to do for an emerging player, especially without big corporate backing. And Clojure is as grassroot as it gets: https://clojure.org/about/history

I do definitely recommend Clojure - I've switched to it in 2019 coming from Rails and JS and never looked back.

Clojure's job market is great, there's no shortage of offers, even for newcomers and it has been the top paying lang in stackoverflow surveys for years https://survey.stackoverflow.co/2022/#section-salary-salary-...

However, the most important part is that Clojure is a very powerful piece of technology that made me reevaluate what software engineering really is. You can efficiently use Clojure for both backend and frontend with easy access to libraries from JVM and npm so you will never run into the problem, common in other niche langs, of too few libraries. Nevertheless, Clojure's own ecosystem is filled with many great, cutting-edge ideas that you wouldn't find working so well elsewhere. The community is very welcoming, growing and diverse with people coming from all different programming backgrounds - all sharing the disillusionment with other programming languages and determination to find and build a better way.

https://jobs-blog.braveclojure.com/2022/03/24/long-term-cloj...

I went from Ruby on Rails, then Javascript/Typescript to finally land at Clojure in 2019 and I'm not looking back.

Clojure has been a perfect fit for my needs, very similar to what you describe, and neither Rails nor JS have been able to match that.

With Clojure/Clojurescript you get:

- sane, single lang for both backend and frontend (much more seamless than JS/node),

- REPL-Driven-Development - immediate feedback loop translating to huge productivity boost,

- a very refreshing approach to programming,

- access to both two largest ecosystems JVM, npm and of course clojure's own amazing libraries,

- vibrant and diverse community, converging people from all different programming backgrounds,

- much, much more.

Rails and Django are a bit tied to 2005ish MVC paradigm and while it's reliable and gets job done, it comes with compromises on flexibility and user experience - making it hard to be competitive in 2022 as a solo founder. Clojure on the other hand is known for empowering single/few developers to outcompete much larger teams.

Seriously, forget about Rails and Django and just focus on Clojure.

Would you say, for someone starting in the same place as OP, that it's better to skip K8s entirely and just go with Nomad?

The punctuation serves a purpose of separating thoughts from each other and conveying the tone. In messaging apps you separate thoughts by sending them as separate messages and convey the tone through emojis.

In the time-stressed and client-diverse environment of synchronous text conversations punctuation becomes redundant.

Nowadays, you can get VSCode support for Clojure pretty much out of the box with calva[1] extension working together with clj-kondo [2] almost without any configuration. It works great - I've switched over from Cursive and I'm not looking back.

[1] https://calva.io/ [2] https://github.com/borkdude/clj-kondo/blob/master/doc/editor...

You're on to something.

Low code platforms, at their core, allow you to define the software with data (from predefined components usually through UI) and that's how they enable super productivity, until you hit a wall.

Data Declarative programming paradigm could potentially achieve the same levels of productivity without its limitations but it's very difficult to get the right implementation.

The most interesting development in this area I had found, is Fulcro Rapid Application Development Tools [1] - a fullstack clojure framework that's performant, declarative and extensible. RAD is still alpha but it bases on battle-proved Fulcro. Once you hit the limits of declarative RAD you can easily extend it with regular Fulcro components which are, in their essence, a cheap abstraction over React/React Native components - offering industry standard performance.

[1] https://github.com/fulcrologic/fulcro-rad

The most humanitarian solution to the collapse seems to be a combination of both:

Global Universal Basic Income and Global Carbon Tax.

Global GDP [1] = $142000bn

Human population [2] = 7.8bn

GUBI = $100 * 12 months * 7.8bn = $9360bn

$9360bn / $142000bn = 6.59% of global GDP

6.59% is below the common tax rate. If it could end all wars forever, wouldn't it be worth it?

Can you survive on $100 per month? Barely anywhere so people would still work but it would be a big step towards rebuilding trust among humanity.

We can only avoid violent dystopia if we solve communication and resource distribution problems.

[1] https://www.google.com/search?q=global+gdp

[2] https://www.google.com/search?q=human+population

> UBI is one of those ideas that is theoretically awesome but doesn't survive contact with reality

You don't know that - you just base it on your theory.

Of course, every idea gets perverted by current political system, but the problem is often not the idea itself. Huge appeal of UBI is that it's simple hence easier to control. Taxes were supposed to be simple too and yet they got overcomplected to serve the special interests. The danger of abusing UBI for political gains is as real as it happened with taxes, but it doesn't mean the idea is inherently bad - we just have an inefficient and harmful government system and fixing it should be a priority if we want anything nice like properly implemented UBI. Another Yang's idea, Ranked Choice Voting could at least mitigate some of the issues like political bipolarity.

> Probably minimum wage would have to be raised so that people would want to work as a maid or McDonald

The beauty of UBI is that government mandated minimum wage, with all its drawbacks, wouldn't be needed anymore. People would be able to refuse shitty job offers and not starve. Ultimately, employers would have to raise wages but not because of the law but because of workers' better negotiation position.

It needs to be universal so it doesn't penalize work. If there's any set limit, it'll create pathologies around it like people not taking up a job because it would lead them to loosing money/time.

The downsides are not clear to me as well. The only argument I could think of is a nationalistic sentiment that nations should live & work together but I find it poorly motivated in a global world. I see, however, a lot of benefits of easing out the wealth distribution geographically. And you rarely want to live in the cheapest 3rd world country far away from your family. It's a CoL-vs-comfort balance you need to figure out for yourself - no calculator will be 100% accurate here.

I've been riding this ride through most of my career, working remotely for western startups mostly from Poland. In the end, I don't care how "fair" your compensation policy is - it all comes down to the best alternative offer.

This submission points to a pretty landing page instead of directly to the article, but of course the discussion stays relevant.

If you're looking for potential alternatives to REST and GraphQL, I suggest checking out how Fulcro [1] works together with Pathom [2] using EQL [3].

It's a data-driven full-stack application programming system centered around graph-based UI and data management implemented in Clojure [4].

While React lets you be declarative about your UI, Fulcro lets you be declarative about your entire system - both backend and frontend.

Check out this discussion too: https://news.ycombinator.com/item?id=21743720

[1] https://fulcro.fulcrologic.com/ [2] https://github.com/wilkerlucio/pathom [3] https://github.com/edn-query-language/eql [4] https://clojure.org/

The original question made this mistake probably because the poster didn't know it but Pathom is the actual alternative to GraphQL-based APIs. Datalog solves a subtly different problem of querying the data, while Pathom/GraphQL/REST is about exposing the data (interfacing?) as API.

It's more like:

Pathom vs GraphQL-based API (vs REST)

and

Datalog vs SQL (vs NoSQL)

The mainstream is in the process of migrating from REST to GraphQL, but I think Pathom could be the black horse in this race. Just watch the last part of Wilker Silva's The Maximal Graph talk to see the potential: https://youtu.be/IS3i3DTUnAI?t=2080

Rails were successful in the 2005-2015 era of server-rendered HTML but today MVC + REST API might not be enough anymore for solo founders to compete in multi-platform, client-rich reality.

After spending of +4 years working professionally with Ruby on Rails I've grown aware of its limitations. I've spent a long time searching for its successor in my programmer's toolbelt. I've waded through numerous Javascript frameworks yet every one of them proved to disappoint me after taking it for a spin. I've finally arrived at Clojure at the beginning of 2019 and it has been really refreshing. I love how well designed the language is, how mature the community is and I am amazed by the quality of the ecosystem.

You can see my repo-graveyard made along that journey here: https://github.com/roterski/sonder-syncrate

My personal bet for the next killer-app in web development is: Clojure[0] + Fulcro[1] + Pathom [2] + Crux [3].

[0] Love Letter To Clojure - Gene Kim (Clojure/conj 2019) https://www.youtube.com/watch?v=5mbp3SEha38

[1] Fulcro links and resources: https://www.reddit.com/r/fulcro/comments/dtzhsm/fulcro_links...

[2] The Maximal Graph - Wilker Silva (Clojure/conj 2019) https://www.youtube.com/watch?v=IS3i3DTUnAI

[3] https://opencrux.com/

> With this, the international research team has also made an important step towards practical applications such as a future quantum internet, since high-dimensional quantum systems can transport larger amounts of information than qubits. "This result could help to connect quantum computers with information capacities beyond qubits", says Anton Zeilinger, quantum physicist at the Austrian Academy of Sciences and the University of Vienna, about the innovative potential of the new method.

I wonder how a quantum internet would be different than the binary one.

I would add cryptic error java stacktraces to this list but, as someone who recently overcame the "java is gross" bias, I'd say benefits of JVM and its vast ecosystem outweigh the cost.

I have a feeling that this book is _the_ advice. It's literally in the subtitle: "Upgrade Your Reasoning and Make Better Decisions with Mental Models". I imagine mental models have a lot to do with managing and balancing one's life.

That's what I love about Clojure culture. It started as an acknowledgment of weaknesses of dominant solutions (isn't ORM an anti-pattern?) and lead to this beautiful story of open source: Yesql -> HugSQL -> PugSQL

It's interesting to watch as it clashes here with one-way-of-doing-things Python culture.

The author mentions it in the first paragraph, just chooses to focus the article on the design part: "At this stage, I'm going to assume you've conducted some user research or at the very least, spoken to potential customers to test your assumptions. That way you'll be much better positioned to turn your ideas into actual design."

The worst part about comments is that they just add a cognitive load of reading and parsing extra lines of text.

What if the underlying logic changes? Do I need to update the original witty comment as well?

How do I know if the comment is still relevant? No compiler nor tests will tell me that and now I'm left with a task of parsing a language with much more degrees of freedom (English), without any support from the IDE. It becomes even harder in international teams.

That sounds like a market ripe for disruption - imagine a competitor that follows software engineering best practices.