Easier?
Easier?
Posted Nov 22, 2024 17:42 UTC (Fri) by ceplm (subscriber, #41334)Parent article: NonStop discussion around adding Rust to Git
???
Do you mean to say, with a straight face, that there are more Rust developers than the C ones?
Posted Nov 22, 2024 18:08 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
* While there are more C than Rust developers now, in 10 or 20 years that may no longer be the case.
Posted Nov 23, 2024 9:19 UTC (Sat)
by ceplm (subscriber, #41334)
[Link] (2 responses)
Do you believe, with the speed of the IT development, anybody will care for either of these programming languages in twenty years? Do you believe that anybody will care for git? And even if we do and the proportion of Rust/C-C++ changes tenfold, I guess git development could change (and the rewrite of git to Rust would already happen anyway).
Posted Nov 23, 2024 14:44 UTC (Sat)
by pbonzini (subscriber, #60935)
[Link]
Perl is probably the least healthy of the various languages in use today. Maybe in 20 years people will treat C like they treat COBOL or Fortran, but the lesson of COBOL and Fortran is exactly that C and C++ *will* be around in 10 or 20 years just for the sheer amount of code that's written using those languages. Others like Rust or Go or Ruby maybe not have the same amount of code to protect them, but of the three I would bet on Rust the most because it's pretty much the only language to provide important advantages in the field occupied by C/C++.
Posted Nov 24, 2024 5:41 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Git _itself_ is 20 years old! People are still using RCS in some niche software, and it's 40 years old.
I can say for certain, that Rust absolutely will be around in 20 years.
Posted Nov 22, 2024 18:15 UTC (Fri)
by geofft (subscriber, #59789)
[Link] (4 responses)
Posted Dec 3, 2024 9:01 UTC (Tue)
by LtWorf (subscriber, #124958)
[Link] (3 responses)
Posted Dec 3, 2024 9:53 UTC (Tue)
by intelfx (subscriber, #130118)
[Link] (2 responses)
> By that logic, python or js would be orders of magnitude better.
Yes, except that Rust offers comparable (or better) performance to C code, while at the same time offering a significant amount of statically verified guarantees about the program's correctness (under the umbrella term of "safety", which is emphatically NOT just about "memory safety", read here for details). None of this is available in Python or JS.
So, unfortunately, it appears that you've entirely missed the point of "that logic".
Posted Dec 3, 2024 10:27 UTC (Tue)
by LtWorf (subscriber, #124958)
[Link] (1 responses)
1. The increased complexity of building it would be a burden to the project
2. The quality of the developers is not the same
3. More developers doesn't imply more contributors
I hope it's clearer now.
Posted Dec 3, 2024 12:30 UTC (Tue)
by intelfx (subscriber, #130118)
[Link]
So, no, I did not miss "your meaning". If you had any other meaning, you should have said something that conveys that meaning.
Posted Nov 23, 2024 1:45 UTC (Sat)
by khim (subscriber, #9252)
[Link] (4 responses)
No, but anyone may say, with a straight face, that the vast majority of developers, these days, have no idea how to write code in any language which have piles of UB and which doesn't notify you if you do mistakes. You can give Rust compiler to TypeScript or Python developer and while they may not like it… they would be able to write something working. You can not give them a C compiler and expect them to write code that works. Because they implicitly expect that code either works or breaks and they get an error message – that's true for Rust without
Posted Nov 23, 2024 13:25 UTC (Sat)
by pizza (subscriber, #46)
[Link] (3 responses)
No.
They may/will be able to write something without UB, but that doesn't mean it actually *works*.
The *works* is the critical point. It doesn't matter if git is written in rust or javascript or C or algol or whatever. You still have to have at least some understanding of what and how git does things -- core concepts, data structures, algorithms, etc -- if there is going to be any chance of producing something that works.
And sure you can just bash against the compiler until your rust code compiles, but again, that doesn't mean that the resulting binary _works_ for its intended purpose.
Posted Nov 23, 2024 15:56 UTC (Sat)
by khim (subscriber, #9252)
[Link] (2 responses)
It kida does, though. C/C++ is more-or-less unique among popular languages in that you may easily write code that compiler would accept and that would works, for some time, but may then explode if you change something in entirely different place. In most other popular languages if code compiles – then it works… somehow. It may not do what you want, it may even fail (and most likely would fail on first try), but it fails in predictable fashion! That's different story altogether. Once your code works but doesn't do what you want it to do you start the “genetic programming”: start mutating code semi-randomly while picking better and better behaving specimens till it would do what it needs to do. StackOverflow is a great thing at this point, ChatGPT or Gemini are even better. It does, though. Very much. Well… that's precisely what makes is so hard to contribute, isn't it? The algorithm explained above that the vast majority of modern programmers employ… it just simply doesn't work with C/C++! Because in C/C++ wrong code may actually work by accident in your tests, but then it would fail in larger program and random mutations don't bring you closer and closer to something you may declare as “finished” but just make it harder and harder for anyone to fix it.
Posted Nov 23, 2024 16:29 UTC (Sat)
by pizza (subscriber, #46)
[Link] (1 responses)
...Are you seriously asserting that something can still "work" even if it "it fails" ?
(Well, if by "works" you mean "compiler accepts it and it produces a runnable binary" then sure. But most would consider that a necessary, but wholly insufficient milestone)
Posted Nov 23, 2024 16:45 UTC (Sat)
by khim (subscriber, #9252)
[Link]
Sure, but in most language that perfectly fine basis for the iterable attempt to fix your code. In C/C++… that approach doesn't work at all: usually your code still fails but without any breadcrumbs which allow you to go and tweak the code randomly till error messages would stop occuring. Because in C/C++… very often the actual problem that makes you code fail (some wild pointer or buffer overflow or any other silly problem) is happening in entirely different piece of code, not where something actually crashes! That's such a crazy wild disconnect from what the most contributors (the ones who don't know C/C++, but know JavaScript, C#, Go, or any other popular language) expect that C and C++ form it's own wild subculture entirely disconnected from all other languages. Sure, there are also a lot of infigthing withing that subculture, too, but it's entirely separated from the other languages – and that division also reduces number of potential contributors. In C/C++ people consider it the norm that you would first try to understand core concepts, data structures, algorithms, etc of the project – and only then would attempt to contribute… but in all other languages it's the opposite: you first contribute something and as you add more and more code to the project you, gradually, learn about core concepts, data structures, algorithms, etc of the project. Contributing to the project written in Rust is the same as contributing to the project written in any other popular language and thus open up your project to a much wider audience.
Posted Nov 23, 2024 2:07 UTC (Sat)
by dvdeug (guest, #10998)
[Link] (4 responses)
C++ is terrifying; it's like four layers of experimental language stacked on a weak foundation.
Rust? It's more low-level than I like, but it's a reasonably well designed language of the 2010s, not a reasonably well designed language of 1970s, or several decades of experimental languages piled on top of that language of the 1970s.
Posted Nov 23, 2024 9:13 UTC (Sat)
by ceplm (subscriber, #41334)
[Link] (3 responses)
That is all I was saying.
Posted Nov 23, 2024 11:45 UTC (Sat)
by khim (subscriber, #9252)
[Link] (2 responses)
According to that logic we should use Chinese and not English here, because there are way more Chinese speakers in the world than English speakers. Now… why don't we do that? Hmm?
Posted Nov 23, 2024 12:06 UTC (Sat)
by aragilar (subscriber, #122569)
[Link] (1 responses)
Posted Nov 23, 2024 12:42 UTC (Sat)
by khim (subscriber, #9252)
[Link]
Sigh. Please read the very first sentence of the very page that you linked to: For example, Chinese and Arabic are sometimes considered single languages, but each includes several mutually unintelligible varieties, and so they are sometimes considered language families instead. Conversely, colloquial registers of Hindi and Urdu are almost completely mutually intelligible, and are sometimes classified as one language, Hindustani. Indeed, there are big difference. English have significantly less speakers, but if you add up all the people who may write something in it (even if in a horrible broken form) you would arrive at about the same number as for Chinese (around 1.5 billion for both). And similarly with languages: if you look on the graph you'll see that number of projects that include Rust code is almost the same as number of projects that include C code and significantly more than number of projects that include a Dart code… in fact there are more code in Rust on Github than in, e.g., Kotlin, but Kotlin is considered way more popular than Rust because there are more questions in Stack Overflow! And with programming language there are also big difference between the ability to understand the language and ability to contribute code in the language. C++ have both more code and more questions and there are, arguably, more people who may understand C code than Rust code right now… but would such people really be ready and willing to contribute to the project in the language where even simplest bast data structures are not standardized and you have to learn what bespoke solution was used in this particular piece of code?
Posted Dec 13, 2024 0:30 UTC (Fri)
by sunshowers (guest, #170655)
[Link] (4 responses)
There are entire communities of "hardcore" C/systems devs who have quietly moved to Rust—and don't really want to write C any more. There is a massive wave that's been building for a few years, and it's only going to get bigger over time.
Posted Dec 13, 2024 1:17 UTC (Fri)
by pizza (subscriber, #46)
[Link] (2 responses)
The barrier to contribution isn't "skilled in C" so much as "skilled in that particular codebase."
> There are entire communities of "hardcore" C/systems devs who have quietly moved to Rust—and don't really want to write C any more. There is a massive wave that's been building for a few years, and it's only going to get bigger over time.
Give a highly skilled person a more complex tool, and after some practice they may be able to achieve greater things. But you're not oging to get the same results by handing the same tool to someone that is barely literate.
Posted Dec 13, 2024 3:46 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (1 responses)
By virtue of having more high-level abstractions and generally a more modern/ergonomic design, Rust makes it easier to get up to speed within a given codebase[1]. It does not necessarily make you *skilled* faster, but it's likely to make you *productive* faster.
> Give a highly skilled person a more complex tool, and after some practice they may be able to achieve greater things. But you're not oging to get the same results by handing the same tool to someone that is barely literate.
That's not what GP was saying. In this analogy, C is the "more complex" tool.
[1] for a very simple reason: you spend less time on rediscovering how a particular codebase does fundamental things, because all of those fundamental things are baked into the language (or, worst case, implemented in highly popular libraries which are likely part of the dependency tree anyway).
Posted Dec 14, 2024 1:57 UTC (Sat)
by sunshowers (guest, #170655)
[Link]
If wasmtime were in C or C++, it would have taken me a long time to wrap my head around all of the details. I'd probably had to have one of the maintainers walk me through it on a video call. But with Rust, I went from never having seen the code before to having a ~800 line prototype of a fairly major internal refactor within a day. I was contributing fixes and identifying bugs the very next day too.
Rust is great for novices to a codebase.
Posted Dec 13, 2024 2:44 UTC (Fri)
by viro (subscriber, #7872)
[Link]
Easier?
* Once you are proficient in both Rust and C, it is easier to come up to speed on a Rust codebase than a C codebase (because the Rust compiler will enforce the correct ownership model and many other invariants that the C compiler does not understand).
* C is a simpler language, but that does not make it an easier language. By forcing you to write provably correct code from the beginning, the Rust compiler avoids the pitfalls of memory corruption and "impossible" crashes that many C beginners struggle with (before eventually learning many of the same lessons anyway, but without explicit syntax to describe what they have learned). Rust may have more complexity to learn up-front, but in the long run, it is an easier language to use, and ultimately easier to master, specifically because it forces you to deal with these issues instead of ignoring them until they bite you.
Easier?
Easier?
Easier?
Easier?
Easier?
Easier?
Easier?
Easier?
> Do you mean to say, with a straight face, that there are more Rust developers than the C ones?
Easier?
unsafe and very explicitly not true for C.Easier?
> And sure you can just bash against the compiler until your rust code compiles, but again, that doesn't mean that the resulting binary _works_
Easier?
Easier?
> But most would consider that a necessary, but wholly insufficient milestone
Easier?
config is undefined – oh, damn, I forgot to read the config file, ok, done panic: index 24325462 is out of bounds – wow, I guess I mess up with my calculations, somehow… better to fix that, and so on.Easier?
Easier?
Easier?
Easier?
Easier?
Easier?
Easier?
Easier?
Easier?
Easier?