[ / / / / / / / / / / / / / ] [ dir / cafechan / leftpol / lewd / marx / o / radcorp / russian / stol ][Options][ watchlist ]

/tech/ - Technology

You can now write text to your AI-generated image at https://aiproto.com It is currently free to use for Proto members.
Name
Email
Subject
Comment *
File
Select/drop/paste files here
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Expand all images

File (hide): d6869dcd0f51f1c⋯.png (15.02 KB, 200x240, 5:6, logo-droplets-200.png) (h) (u)

[–]

 No.832461>>832528 >>832591 [Watch Thread][Show All Posts]

Using Rust in Mercurial

Today, Mercurial is a Python application. It uses Python C extensions in various places to achieve better performance.

There are many advantages to being a Python application. But, there are significant disadvantages.

A major pain point of Python for Mercurial is startup overhead. It takes dozens of milliseconds to start a Python interpreter and load the Mercurial Python modules. If you have many extensions loaded, it could take over 100ms just to effectively get to a Mercurial command's main function. While the command itself may complete in mere milliseconds, Python overhead has already made hg seem non-instantaneous to end-users. A few years ago, we measured that CPython interpreter startup overhead amounted to 10-18% of the run time of Mercurial's test harness. The ability to skip Python completely for some hg commands would be a very compelling feature.

Python is also substantially slower than native code. While we embrace the hackability advantages of Python for large parts of Mercurial's functionality, there's a lot of lower-level, performance sensitive code that would benefit from not being implemented in Python. And the types of things we want to do (like using thread pools to handle CPU-intensive tasks like decompression and delta application) are not things that can be efficient in Python as long as the GIL is around.

As Mercurial's code base grows, the use of a dynamic programming language also hinders development velocity. There are tons of bugs that could be caught at compile time by languages that do such things.

When performance is an issue, Mercurial developers currently turn to C. But we treat C as a measure of last resort because it is just too brittle. It is too easy to introduce security vulnerabilities, memory leaks, etc. On top of vanilla C, the Python C API is somewhat complicated.

Furthermore, Mercurial needs to run on multiple platforms, including Windows. The nice things we want to do in native code are complicated to implement in C because cross-platform C is hard. The standard library is inadequate compared to modern languages. While modern versions of C++ are nice, we still support Python 2.7 and thus need to build with MSVC 2008 on Windows. It doesn't have any of the nice features that modern versions of C++ have.

For Mercurial, Rust is all around a better C. It is much safer, about the same speed, and has a usable standard library and modules system for easily pulling in 3rd party code.

https://www.mercurial-scm.org/wiki/OxidationPlan

discuss

 No.832528>>832532

>>832461 (OP) (OP) (OP)

>cross-platform C is hard

C was designed to be cross platform. If you are talking about getting the code working on windows, you just have to worry about the netcode.

And when working with the networking code do NOT use their version of select unless you want to debug what's wrong for 6 hours because there is a bug in Windows which Microsoft won't fix because muh compatibility.


 No.832532>>832543

>>832528

>C was designed to be cross platform.

Source?

Anyway cross-platform C is hard. If you claim otherwise you probably are a LARPer. Just because your Hello, World! in C doesn't segfault doesn't mean you are allowed to post on /tech/.


 No.832534>>832539

>python2

Trash. Use python3 and C++17. No need for Rust.


 No.832539

>>832534

>hurr im a retarded nigglet that didn't read the full post

They are switching over to python3. Also C++ is absolute cancer. C is at least simple but C++ is a fucking mess.


 No.832543>>832548

>>832532

C was designed so that Unix didn't have to be written in scratch every time they wanted to port it to a new platform.

>If you claim otherwise

You only have to worry about a few small platform specific bits. It is only going to take like a day to pump out all the windows specific code by just adapting your Linux code and reading the documentation.


 No.832548>>832568

>>832543

Sure thing kiddo. C is absolutely awful if you want your shit to be portable.


 No.832562>>832564

I guess Facebook uses mercurial.


 No.832564

>>832562

Yeah and they have written a mercurial server in Rust:

https://github.com/facebookexperimental/mononoke

>Mononoke is a next-generation server for the Mercurial source control system, meant to scale up to accepting thousands of commits every hour across millions of files. It is primarily written in the Rust programming language.


 No.832568>>832570

>>832548

not an argument


 No.832570

>>832568

I wasn't trying to make one. I was merely stating a fact.


 No.832576>>832577

File (hide): f4a1f044a50a375⋯.jpg (44.92 KB, 279x400, 279:400, nyet.jpg) (h) (u)

>hey goy use this CMS

<is it git?

>no

<is it fossil?

>no

<(pic related)


 No.832577>>832579

>>832576

not an argument


 No.832579

>>832577

maybe for rust's next big win someone can rewrite svk in it


 No.832591




[Return][Go to top][Catalog][Screencap][Nerve Center][Cancer][Update] ( Scroll to new posts) ( Auto) 5
14 replies | 1 images | Page ?
[Post a Reply]
[ / / / / / / / / / / / / / ] [ dir / cafechan / leftpol / lewd / marx / o / radcorp / russian / stol ][ watchlist ]