This is intriguing. Interesting, how does this new Influx engine compete in terms of performance with VictoriaMetrics (which is written in Go and really fast)?
They moved their entire stack from Go to Rust, rewrote the system from the ground, and spent a lot of time on it, I guess this is a big cost.
If I'm reading this [0] right, there will be no a standalone OS influxdb 3.0 version. So there's no point in comparing. I also wonder if it would be allowed to publish benchmarks of ENT version by 3rd-parties.
But C can be improved by adding features that allow this and there is a lot of CS experience accumulated around metaprogramming to design this without lots of pitfalls, and no one says that this is easy, this is really hard, but possible. Unfortunately, the committee plays with old and ugly macros system and a little bit with lambda which for sure is better than nothing, but not enough to make C better.
Absolutely true. C might have its own way of evolution to Modern C with quite a good standard library and mature features, but people who stay behind C++ don't want this, and even though some of them behave really aggressively if some languages like Rust or Zig or Modern C (unfortunately this is will never ever happened) try to replace C++ or take even a little piece of the pie.
C++ is not a bad language at least because lots of amazing soft already written on it, but some people accept it with all of the myriads of complex rules with their own subset and some people totally disagree with this and just want Better(Modern) C with plain and simple rules without hidden complex things which happened behind the scene, and counterintuitive features.
About Rust is everything cool except sometimes it doesn't allow you to write correct code and push you to do things in ways that you don't like. But we are programmers and some part of us is a painter :)
Yet another "X faster than Y" where inside X all hot jobs are done by really good-tuned C or C++. Facepalm.
Without real problem-solving (business logic) written in Python, this is only lightweight wrapper on C/C++. When the number of Python code start growing in the hot path, then these blazing-amazing thruput numbers tremendously will be going down.
Why is it a sham? It's useful to know that x is faster. As a user of x I don't really care if the reason it's faster is it's C++ under the hood. That's really an implementation detail for me.
Because it's measuring a scenario that's not representative of real usages of X and is usually tweaked for the framework/tool the author is trying to showcase.
For example: all the deno/bun benchmarks often use the Node.js frameworks in an unnecessarily slow way and don't measure apples to apples. (like using uWS in bun but not uWS for Node in the benchmark).
This one in particular just measures the speed of "hello world" in plaintext and JSON with very specific parameters.
What happens when you use X because it's fast at one thing in a microbenchmark, but it locks you into an environment that is slow at the rest of your program?
The real thing will be some mix of your code and the library's code, and in cases like this where you'd be writing all your logic in Python vs Golang, that will have a significant effect on the results.
A while back I implemented a game rules engine and MCTS in Torch (the Lua library). The training loop spent like half of its time running the rules engine. Writing it in Python would have been a disaster in comparison. To really make good use of the hardware and spend more time in the optimized machine learning code provided by libraries, one would have to write their rules engine in some language other than Lua or Python.
Because the moment you actually write any server or business logic in Python performance drops off a cliff and it doesn't differ significantly from any of the other Python web frameworks.
> Yet another "X faster than Y" where inside X all hot jobs are done by really good-tuned C or C++. Facepalm.
This is the case for basically every programming language or performant library that exists. Yet, I never see this when discussions exists about node libraries or other languages for that matter. I mean you could argue that node itself is just a thin wrapper around fast C++ libraries.
Who the fuck cares if the request goes down to some compiled C++ library? I still write my logic in Python and get this benefit anyway. This is what makes it great.
> Yet, I never see this when discussions exists about node libraries or other languages for that matter.
Huh? It's the first comment for pretty much any of these stupid performance comparisons. Does someone really think node performance is great, or pick node because of its performance?
> I still write my logic in Python and get this benefit anyway.
That's part of the point. Writing your logic in Python is fine, but then your app performance isn't winning any comparisons. No one cares about the performance this article is explicitly talking about.
I think the issue is that there is three different types of people when it comes to performance.
There is the 1% that are in a need of hard realtime performance, that thinks about GC performance as an issue that needs to be adressed. Sure I can get that for these people, these kind of discussions seems stupid and confusing since they have to develop in C/C++, Rust etc to get the pure performance they need. These people probably aren't in this thread because they know that Python is not a language for them and will never be.
Then there is the 99% crowd, which I am a part of, that could use slow-as-shit frameworks like Rails or Laravel because the performance is just a nice-to-have. These people, like myself, compares Python perf to perhaps PHP or Node because they are fast enough languages and in this kind of league a framework like OPs can make a huge difference. No matter what language you pick here you are basically always using something "beneth" it. Node has been picked by many because it's faster than for example Python and Ruby.
Then there is the people who are part of the 99% crowd but are just have to comment and point the needs of the 1% out because they are negative people who probably produce little themselves and have to hate on what other people create and distribute for free. This group is where most haters on HN belong in. :)
I started in PHP, when I went to Node in the early beginning I was deeply impressed by the great performance and nice features it had. Sure it was built upon C++ libraries but I am never gonna use C++ to write my web api. Still, I could use Node and get 2-3x AT LEAST the performance in all of my endpoints because of this and all my code was in javascript.
What I am trying to say is that I don't care if you pack my code and run it on a computer in Minecraft or your calculator, if it runs faster for very little to no pain on my side that is pure joy to me.
NodeJS might be slow, but it still is orders of magnitude faster than any interpreted or JIT Python implementation. I agree that no one really chooses Node because it is fast, but I think they choose it because it is fast _enough_ whereas if using Python you'd probably find multiple performance bottlenecks that could be show-stoppers.
> Who the fuck cares if the request goes down to some compiled C++ library?
The way this is titled, you know someone will read this as "Python can be faster than go" and influence their decision when it comes to performance ; that's actually why I clicked on that, thinking "how the hell did they achieve faster speed with Python".
Well, it could be true IMHO. If I run my code that calls down to some ultra fast, mega well done C++ library that is much better than anything in the Go community my code then completes requests faster than the Go alternative.
If that is the case, that should influence the decision when it comes to performance. If performance is a very important deal in your app, you have to test this yourself so that you reach the performance you need.
Perhaps you can write C++ extensions to Python for the perf-heavy parts yourself instead of having to write the entire application in a language that takes much longer time to develop in?
I think this is correct and does demonstrate that these comparisons are not all that useful.
But I also think that writing Python and then dropping down into C or C++ for performance is perfectly valid and often a great idea. Of course, there's nothing wrong with just using a different language that's a sensible middle ground between Python and C (like Go). But hold on to the baby when that bathwater is being dumped: there's nothing wrong with writing a blend of Python and C++ for real uses.
Would golang interfaced with the C++ implemenation be as fast? IMO one of the nice features of Python is being able to seamlessly drop to numba, or a C++ module when you need an optimized fastpath, but the rest of your application, the bulk of it, need not.
Most benefits of Rust are true, except in some cases it does not allow you to compile an absolutely valid and safe program like here https://github.com/rust-lang/rust/issues/47680 - unfortunately you don't have freedom of code design decisions! I see some possible problems with refactoring, extending logic and functionality, and lots of issues with async code design and readability.
For me, Rust looks like a temporary step before the next language.
You have successfully linked to the only meaningfully loud bug in the borrow checker; declaring that as proof that Rust is a temporary step does not seem like the most cool-headed of evaluations, especially as it will be fixed by a new borrow checker in active development. These assertions are always made, and always alongside information suggesting the speaker has not actually spent very much time using Rust.
Eh, it might be the only meaningful issue with the borrow checker, but the language itself has more issues than just that. I adore rust and have done for years, but I also see it as a stepping stone language and worry about it gaining too much adoption
It is a stepping stone language in the sense that nobody has ever done anything like it before but you could adapt some of its principles to a language where you don't have to care quite so much about the stack. (Things you could not jettison along the way include ownership and explicit lifetime annotations.) But the language has absolutely nothing I'd call an issue. Only things that could be made even better, and coincidentally always are.
Odin, Zig, Jai, Hare, etc - all of these new languages have been mostly inspired by Go, C, and Rust.
So let's summarize:
1. Simplicity and readability - C, Go
2. Tiny language - C, Go
3. Modularity - Go, Rust
4. Defer statement - Go
5. Metaprogramming (generics, compile time, macros) - lots of inspiration and some really fresh ideas like Zig and Jai, Go interfaces, and Rust traits look nice
6. Strong type system - Go, Rust
7. Manual memory management, pointers - C
8. No OPP in terms of C++, Java
9. No references, just pointers
10. Syntax - Go, Rust
11. Zero cost abstraction and as much as possible minimal runtime - C, Rust
Mostly their look like Rust with "defer" but without borrow checker, move semantics, references, RAII, and lifetime annotation.
Putting Rust and Go together under strong type system is a very odd choice.
Rust is inspired by ML family languages and heavily leans on it's type system, while Go is very simplistic in comparison. (This has improved somewhat with the recent addition of generics)
Yup. For example, in both Rust and Go you can cheerfully open a filename, based on a string you found in some JSON. But the reason why you can do that is very different, and reveals important foundational differences.
In Go the answer is that strings are just some bytes, and filenames are just some bytes and so this naturally just works.
In Rust the answer is that strings are AsRef<Path> and you can open a Path, so when you call open the compiler gives it a Path even though that isn't what you actually had (you can't mutate the Path via this reference, so we know open doesn't change it).
The difference becomes more stark if we go the other way, starting from a list of files in the current directory and writing a JSON file.
In Go if you get a list of all the filenames in the current directory, it's a list of strings, and the fact that those aren't actually text is your problem, you will need to explicitly take care of this or you can't emit valid JSON.
In Rust, you get Paths, and you're going to need to explicitly ask for the strings to make JSON, at which point you have to decide what you want to do if the Path isn't just text, you're obliged to decide, even if it's just panic (ie abort the program).
> In Go if you get a list of all the filenames in the current directory, it's a list of strings, and the fact that those aren't actually text is your problem, you will need to explicitly take care of this or you can't emit valid JSON.
You'll still emit valid json. The encoding/json doc says:
> String values encode as JSON strings coerced to valid UTF-8, replacing invalid bytes with the Unicode replacement rune.
But to be fair if we're sending them as UTF-8 in a JSON file we can't do anything about that.
I've had situations where I am obliged to write output to XML, and clients are like, "You can't lose this weird data in our text". That's not me, that's XML, in XML 1.0 most of the ASCII Control Characters are banned (not like "You must escape this character" they are banned if you write them as text, escaped or not, that's not a valid XML file and some parsers won't read it). You can either admit you want binary data maybe wrapped as Base64 inside the XML or you can accept that in XML those characters are toast. I would turn all the banned characters into U+FFFD in XML.
JSON doesn't have that defect, but it still can't magically make non-text into text, and some filenames are not text. So this feels fair enough. Chances are if your JSON format is so capable that you can write "Here's a Non-text filename" and have that work almost all the people parsing it ignore that case and you didn't really improve interoperability at all.
I agree - Go's type system would be perhaps better described as strict. There are rarely cases in which conversion is implicit (not particularly unique to Go, but useful). Between types are aliases of those types? No. Between signed and unsigned? Of course not. Between string and []uint8? No. What about less precise to more precise? Nope. This can be a pain, but overall it avoids some classes of bugs present in languages like C (without getting strict about your compiler flags anyway) and allows you to use types to encode your problem in a way that prevents dumb mistakes.
Especially with how Go handles default values. Suddenly a value wasn't present in a deserialization and now that's a nil pointer. Or if you have a stateful 0 so you can't tell the difference between missing or user choice without a deeply awful extra check.
- Defer is nice for cleanup, but I think destructors are the gold standard there. They're even simpler to reason about, you can't forget to invoke them, and combined with move semantics they automate away a really wide range of cleanup scenarios. Another interesting difference is that adding destructor-based cleanup to an existing type that didn't previously have a destructor is often a backwards-compatible change. Lastly, GC'd languages like Go usually need to include some sort of finalizer mechanism in addition to the defer syntax, and finalizers are surprisingly complicated.
- I don't think C should get full points for zero cost abstractions. There's a lot of pressure to use void*'s or intrusive structures in place of true generic containers like std::vector/Vec, and that comes with runtime overhead in practice.
They moved their entire stack from Go to Rust, rewrote the system from the ground, and spent a lot of time on it, I guess this is a big cost.
Is it worth it?