The German Wikipedia page[1] about the Z1 also contains a quote from Kurt Pannke, who Zuse told about his plans for the computer.
"Oh, Mr Zuse, there is absolutely nothing left to invent in the field of calculating machines. But you are a nice young engineer, I'll give you 1,500
Reichsmarks and when you have come up with something, show it to me."
(Translated by Deepl)
I like the "640K ought to be enough" vibe of that statement :)
It is in regards to the GDPR. If you're a European vendor and process PII, you must ensure some level of data protection. If you want to be on the safe side, you'll pick European providers instead of US hyperscalers (who have EU data centers, but are still US owned).
True, but we should also remember that some services like the fast responses and the image generations (may?) run in US data centres also for Mistral. So that part of the data, in principle, may end up in the ends of other extra European countries.
This said, I am really supportive of Mistral, like their work, and hope that they will get more recognition and more EU-centric institutional support.
GDPR doesn't stop personal data being stored. It handles whom it can be shared with, when it has to be deleted, and only collect as much data as required. Also gives transparency to the users about their data use.
And if I were to give over personal information to an AI company, then absolutely I'll prefer a company who actually complies with GDPR.
As a metaphor (well, a simile) think of it like if they were providing you with an FTP server or cloud storage. It's your choice what, if any, personal data you put into the system, and your responsibility to manage it, not theirs.
As to what to do if you, with a customer's permission, put their PD (PII being an American term) into the system, and then get a request to delete it... I'm not sure, sorry I'm not an expert on LLMs. But it's your responsibility to not put the PD into the system unless you're confident that the company providing the services won't spread it around beyond your control, and your responsibility not to put it into the system unless you know how to manage it (including deleting it if and when required to) going forwards.
Hopefully somebody else can come along and fill in my gaps on the options there - perhaps it's as simple as telling it "please remove all traces of X from memory", I don't know.
edit: Of course, you could sign an agreement with an AI provider for them to be a "data controller", giving them responsibility for managing the data in a GDPR-compliant way, but I'm not aware of Mistral offering that option.
edit 2: Given my non-expertise on LLMs, and my experience dealing with GDPR issues, my personal feeling is that I wouldn't be comfortable using any LLM for processing PD that wasn't entirely under my control, privately hosted. If I had something I wanted to do that required using SOTA models and therefore needed to use inference provided by a company like Mistral, I'd want either myself or my colleagues to understand a hell of a lot more about the subject than I currently do before going down that road. Thankfully it's not something I've had to dig into so far.
I can still remember when the first inkjet printers came onto the market as the successor to dot matrix printers. I wanted one because, as a child, I thought it would allow me to imitate my handwriting with a fountain pen and I would never have to write my homework by hand again...
I'd emphasize that it's a problem with your particular code base. If you set it up correctly, all dates are properly parsed at the boundaries and you would only deal with one type of date inside your app. I'm working on a large Clojure app with a lot of date handling and never had any issues. For me, a date is always juxt/tick date.
The parent comment illustrates the problem with one clear example. In real-world code functions pass around amorphous maps, they add, subtract and transform fields. There is no way to know what's being passed around without reading the source of the whole chain.
Statically typed languages reduce the need to know how the data is structured or manipulated. The market has clearly chosen this benefit over what Clojure can provide.
Yes and no. Statically typed languages only know that data stored in some piece of memory was conforming to some kind of shape/ interface when it was first stored there. That's why tricks like SIMD Within A Register (SWAR) work at all. E.g. when you need to parse temperatures from string input very fast like in the 1BRC:
https://questdb.com/blog/billion-row-challenge-step-by-step/
How does your type system help there?
With static typing, you are doing specification and optimization at the same time, which is maybe necessary because compilers and languages are not sufficiently smart but also because of this mix it complicates reasoning about correctness and performance. Also static typing introduces a whole universe of problems with itself. That's why we have reflection or stuff like memory inefficient IP address objects in Java:
For a simple IPv4 address normally representable using 4 bytes/ 32 bits Java uses 56 bytes. The reason for it is Inet4Address object takes 24 B and the InetAddressHolder object takes another 32 B. The InetAddressHolder can contain not only the address but also the address family and original hostname that was possibly resolved to the address.
For an IPv6 address normally representable using 16 bytes/ 128 bits Java uses 120 bytes. An Inet6Address contains the InetAddressHolder inherited from InetAddress and adds an Inet6AddressHolder that has additional information such as the scope of the address and a byte array containing the actual address. This is an interesting approach especially when compared to the implementation of UUID, which uses two longs for storing the 128 bits of data.
Java's approach is causing 15x overhead for IPv4 and 7.5x overhead for IPv6 which seems excessive. Is this just bad design or excessive faith in static typing combined with OOP?
> There is no way to know what's being passed around without reading the source of the whole chain.
But that's not what a Clojure dev would do.
1) We use Malli [0] (or similar) to check specs and coerce types if needed at every point. Checks can be left on in production (I do), or disable–up to you.
2) If the coercion is difficult, use something like Meander. [1]
3) If even that isn't straightforward and you need actual logic in the loop, use Specter. [2]
4) If you're not sure what going on at intermediate steps, use FlowStorm [3].
5) But you're going to be processing a lot of data you haven't seen before! Use, Malli with test.check [4] and make use of property-based testing with generators.
None of this is "advanced" Clojure, this is bread-and-butter stuff I use every day.
6) Need a Notebook-like experience to get better visualization of intermediate data? Use Clerk [5].
7) Need special checks on API usage within your codebase? Use clj-kondo [6] with custom linters. They're less than 10 lines each.
Unlike default-mutable languages, or typed, it's safe and easy to use libraries with Clojure and they tend to have very little churn. Total opposite from Python or JavaScript (if you're used to that).
It's almost impossible to give the impression of what it is like to develop with Clojure if you've only ever used languages with static typing, or languages from the Algol family.
Honestly, I hated Clojure's syntax at first BECAUSE I COULDN'T READ IT, and I loathed "structural editing." After 2-3 weeks, I read it just fine and it's hard to remember I ever couldn't do so. Now I like it, and structural editing makes it so easy to change your code, I couldn't live without it at this point.
Basically, all my "fears"/dislikes were unfounded—it was a skill issue on my part, not a problem with Clojure.
Most people don't use those libraries, nor do most libraries use those libraries. They don't help me understand most code out there beyond my carefully orchestrated app code. I'm back to reading the source.
But this long list of runtime libraries is definitely a downside of Clojure. It's people trying to grapple with things mostly solved with static typing where you can just write a(b(c())) and it fails before it hits your fancy yet-another-thing-to-learn Malli library in runtime.
They might be great libraries, but you're only seeing one side of the trade-off.
I learned Emacs with evil-mode, paredit, nrepl/cider, and Clojure in my early 20s and used them for six years, and I was pretty gung-ho about it like you. But eventually I started using static typed languages for work and decided that I couldn't go back. It's like trying to read Javascript after you've spent five years with Typescript. You just think "wow, I can't believe I did that for so long."
And I'm remembering times I've used paper and pencil to figure out how map is being transformed as it's passed through library code. I don't miss that.
Apparently I and my fellow Clojure devs aren't real Clojure devs. Or perhaps you mean "true" clojure developers, or "good" clojure developers. (cf. https://en.wikipedia.org/wiki/No_true_Scotsman)
And even if we were Clojure devs we've inherited multiple big Clojure codebases that were apparently written by non-Clojure devs, and heavily refactoring is not on the to-do list.
This is really nice, and I am impressed how much effort went into the documentation, to make the demo nice and interactive.
At first I thought this is something new, because it's cool and I haven't heard of it, even though I'm coding in Clojure for about 3 years now. But this project is already 10 years old and hasn't received much attention for the last few years, which is a pity.
I wish it was coming with Calva, my favorite Clojure tooling in VS Code.
> I wish it was coming with Calva, my favorite Clojure tooling in VS Code.
You have this basically already. When you move forms in/out on the indentation levels, notice how the brackets/parenthesis automatically re-arrange themselves? That means it's working :) https://calva.io/parinfer/
Damn, you're right, I didn't notice the notice, nor am I a daily Calva user.
But so what, is there no automatic balancing of parenthesis in Calva? That seems to diminish the value from the extension by a lot, I couldn't imagine coding Clojure and having to manually balance parenthesis.
Something about VSCode makes it hard to add in. I think it lacks the right APIs.
Also, the main maintainer of Calva doesn’t use Parinfer, and so isn’t very motivated to add it either. But if someone were to contribute it, I imagine he’d be very receptive.
Quick (and cheap?) hires are not necessarily good hires.
In my experience (and my theory) developer productivity can range from 0.5x to 5x and more, and those developers in the upper range tend to look for certain programming language which they enjoy, like Rust, Go, Elixir, Scala and Clojure. They are hard to get if you are on a "boring" stack like Java, NodeJS, PHP.
So if you might need to invest some time and money to find the right people, but at the end you make a better deal: Even if the salary is twice as much, the productiviy is even more. Additionally less people means less communication overhead, which is another advante.
I find the opposite to be true, that best and most productive developers tend to be more language agnostic than average, although I'm not saying they don't have their preferences.
Specifically, I find language evangelists particularly likely to be closer to .5x than 5x. And that's before you even account for their tendency to push for rewriting stuff that already works, because "<insert language du jour here> is the future, it's going to be great and bug free," often instead of solving the highest impact problems.
I've worked with language zealots and it's awful. Especially the ones with the hardcore purely functional obsession. But that can apply to almost anything: folks that refuse to use anything but $TECH (K8S, FreeBSD, etc). Zealots like this general care less about delivering and more about what they get to play with.
Then you have the folks that care about delivering. They're not language agnostic, they have strong opinions. But also: they communicate and collaborate, they actually CARE: they have real empathy for their users and their co-workers, they're pragmatic. Some of these folks have a lot of experience in pushing hard to make things work, and they've learned some valuable lessons in what (not) to do again. Sometimes that can manifest as preferences for languages / frameworks / etc.
It's a messy industry, and it can be extremely hard to separate the wheat from the chaff. But a small team with a few of those can do truly game changing work. And there's many local optima to be had. Get a highly motivated and gelled team using any of: Elixr / Typescript / Zig / Rust / Ada / Ocaml / Scala / Python / etc, and you'll see magic. Yes, you don't need fancy tech to achieve that. There's more than a few of those writing C for example, but you're unlikely to see these folks writing COBOL.
I agree with you but also agree with the above, if youre stuck permanently in some tangled codebase with a boring language/style, the really good programmers tend to find something more fun to work on - unless they can bring their new skills/experience to bear. personally I'll only go back to doing boring stuff if i can't find a job doing the fun stuff
Yeah, this has been my experience too. The mentality seems similar to "productivity hackers" who spend more time figuring out the quickest, most optimal way to do a thing than people who just do the thing.
One of the things I've noticed is that people who just do the thing, take note of what's annoying, and fix the most annoying things about a process later on tend to make the most impressive dents in a system or process, especially since they spend time mulling over the idea in their head and so by the time they implement, they aren't "zero-shotting" a solution to what's generally a complex issue.
100% agree. You have hit the nail on the head. I went from Common Lisp to Go to now Rust and find that Rust devs are the best so far on average.
There are fewer of them, they ask for more money, but they really are exceptional. Especially Rust devs right now because there are not a lot of jobs you only find the most passionate and the most brilliant in that space. A short window though which will close as Rust gets more popular to startups, take advantage of it now.
I'm running two clusters on it, on for production and one for dev. Works pretty good. With a schedule to reboot machines every sunday for automatic security updates (SuSE Micro OS). Also expanded machines for increased workloads. You have to make sure to inspect every change terraform wants to do, but then you're pretty save.
The only downside is that every node needs a public IP, even though they are behind a firewall. But that is being worked on.
Love it. Just the other day I have been looking for something like this.
What preconditions must be met to use this with an existing app? What tech stack is supported (e.g. only Typescript and React and ...)?
The docs say it's framework-agnostic. I assume then that the editor would only be used for editing css, not html, but I'm sure the founder can correct me if I'm wrong.
I'm also curious how they determine where in source the code needs to change, because you could have (a) external stylesheets, (b) a stylesheet in the html head, (c) tailwind classes, (d) some css-in-js variant, or even (e) direct style application of dom elements in your javascript.
> I assume then that the editor would only be used for editing css, not html
It does edit html. Inserting html elements in this case.
> I'm also curious how they determine where in source the code needs to change
Right now we're editing inline-tailwind because it's the easiest option. It only edits the existing tailwind styles so there could be some interaction with existing styles that have higher-priotity.
The plan later is to have users configure how they want their styles written. We have full code access to be able to edit css stylesheets or inject our own.
Would be interesting to reconstruct that using a 3D printer... if anyone has too mich time to spare.