I only watch the go part, and I'll say that in 3 years working with I might have had at most 3 times nil pointer crashes in prod, in which took about 30 min between getting fixed and deployed.
There are linter which helps prevent most of if not all crashes (just keep in mind to run linting and compile the binary it would still be ages faster than anything rust I have ever compiled). His argument is weak, and not simple.
I'll give that type system in golang is too simplistic sometimes, and a more complex could help to express better some use cases.
Still go for a person coming from a interpreted language is a solid choice by being MUCH MUCH simpler.
> 3 years working with I might have had at most 3 times nil pointer crashes in prod
I've been running a rust app for my personal trading app and a small service at a very large FAANG company for more than 3 years, and guess what I'm yet to see a nil crash.
Agree, people should understand why they are picking a language. If it is to learn new language that is fast, compiles to a binary (also fast) and has a nice onboard experience for a person coming from a interpreted language (which is the topic of thread) go fits nicely.
Rust is not always the answer just because it has "no nil exception". The correctness of Rust comes at a cost as well.
> "biased" -- any evidence of that? And what if that is biased? Ever heard of "academic freedom"?
Evidence of bias again China? There are plenty outlets that have bias against China, where every mundane action take by the Chinese party is taken as "debt-trap diplomacy," "neo-colonialism," or "strategic expansion".
> "genocide" -- how on earth is that relevant to this topic?
This is topic about "China intimidated UK university to ditch human rights research" so of couse accusation of genocide occurring in Chine is in the topic since GP arguers that episode might be retaliation against anti-Chinese bias.
> Dude, the ambiguity and instant whataboutism makes your account extremely suspicious
I love that every mildly neutral take on China is answered with these. Tell me about whataboutism.
An actual socialist would say the state in capitalist society provides a legal and infrastructural framework that supports business enterprises and the accumulation of capital, so it is business as usual. But feel free to throw words around as they mean nothing.
> I think its only a matter of time where legislation, lawsuits and fines will follow.
That depends where you are. In the US and anywhere where it can exert political force that won't happen. The US administration acts as a de facto lobbying arm for big tech giants like Google, and any attempt to regulate is met with threats of embargo.
> It's actually because China is lowring the requirement/quality for delivery and makes everthing for the comsumer market to degrade rapidly so that the manufacturers has the chance to involve because of the involving needs for newer/better products.
Isn't the requirements set by the company outsourcing to China? Because as far as I can tell in China you can produce with all ranges of quality so it feels a bit too simplistic to blame "planned obsolescence" to China alone as the whole chain profits from it (besides the end-user of-course).
As a developer interested in zig it is nice to see books being release, but I'd be a bit resitant to buy anything before zig reaches 1.0 or at least when they settle on a stable api. Both the builder and the std keep changing. Just 0.15 is a huge breakage. Does anyone knows how those changes would affect this book?
People are doing real companies with Zig (e.g. Tiger Beetle) and important projects (e.g. Ghostty) without the 1.0 backward compatibility guarantee. Zig must be doing something right. Maybe this also keeps opinionated 9-5er, enterprise type devs out of it as well which might be a good thing :).
Are there other notable commercial companies/projects than Tiger Beetle relying on Zig? According to public information, Tiger Beetle are about eight employees with a single customer, isn't it?
I'm not sure how many customers that Tiger Beetle have but I really hope they are successful. It would be great to see such a quality focused engineering org make it. They are basically doing what many devs really want to do - make the highest quality and fastest stuff possible - instead of banging out random features that usually no one actually cares about. I don't have a use case for their tech right now, but the moment I have a need for anything in the vicinity I'll be checking it out..
We’re doing pretty well as a business already, contrary to Rochus’ comment, which is not accurate.
Our team is 16, we have $30M in investment, and already some of the largest brokerages, exchanges, and wealth managements, in their respective jurisdictions are customers of TigerBeetle.
We have a saying:
“Good engineering is good business, and good business is good engineering.”
At least in TigerBeetle’s experience, the saying is proving true. We really appreciate your support and kind words!
Go doesn't belong in this discussion.its a better java, c#, python and not much more. It doesn't work for 24/7 or for performance sensitive applications.
> Go doesn't belong in this discussion.its a better java, c#, python and not much more. It doesn't work for 24/7 or for performance sensitive applications.
The claim is factually backwards. Go significantly outperforms Java, C#, and Python (~10x faster than Python, lower memory usage than C#), and runs successfully in countless 24/7 production systems including high-throughput APIs and distributed services.
The actual valid concern, which made me question its suitability, is that Go wouldn't be appropriate for TigerBeetle's specific real-time requirements. TigerBeetle is a financial transaction database requiring deterministic, predictable microsecond-level latencies with strict timestamp ordering across a distributed consensus protocol. Go's garbage collector introduces unpredictable pauses that would likely violate these hard real-time guarantees.
Thanks for the hint. According to public sources, Bun's runtime infrastructure and bindings are written in Zig, but it uses Apple's JavaScriptCore engine written in C++ (i.e. Zig is essentially used in a thin wrapper layer around a large C++ engine). Bun itself apparently struggles with stability and production readiness. Oven (Bun's company) has around 2-10 employees according to LinkedIn.
Lightpanda looks interesting, thanks for the hint. According to public sources, behind the development is a company of 2-10 employees (like Bun). The engine uses parts of the Netsurf browser (written in C) and the V8 engine (written in C++), and - as far a I can tell - is in an early development stage.
I guess almost every single language out there have at least one "real" company using it, so yeah, Zig is still mostly hype and blog post praising its awesomeness.
As a Zig adopter I was rooting for this because even though there is the official documentation and some great community content, it's nice to just kick back and read a well written book. I'm also very happy with other Manning titles; they have built a high level of trust with me.
To answer your question is it too early. My expectation is that the core language, being quite small by design, will not change that much before 1.0. Some things will, especially async support.
What I think we will see is something like a comprehensive book on C++14 . The language is not much changed between now and then, but there will be new sections to add and some sections to rework with changes to the interface. The book would still be useful today.
Not a perfect analogy because C++ maintains backwards compatibility but I think it is close.
Do you have a history we can look at to see how good you are at predicting this for programming languages? Like say, some 2020 predictions you had for languages which would or would not ship 1.0 by 2025 ?
I made a set of predictions for Rust in 2022, nearly all of which turned out to be correct. And I was publicly confident Go and Rust would be massive when they reached 1.0. I was right on both counts.
But I will also admit I don’t follow developments in zig as closely as Rust. I’ve never written any Zig. And in any case, past performance isn’t indicative of future performance.
I could be wrong about this prediction, but I don’t think I will be. From what I’ve seen Andy Kelley is a perfectionist who could work on point releases forever. But his biggest users (tigerbeetle and bun especially) will only be taken seriously once Zig is 1.0. They’ll nudge him towards 1.0. They can wait a few years, but not forever. That’s why I guessed 4 years.
> But his biggest users (tigerbeetle and bun especially) will only be taken seriously once Zig is 1.0.
TB is only 5 years old but already migrating some of the largest brokerages, exchanges and wealth managements in their respective jurisdictions.
Zig’s quality for us here holds up under some pretty extreme fuzzing (a fleet of 1000 dedicated CPU cores), Deterministic Simulation Testing and Jepsen auditing (TB did 4x the typical audit engagement duration), and is orthogonal to 1.0 backwards compatibility.
Zig version upgrades for our team are no big deal, compared to the difficulty of the consensus and local storage engine challenges we work on, and we vendor most of our std lib usage in stdx.
> They’ll nudge him towards 1.0.
On the contrary, we want Andrew to take his time and get it right on the big decisions, because the half life of these projects can be decades.
We’re in no rush. For example, TigerBeetle is designed to power the next 30 years of transaction processing and Zig’s trajectory here is what’s important.
That said, Zig and Zig’s toolchain today, is already better, at least for our purposes, than anything else we considered using.
If you don’t mind my asking, did TB add support for transaction metadata? I’ve seen this anti-pattern of map<string, string> associated with each transaction. Far from ideal, but useful. Last I checked TB didn’t support that because it would need dynamic memory allocation. Does it support it now or will it in future?
It’s not that it would need dynamic memory allocation (it could be done with static), but rather it’s not essential to performance—you could use any KV or OLGP for additional “user data”, it’s not the hard contended part.
To keep consistency, the principle is:
- write your data dependencies if any, then “write to TB last as your system of record”,
- “read from TB first”, and if it’s there your data dependencies will be too.
That makes sense, but it seems to add latency? Let’s say we’re currently reading the transactions from Cassandra with latency t. If TB is the source of truth, but we need an additional read from Cassandra for every transaction, the read latency is strictly worse now. Similarly with writes, especially since you recommend writing to TB last.
If what I’m saying is correct, we won’t actually see any performance benefits, only possible regressions. And if we’re already happy with Cassandra’s record keeping, what does TB add here?
Correct me if I’m missing something though! Like maybe we could rework how we write to Cassandra.
If you have any contention in your workload, which is typical for OLTP workloads [1], then, per Amdahl’s Law, that portion of the work will dominate, and TB will be orders faster.
For example, if your KV can do high throughput writes (and most can) at low latency then you should be looking at 20-50ms P100s all combined, per 8K transactions, when you’re running at 500K TPS, even with extreme contention up to 90%. Very hard if not impossible to do that if you don’t have TB as part of your stack. At least not with the durability and strict serializability guarantees that TB gives.
Both go and rust had substantial dedicated corp support and dollars behind them. Zig not so much. With that in view its advancement is pretty remarkable.
I read it more like that people should start tracking success of country not based on how much health it produces and start caring about the actual quality of live of its people. People can't eat GDP or sleep under it
> Equality can be achieved using capital systems and market economies.
Sure, it is just going to be a eternal battle between the need of capital for infinity growth and the need of working class for better wealth distribution.
> "you should use jj because it's a lot better at solving problems you don't have"
It is more like "you should use jj because then you won't have a lot of problem with git that you'd need git to solve"
> it shouldn't be that hard to explain, should it?
It is not. There are plenty of example on this page. For me the biggest one is stacked PR, jj makes it trivial since it tracks the change sets and not commit ids (which are immutable). So you can work on any level of the stacked PR independently, once you're done run "jj git push -r '(trunk()..@ | @::)'" and it will update all the remote branches accordingly. Another feature that works great with stacked PR is that you don't need to solve conflicts right away. You will see a marker in the "jj log" and you can solve it later down the road.
Also another great feature is the operation log, you can just rewind your actions. F'd up a conflict resolution? Just go "jj op undo". That goes for everything, including file changes and rebases. Want to go back the state it was 15 min ago because you didn't like what you did? Merge to the wrong place? "jj op undo"
Adding to that there are hundreds paper cuts that jj fixes, like:
* Simpler mental model for local change, no git stash/add necessary.
* Simpler commit process, you can just work and use "jj describe" whenever where git forces you to write message before creating commit (again because commits are immutable).
* Starting a work is much easier, I can just go "jj new" away without caring about detached head. Nowdays I just use branches (jj bookmarks) for git compatibility reasons.
* Revsets are amazing, much more powerful and expressive than git logs, and since the UX is more consistent you can always work with set of rules that expects a revset with "-r".
Ofc, you can do all of that with git, but it just works better, easier and more consistent with jj.
> It is more like "you should use jj because then you won't have a lot of problem with git that you'd need git to solve"
I don't have a lot of problems with git that I need to solve, that's the thing. And I don't get why people keep trying to convince me that I do. It's about me, my opinion should have some value, right? :-)
> It is not. There are plenty of example on this page.
The problem is that many examples, to me, sound like it's exactly like git but the author of the example doesn't know how to do it in git. For instance, you wrote a whole paragraph about "undo", as if git did not have that feature. Isn't that exactly `git reflog`? Turns out I had a need for it 2 times in the last 10 years, and it just worked.
> Simpler mental model for local change, no git stash/add necessary.
I can deal with git stash/add without feeling like I'm thinking hard. This is a class of examples that makes me think that jj is for people who are not comfortable with git.
It feels like the people who use jj tend to somehow get stuck on detached head with git, and that's a big problem for them.
Again, I'm not saying that jj is not cool, and probably I should try it. But I see a ton of comments that really, really sound like "I can't believe people still do basic arithmetic in their head: they should get a calculator and they would see how superior it is. With a calculator, you never make those frequent and annoying mistakes like 3+5=9 again! Plus you can do 403985/13 easily!". And when I say "I usually deal with basic arithmetic that I do just fine in my head, and I don't actually frequently make mistakes like 3+5=9", I feel like I sound like an elitist.
I can't remember the last time I had to do something "hard" in git. So it sounds like jj may make something simple slightly simpler, at the cost of dealing with a new tool.
> I don't have a lot of problems with git that I need to solve, that's the thing. And I don't get why people keep trying to convince me
You are in *forum* in a post *about jj* saying there is no reason to use jj. We are just interacting as you'd expect in forum. If you don't see any reason to use anything else and don't want to hear anything about it steer away from these posts.
No one is trying to convince you personally, we are just discussing the tool. Go use git and be happy.
I sincerely won't read anything else past that line.
> You are in forum in a post about jj saying there is no reason to use jj
I honestly am not. I am genuinely interested. Everytime there is a post about jj I'm about to try, and then I see a comment like yours, saying "with jj you just use the intuitive syntax `jj git push -r '(trunk\(?.\).x#@ | @@.^)'`, which is a lot simpler than knowing about this weird concept of stash" and it makes me think that maybe, I'll try again next time.
If you are interest in learning you should take people words on good faith, my comment on "jj git push -r '(trunk()..@ | @::)'" is complex operation to update many stacked PRs not compared to local git index operations. Also in my comment I mentioned revsets and the "-r". It is a language to query logs which you should've check if you genuinely wanted to learn about it, which you don't.
Just look at your answer, you literately ignored everything I mentioned and took what I said out of context just to bash on jj for some reason.
Actually, to be blunt (you're already offended anyway): what I'm saying is that I find (personal opinion) that many evangelists here (you included) don't sell jj really well. If so many people are actual fans of jj, there must be something there. I'm just struggling to find it between the "you're probably too dumb to understand a stash so you should use jj" and the "let me explain to you this great concept that jj has which allows you to undo changes in a way that sounds like git cannot do exactly that".
So no, I'm not criticising jj :-). And I'm not convinced I need it.
> And I don't get why people keep trying to convince me that I do. It's about me, my opinion should have some value, right? :-)
I have no problem whatsoever if you don't like jj or use git or whatever else you like.
Let's paddle back:
- you are in post about jj
- you comment why you don't like jj
- I comment why I like jj
- you post that.
Like, what is your intention here? If you don't have good faith into trying to understand the tooling, how would it fit your workflow and deflects everything with "I know git, git works, don't tell me to use something else" what is your goal here?
My problem is not your opinion on the tool, is how you approach the debate.
I have been asking a few questions, and I have received many answers quickly. Which is usually great, but between the "those who don't use jj haven't seen the light and must be in a cult" and the "jj is better because git is impossible to use everyday", it's honestly been harder than anticipated :-).
reply