robinm 15 hours ago • 100%
The fact that rustc has bugs (which is what cve-rs exploit) doesn't invalidate that rust the language is memory safe.
robinm 2 months ago • 100%
This post from 2022 was very interesting:
There are approximately 1.5 million total lines of Rust code in AOSP across new functionality and components [...] These are low-level components that require a systems language which otherwise would have been implemented in C++.
To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
robinm 2 months ago • 100%
git worktree
could become your new friend then :)
robinm 2 months ago • 100%
The quote (and the associated discussion) is such an important part of Rust and why I love this language so much. Anything that can be automated should at one point be automated reliably, and the sooner the better.
robinm 4 months ago • 100%
It's a question of workflow. Git doesn't guide you (it's really workflow agnostic) and I find it easier to taillor CLI to fit my exact need, or use whatever was recently added (like worktrees a few years ago). I have yet to find a GUI/TUI that I'm not frustrated with at one point but everyone has its own preferences.
robinm 4 months ago • 100%
If you use the git command line (and I do) you should spam git log --graph
(usualy with --oneline
).
And for your filesystem example I sure do hope you use tree
!
robinm 5 months ago • 100%
Thank you! I didn’t realized that I was using my lemmy account and not my mastodon account.
Hello, I’m trying to follow Lennard Poetting (@pid_eins@mastodon.social) from my programming.dev account without success. On [its user profile on mastodon.social](https://mastodon.social/@pid_eins), when I click on the “follow” button, then enter “programming.dev” (which is in the completion list) then “take me home”, I am redirected to https://programming.dev/authorize_interaction?uri=https%3A%2F%2Fmastodon.social%2Fusers%2Fpid_eins which is a 404 error. I also tried to search for “@pid_eins@mastodon.social” directly from programming.dev, found it, but 0 toot, and no button to be able to follow it. Am I doing something wrong? Is mastodon.social and programming.dev not federated?
robinm 5 months ago • 100%
I absolutely agree that method extraction can be abused. One should not forget that locality is important. Functionnal idioms do help to minimise the layer of intermediate functions. Lamda/closure helps too by having the function much closer to its use site. And local variables can sometime be a better choice than having a function that return just an expression.
robinm 5 months ago • 100%
Good advice, clear, simple and to the point.
Stated otherwise: "whenever you need to add comments to an expression, try to use named intermediate variables, method or free function".
robinm 5 months ago • 100%
A fun read but it really seems that his writting style is hit or miss!
robinm 5 months ago • 100%
I never understood why python won agaist ruby. I find ruby an even better executable pseudo code language than python.
robinm 5 months ago • 100%
Awesome! It reminds me of that clip that uses the windows task manager to run doom on a 896 core CPU.
robinm 6 months ago • 100%
It's so anoying that at $WORK we have multiple git repos with symbolic link that points above their respective .git to each other and need to be in sync. So of course git workree
and git bisect
don't work that well…
robinm 6 months ago • 100%
For those who don't know (I assume you do), you can git bisect run some_command
and git will automatically run git bisect until it finds the falty commit. It's amazing.
robinm 6 months ago • 100%
Read your own code that you wrote a month ago. For every wtf moment, try to rewrite it in a clearer way. With time you will internalize what is or is not a good idea. Usually this means naming your constants, moving code inside function to have a friendly name that explain what this code does, or moving code out of a function because the abstraction you choose was not a good one. Since you have 10 years of experience it's highly possible that you already do that, so just continue :)
If you are motivated I would advice to take a look to Rust. The goal is not really to be able to use it (even if it's nice to be able able to write fast code to speed up your python), but the Rust compiler is like a very exigeant teacher that will not forgive any mistakes while explaining why it's not a good idea to do that and what you should do instead. The quality of the errors are crutial, this is what will help you to undertand and improve over time. So consider Rust as an exercice to become a better python programmer. So whatever you try to do in Rust, try to understand how it applies to python. There are many tutorials online. The official book is a good start. And in general learning new languages with a very different paradigm is the best way to improve since it will help you to see stuff from a new angle.
robinm 7 months ago • 100%
I reread that article every years for a few years. Each time my understanding of git improved significantly.
robinm 7 months ago • 100%
I reread that article every years for a few years. Each time my understanding of git improved significantly.
robinm 7 months ago • 100%
It was when I read the git parable.
robinm 7 months ago • 100%
I wasn't clear enough. But in a contry where the sun rise at 20:00, the weekday looks like:
- day 1: Monday morning to Tuesday evening
- day 2: Tuesday morning to Wednesday evening
- day 3: Wednesday morning to Thurday,
- …
And phares like "let's meet on Tuesday“ without hour indication could either mean end of day 1 or start of day 2. Likewise "let's meet the 20th” (assuming the 20th is a Tuesday) could either mean end of day 1 or beggining of day 2.
--
And alternative be to have
- day 1 == Monday == “end of the 19th” to “the start of the 20th”
- day 2 == Tuesday == “end of the 20th” to “the start of the 21st”
- day 3 == Monday == “end of the 21st” to “the start of the 22nd”
- …
Which solve the issue of "let's meet on Tuesday”, but not “let's meet the 20th”.
robinm 7 months ago • 100%
The issue is that the notion of "tomorrow" becomes quite hard to express. If it’s 20:00 when the sun rose, when does tomorrow starts? In 5 hours ?
robinm 7 months ago • 100%
Interesting idea indeed. I've never used async yet, but I'm always surprised at how the problem space seems to be much more complicated than what it initially looks like.
robinm 7 months ago • 90%
You shouldn't, it's short and interesting
robinm 8 months ago • 100%
I have a non-breaking space on my layout since 10 years, and a friend recently added a non-breaking hyphen to his. Appart from search that doesn't do automatic conversion I didn't noticed issues.
robinm 8 months ago • 100%
Looks nice. It has a very good “wooow” effect
robinm 8 months ago • 100%
I would have liked a link to the LKLM thread. Usually they are quite informative
robinm 8 months ago • 100%
I use a 42 key layout modified from bépo (french dvorak inspired layout) with the altgr layer of ergol. Go check this altgr layer it's awesome for programming, and there is a version compatible for qwerty and lafayette.
╭╌╌╌╌╌┰─────┬─────┬─────┬─────┬─────┰─────┬─────┬─────┬─────┬─────┰╌╌╌╌╌┬╌╌╌╌╌╮
┆ ┃ ¹ │ ² │ ³ │ ⁴ │ ⁵ ┃ ⁶ │ ⁷ │ ⁸ │ ⁹ │ ⁰ ┃ ┆ ┆
┆ ┃ ₁ │ ₂ │ ₃ │ ₄ │ ₅ ┃ ₆ │ ₇ │ ₈ │ ₉ │ ₀ ┃ ┆ ┆
╰╌╌╌╌╌╂─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┼╌╌╌╌╌┤
· ┃ │ ≤ │ ≥ │ *¤ │ ‰ ┃ *^ │ │ × │ *´ │ *` ┃ ┆ ┆
· ┃ @ │ < │ > │ $ │ % ┃ ^ │ & │ * │ ' │ ` ┃ ┆ ┆
· ┠─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┼╌╌╌╌╌┤
· ┃ │ ⁽ │ ⁾ │ │ ≠ ┃ */ │ ± │ — │ ÷ │ *¨ ┃ ┆ ┆
· ┃ { │ ( │ ) │ } │ = ┃ \ │ + │ - │ / │ " ┃ ┆ ┆
╭╌╌╌╌╌╂─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┴╌╌╌╌╌╯
┆ ┃ *~ │ │ │ – │ ┃ ¦ │ ¬ │ *¸ │ │ ┃ ·
┆ ┃ ~ │ [ │ ] │ _ │ # ┃ | │ ! │ ; │ : │ ? ┃ ·
╰╌╌╌╌╌┸─────┴─────┴─────┴─────┴─────┸─────┴─────┴─────┴─────┴─────┚ · · · · · ·
robinm 8 months ago • 100%
Yeah, this make sence
robinm 8 months ago • 100%
It's also what I understood from what I read but I assume it was just a poor choice of word. Debug symbols are way too important for debugging to be stripped by default.
robinm 8 months ago • 100%
That's only a summary of the introduction! The full story is much more interesting
robinm 8 months ago • 100%
That's a really good explanation. I would just add that I find easier to search for orphans with git log --graph --reflog
than using `git reflog directly, especially if it's one of the top entries in the reflog.
robinm 8 months ago • 100%
vim can have IDE-like capabilities thanks to lsp and tree-sitter. That's a real game changer and is quite easy to set-up with something like kickstart.nvim.
robinm 8 months ago • 100%
If you have references explain why and how that it’s easier to port C to a new architecture by creating a new compiler from scratch than to either create a backend for llvm (and soon gcc) or to create a minimal wasm executor (like what zig is doing) to this new architecture I’m interested. And of course I talking about new architectures because it’s much easier to recreate something that as already be done before.
robinm 8 months ago • 100%
I’m not familiar with C tooling, but I have done multiple projects in C++ (in a professionnel environnement) and AFAIK the tooling is the same. Tooling to C++ is a nightmare, and that’s and understatement. Most of the difficulty is self inflicted like not using cmake/meson but a custom build system, relying on system library instead of using Conan or vcpkg, not using smart-pointers,… but adding basically anything (LSP, code coverage, a new dependency, clang-format, clang-tidy, …) is horrible in those environments. And if you compare the quality of those tools to the one of other language, they are not even close. For exemple the lint given by clang-tidy to the one of Rust clippy.
If it took no more than an hour to add any of those tools to a legacy C project, then yes it would be disingenuous to not compare C + tooling with Rust, but unfortunately it’s not.
robinm 9 months ago • 75%
With Bram Moolenaar death, I sincerely think that vim will no longer be able to play catch-up with nvim. Bram Moolenaar did an amazing job with nvim, but with its death I think that vim is going to be an editor of the past, just like vi is an editor of the past. And nvim is its successor since its where the developers have moved.
robinm 9 months ago • 100%
Nice try kiddo!
robinm 9 months ago • 66%
I never had to use this estimate in front of a client, but if I had, I would decompose it first before giving the total estimate. If there is about 10 items to do per button, so 10 buttons would be a hundred complexe tasks. So let say that it take an hour per task, but since we are fast we can do 10 a day. So suddenly 10 working days, or said otherwise 2 weeks don't seems unrealistics for this apparently simple 10 buttons task.
robinm 9 months ago • 100%
As a rough estimation, if you include everything (apperance, discussion, functionality, interaction with other controls, …) I would say that every single input field or button is about a day of work. And then you start to realise how many buttons there is in any GUI and how much it will cost.
robinm 9 months ago • 88%
Usually when people say “I suck at maths”, it means that they are bad at doing manual calculus. Maths is extremely useful in programming, but it’s absolutely not the same kind of math. I don’t think that the grade you had in math at school will influence in any if you will be good or bad in programming.
robinm 9 months ago • 100%
That's an interesting idea to use zig to test C code. It's quite an achivement for zig to be better than C at testing C code. I really hope for them that this language will become popular.
And this post was interesting to see how a new user of zig approaches that language
robinm 9 months ago • 100%
I would even have said that both throwing and catching should be pure, just like returning an error value/handling should be pure, but the reason for the throw/returning error itself is impure. Like if you throw and ioerror it's only after doing the impure io call, and the rest of the error reporting/handling itself can be pure.
The Rust for Linux (RFL) project may not have (yet) resulted in user-visible changes to the Linux kernel, but it seems the wider world has taken notice. Hongyu Li has [announced](https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/We.20build.20a.20Rust.20Realtime.20Operating.20System.28.60RROS.60.29.20using.20RFL!/near/407428553) that the Rust for Linux code is now part of a satellite just [launched](https://bupt-os.github.io/website/news/2023_12_9/satellite_launch/) out of China. The satellite is running a system called [RROS](https://github.com/BUPT-OS/RROS), which follows the old RTLinux pattern of running a realtime kernel alongside Linux. The realtime core is written in Rust, using the RFL groundwork. > Despite its imperfections, we still want to share RROS with the community, showcasing our serious commitment to using RFL for substantial projects and contributing to the community's growth. Our development journey with RROS has been greatly enriched by the support and knowledge from the RFL community. We also have received invaluable assistance from enthusiastic forks here, especially when addressing issues related to safety abstraction (Thanks to Dirk Behme).