qsantos

> For example: you might not want to use Rust because its steep learning curve means you’ll spend more time learning than delivering

Related to that, it might not actually be the case: https://news.ycombinator.com/item?id=36495667. Key takeaway:

> Rumor 1: Rust takes more than 6 months to learn – Debunked !

> All survey participants are professional software developers (or a related field), employed at Google. While some of them had prior Rust experience (about 13%), most of them are coming from C/C++, Python, Java, Go, or Dart.

> Based on our studies, more than 2/3 of respondents are confident in contributing to a Rust codebase within two months or less when learning Rust. Further, a third of respondents become as productive using Rust as other languages in two months or less. Within four months, that number increased to over 50%. Anecdotally, these ramp-up numbers are in line with the time we’ve seen for developers to adopt other languages, both inside and outside of Google.

> Overall, we’ve seen no data to indicate that there is any productivity penalty for Rust relative to any other language these developers previously used at Google. This is supported by the students who take the Comprehensive Rust class: the questions asked on the second and third day show that experienced software developers can become comfortable with Rust in a very short time.

The clocks have not become a hundred-fold faster, I grant you that. But, combined with specialized instructions, the improvement of the instruction pipeline, the growing cache, the multiplication of shadow registers, the addition of hyperthreading, and the increasing number of cores, we probably do have a hundred time more computing power in a modern laptop.

I am always frustrated with the usual answer to these kinds of demonstrations: “Yes, but these new apps are doing so much more. Also, security.”

Except, that they are not, not at the time they are launched at least. And even if they were, we have a hundred-fold more compute power, with a hundredth of the latency for memory and storage.

Regarding security, it should have negligible effect in most cases. At least, effects should not be perceptible to the human mind.

It really is just a consequence of the way we develop software nowadays. We do not need to optimize programs to make them work at all, so we just do not. We work on new features, and we hire people who can churn new features.

And we decided to optimize for developer time, instead of user time. So, instead of painstakingly developing a Web site, a native application, an Android app, and an iOS app, we just push Web apps everywhere.

The crux of the argument of this article seems to be that C allows working directly with raw memory, which is necessary for some low-level tasks, such as communication with memory-mapped devices. This is not possible in pure managed language, due to the additional level of abstraction.

However, the author themselves state that this is not something that implies that undefined behavior are unavoidable when working close to the metal:

    In fact, the very “unsafety” of C is based on an unfortunate conflation of the language itself with how it is implemented. Working from first principles, it is not hard to imagine a safe C.13 As Krishnamurthi and Felleisen [1999] elaborated, safety is about catching errors immediately and cleanly rather than gradually and corruptingly

I would say that, what they are describing is essentially what Rust has achieved, or at least what it is meant to do.

Tangentially related, but I like how readable the source code of CPython (the official interpreter for Python) is. It is plain C without many shenanigans. If you wonder how Python handles big integer, hashmaps, and so on, just dive in the source code!

A few days ago, I wanted a concrete example about dynamic arrays. The examples in computer science textbook always uses a factor of 2 when expanding, since it is very convenient to demonstrate that it gives an amortized O(1) insertion time. Some people find it wasteful, and may resort to use a constant expansion (e.g. 128) instead, leading to a O(n / 128), i.e. O(n) insertion time instead.

But you can just make the expansion factor less than 2. I wanted a concrete example, so, naturally, I just went for CPython's implementation of `list`. It took me less than 2 minutes to find it: https://github.com/python/cpython/blob/main/Objects/listobje....

If you're curious, CPython essentially grows its dynamic array by ⅛ (12.5%) whenever it needs to.

The mass of the Earth has no impact on its orbit. Think about it this way: the northern and southern halves of Earth orbits the sun in exactly the same orbit as the full Earth. Now, if we increased the mass of the Sun, however…

No Reddit, no Stack Overflow. Thankfully, documentation and manuals are still on various platforms and not a single website.

  Using the word 'DreamBerd' in your project name implies that the DreamBerd Foundation does not own your project.
  
  However, not using the word 'DreamBerd' in your project implies that the DreamBerd Foundation does own your project. If you would like to keep ownership of your work, please always use the word 'DreamBerd' in it.
  
  Here are some examples:
  white_check_mark DreamBerdScript (not owned by the DreamBerd Foundation - you are free to use this name)
  x ECMAScript (owned by the DreamBerd Foundation - please consider renaming)
  x Rust Foundation (owned by the DreamBerd Foundation - please consider renaming)

Maybe the author should actually take over the Rust Foundation.

Add this to Application Autostart in xfce4-session-settings.

xcape -e 'Super_L=Control_L|Shift_L|Alt_L|Super_L|Escape'

Then bind xfce4-popup-whiskermenu to Ctrl+Shift+Alt+Super+Escape in the keyboard shortcuts. You can use another key combination, but that's what I use to avoid any plausible conflict.