> When I enquired ChatGPT why it said "no", this was the response:
> "Because your question was phrased in a way that depended on which year we’re currently in, and I initially answered it generically: “If today is 2025, then 2026 is next year.” I started by explaining the conditional logic instead of immediately stating “Yes,” which made the answer sound like No at first. Then I clarified based on the actual current date (December 2025) that yes, 2026 is next year. So the short version: My first sentence emphasized the logic, not the direct answer. That caused confusion."
I seem to remember Bill Clinton sometimes also talks like this
Also this UI / UX issue isn't just a problem with Spotify but iTunes (Apple Music) to! So I guess it's just a general trend that started for no good reason.
In iTunes, the table view is now only for the main page, and has been gone from the search and the playlist pages. It's so inconsistent. You get the nice old-school table view when you're on default but then when on the search page they display it on grid view. On the playlist page, you're like on this weird half-table half-grid view.
Out of the 4 instruments that are still locked I'd reckon three would definitely be Jupiter 8, Juno, and TR-909. I can't confidently guess the last one though.
I'll try them later at home. Do you think they'll sound as good as the analog counterparts? Hahahaa
I second Bazel. People keep on mentioning how steep the learning curve is, but the conceptual model is really simple, elegant, and intuitive.
What is steep is the technical know-hows:
1. When things don't work as expected. For example, while it worked flawlessly with languages that it natively support such as Java, that wasn't the case for other languages such as Javascript or Python.
2. When you have to do something advanced such as building custom Bazel rule. You'll need to understand Bazel internals and unfortunately the documentation isn't very intuitive and also somewhat sparse.
It doesn't do union types yet, but it's got type inheritance, type inference, type-safe joins (with its "relation" feature). It's quite cool what you can do with it when you can express complex domain with the language.
I agree with your statement that concepts like formal-proofs is underrated. Fortunately, one of the general trend that I'm seeing going forward is the birth of programming languages with more and more sophisticated type systems. In these languages type systems do not only capture object types (eg., int, string) but also various other aspects.
For example functional languages and their monadic construct supports capturing various interesting aspects. This allows for really useful feature such as capturing concurrency behaviour (Future/Promise) and possibility of returning errors (Try), at compile time.
Then there's Rust where memory ownership can be reasoned about at compile time.
Languages such as Idris allows to declare a type that is dependent on the value (eg., declare that this function "x() can only return odd numbers?)
I also happen to work in a company where we try to bring type-safety to the databse world with our product TypeDB.
I think this trend is very good to see - stronger type-system = safer code. In a way the stronger type system a programming language has, the more it can validate at compile time. And therefore, we can say that such language somewhat provides what formal proof / formal verification systems ought to provide, but in a practical setting.
I don't think there is any "standard" that strictly governs the implementation of a CQRS system. We just need to be aware of the nuances of the fault-tolerance aspect in distributed systems:
- idempotency is ONLY a hard-requirement if the events are transmitted via lossy channels such as network. ID is one out of several ways to ensure idempotency. If you're implementing CQRS for your distributed system then it's needed
- otherwise, if the events aren't lossy and can be processed atomically, you don't need to ensure idempotency. think implementing CQRS for your user interface where events are just transmitted between different objects in memory rather than via network
I can say we're one of the companies that have successfully embraced event-driven design. We're Vaticle and we're not a microservice shop - rather, we're building a database software called TypeDB. The internals are quite event-driven mainly realised with the actor model and event-loop concurrency.
It has allowed us to scale mainly in two ways: maximising parallelism with respect to CPU, and doing other works while waiting for an RPC call to return.
Event-driven architecture by nature is more parallel and efficient, but comes with a weaker consistency guarantee when it comes to the ordering of events coming from multiple parallel sources.
In my experience, people tend to fall prey to these pitfalls, and ended up resorting to inappropriate workaround such as global locks and ad-hoc retry mechanism. These are most commonly done when trying to aggregate works coming from concurrent producers or when needing to handle communication failures.
In fact, communication failures and downtimes are the most prominent problem in microservice particularly when you need your data to be inserted into multiple data sources in an atomic way.
This is an inherent issue in distributed systems and you have to think what's the atomic unit of data that you wish to insert, and design your system based on this hard constraint. Making the operations atomic, idempotent or revertable are some of the solutions you may want to investigate, but the moral of the story, is that you need to make sure these additional complexities are justified.
For us as a company, we decided on the event-driven architecture after knowing not just the benefit, but also the cost that I've outlined above.
For simpler applications that don't need to be a) real-time and b) handle crazy amount of loads, think small internal applications, small business ecommerce website, I would resort back to good old non-event-driven system since it's the more pragmatic option.
I've seen several companies building an event-driven architecture even when they know there's no way they would need to scale beyond serving several thousands of request per hour in the next two years. I think they would've been better off with a simpler, synchronous model.
> "Because your question was phrased in a way that depended on which year we’re currently in, and I initially answered it generically: “If today is 2025, then 2026 is next year.” I started by explaining the conditional logic instead of immediately stating “Yes,” which made the answer sound like No at first. Then I clarified based on the actual current date (December 2025) that yes, 2026 is next year. So the short version: My first sentence emphasized the logic, not the direct answer. That caused confusion."
I seem to remember Bill Clinton sometimes also talks like this