All the usual suspects, error handling, sum types, interfaces.
Just a note, I'm yet to see a problem highlighted in the section about interfaces, in particular that changing a concrete type will make it not fit the interface anymore which will result in troubles. It's often used as a tool to make the changes (e.g. change the interface, observe the compilation failure and fix all the occurrences). They way interfaces are usually defined on site as a minimal possible signature - if your code just needs one method, you define a narrow interface and that's it. That also makes it impossible to predict what kind of interface is needed at producer side.
If the argument is that you can fit a wrong struct into the interface, then again, I'm yet to see a real life manifestation of this problem.
Every library is a liability especially in terms of api. There are many example where the first take on a problem within a std lib was a bad choice and required a major overhaul. Once something is in standard library it’s literally impossible to take it back without breaking the world if you don’t control api consumers
I think this post needs better examples to show case the issue, because right now the issue is not clear. Ideally you would need an example that uses the context.Cause function, see below
The contexts and errors communicate information in different directions. Errors let upstream function know what happened within the call, context lets downstream functions know what happened elsewhere in the system. As a consequence there isn't much point to cancel the context and return the error right away if there isn't anybody else listening to it.
Also, context can be chained by definition. If you need to be able to cancel the context with a cause or cancel it with a timeout, you can just make two context and use them.
> For many business apps, they will never reach 2 billion unique values per table, so this will be adequate for their entire life. I’ve also recommended always using bigint/int8 in other contexts.
I'm sure every dba has a war story that starts with similar decision in the past
The other reason is the volume of the code being produced combined with the constant product changes. An innocent change like mixing two close but still different concepts can easily poison the whole codebase and take years to undo and may even be nearly impossible to fix if it propagates to external systems outside of direct control
I’ve made my own attempt in building a social network [0] and it’s evening running for me and my friends.
Here are few things I’ve encountered during the development:
- Based on my experience private only approach does not work. It’s all about network effects and if users can’t send their post to all friends, they’ll just move on to a different platform
- chronological friends only feed is really boring. Not that it’s bad per de, but it’s hard to convince people to stay if the service is not entertaining
It can also be me not being able to market the project right. Good luck with your attempt!
There are two sides to the argument which I think should be treated separately: a) Is it a good idea overall? and b) is htmx implementation good enough?
a) I think so, yes. I've seen much more spa that have a completely broken page navigation. This approach does not fit all use cases, but if you remember that the whole idea of htmx is that you rely on webserver giving you page updates as opposed to having a thick js app rendering it all the way it makes sense. And yes, js libraries should be wrapped to function properly in many cases, but you would do the same with no react-native components in any react app for example
b) I don't think so. htmx boost functionality is an afterthought and it will always be like this. Compare it with turbo [1] where this is a core feature and the approach is to use turbo together with stimulus.js which gives you automagical component life cycle management. Turbo still has it's pains (my favorite gh issue [2]), but otherwise it works fine
This and similar post are a bulletproof way to start a flame war.
Last time it was generics that were missing, now everyone is raging about sum times and of course explicit error is a topic of constant concern and why panics and not exceptions?
Go is well designed to build good software quickly. Easy dependency handling, good tooling, vast ecosystem.
Go is well designed to help developers with automation and help them catch mistakes, that's why it's easy to parse and all language design decisions take that into account.
It's also designed to produce a lot of code and that requires the language to be easy to understand and programs easy to tweak and that's what it provides, since you'll have a lot of developers tweaking the code.
We're in the industry of shipping different kinds of products and that imposes different constraints and results in different languages being used. Also, different people care about different stuff and languages form clusters of similar minded people around them, that's a choice too.
One of the things that surprised me in the article was their usage of J2K. They’ve been using it as part of IntelliJ, alright, but why did they have to run it headless? They’ve even mentioned that it was open sourced. And later they’ve said that they were not able to do much improvements because it was on maintenance mode at Jet Brains.
I mean, with the ressources meta has I’m sure they could have rewritten the tool, made a fork or done any other thing to incorporate their changes (they talk about overrides) or transformed the tool into something better fitting their approach. Maybe it has been done, just not clear from the article
Local state is indeed a problem that's exacerbated by swapping logic. Simple example: you have a form + a collapsible block inside or maybe a dynamic set of inputs (imagine you're adding items to a catalog and you want to allow to submit more than one). If you save the form and simply swap the html the block state will be reset. Ofc you could set the toggle state somewhere to pass it along to the backend, but that's a pain already compared to spa approach where you don't even bother with that since no state is reset.
You could you query string as mentioned in the article, but that's not really convenient when done in a custom way for every single case.
Having said that I think that a way to go could be a community effort to settle on the ways to handle different ui patterns and interactions with some bigger project to serve as a testing ground. And that includes backend part too, we can look at what rails does with turbo
My opinion is that htmx (and similar) approach is different enough to potentially require a different set of ui interactions and it usually hurts when one tries to apply react friendly interactions to it.
Just checked it, thanks for pointing to it. I think it's more of a decentralized encrypted messaging platform, and my idea was to have a way constrain the visibility of the conversations to naturally connected groups of people while giving a way to slowly expand the connections rather then fighting censorship
More or less like in real life, where you chat a lot with your friends, but necessarily with some of their friends you don't know that well. In this case you would ask your friends for the introduction and that what I've tried to model.
One other feature I've been thinking about was to make the moderation automatic in a sense of making signups possible only via invitation and putting some weight on it. Basically if you invite somebody who's misbehaving on the platform and they get flagged, you get penalized as well unless you do it first. My theory is that it should make users care about their digital surroundings.
Nice! Personally I think that the more niche social networks we have the better it is. The big problem with the mainstream networks is that they've evolved from a media to communicate and keep in touch with real people into a platform for influencers and businesses.
The common complaint I hear about instagram for example is that every second connection of yours would try to sell/teach something and that's just garbage if all you need is to keep in touch with your friends.
The main problems to tackle imo are:
- information propagation speed. This is good in case you want to get a quick update but it also a double edged sword, since this allows information attacks, trolls etc
- Scale. Anything of big scale becomes a problem by itself since it becomes economically viable to target the platform with bots, scam etc.
- Incentives. I think we should get to the point where social networks are being run by non profits
I've posted the link a couple of time, I'm working on my personal take on this problem[0]. My approach is the following:
- Slow down information propagation. Every post is visible to the direct connections, to their connections if you allow it, but no further
- No way to get a connection request from a stranger. Either you specifically allow it, or it's introduced by your direct connections
- No federation, since my idea was to have small communities
- Fully open in the sense of data formats, import/export etc. Migrating between instances is as easy exporting posts in bulk, creating an account on another instance and doing the import. You could do the bulk updates the same way
Also, it's all go + htmx just in case anyone else is also tired of modern frontend mess. I have a couple of videos on the feautures[1], if you like. The design is not great, since I wanted to focus on the idea itself
I’ve been scratching my own itch lately trying to build a communication medium that I like.
IMO the problem with current social networks is their scale and public only approach. Any network that goes this way ends up with lots of bad actors and public only approach means that it’s easy to harass people and bots are economically viable.
I’ve addressed both points [0]. Visibility of the posts is limited to direct connections, you need a proxy connection to make a new one and at the same time it’s mega easy to import/export, markdown support and apis are there etc. That was my way to get miningful discussions back.
In general, you need to look to small scale places
Small nitpick - the author mentions upsert in the beginning of the article only to "forget" about it and use it in the end (insert .. on conflict ignore) and that's the obvious solution there.
The final query is very neat though! And special thanks for mentioning "MERGE ... RETURNING" in PG17, that's really cool
I think the whole article can be generalized as following: one cannot make assumptions about relative values.
You can replace UTC with US dollars and Amsterdam time with euros and talk about conference prices. If you convert 100 euro to US dollars at the time of record creation, the price at the day may not be 100 euros anymore.
Ideally you record a tuple that allows to define value unambiguously (e.g. time 2022-02-21 9:00 timezone Europe/Amsterdam) because in this case you can always resolve the absolute time value later.
This is a typical hiccup for any business expanding into multiple locations with different parameters (time zones, currencies, units etc).
Once case that I find particularly interesting is an event that happens in different locations at the same logical (but different absolute time). Let's say you want to send an email to all your users across the global on Monday 9:00. If you want to add up to complexity, you could think about sending an email to all your users across the globe on the first working day next week.
I think the module imports apis are a python2/3 moment for node.js ecosystem. There is no clearly superior way and as a consequence not too many people care, however it hurts for real.
The proposal to disable node.js style imports will just split ecosystem and make a large part of industry stick to ancient version / make a fork. Is that really worth the gain? Just check how long it took some bigger projects to migrate from python2 to python3
Mile unit is another one of the same sort - https://en.wikipedia.org/wiki/Mile with the exception that only two kinds have survived if I'm not mistaken - US mile and nautial mile
I guess it can be very simple in US, especially if mug/cup volumes are defined in terms of a "cup" multiples, but in europe I get totally lost when I see the cup unit in the recipe since I din't know what volume it refers to
Just a note, I'm yet to see a problem highlighted in the section about interfaces, in particular that changing a concrete type will make it not fit the interface anymore which will result in troubles. It's often used as a tool to make the changes (e.g. change the interface, observe the compilation failure and fix all the occurrences). They way interfaces are usually defined on site as a minimal possible signature - if your code just needs one method, you define a narrow interface and that's it. That also makes it impossible to predict what kind of interface is needed at producer side.
If the argument is that you can fit a wrong struct into the interface, then again, I'm yet to see a real life manifestation of this problem.