I didn’t answer your “request” because that has nothing to do with what I originally said.

If I wanted to get into an hours long conversation about gender I would’ve said something completely different. Got better things to waste my time on.

If other opinions matter, then it is not an irrelevant question. Since it prompts people to tell their opinions.

If the question is so irrelevant, why do you even try to answer it in the same comment? Not only answering it, but also making it a fact. As if your opinion is the only one that matters and suddenly it’s irrelevant when there’s a different opinion.

You can just use an unsafe block though. Or make a thin wrapper that is just safe functions that inside just have an unsafe block with the C ABI function.

Even if rust had a stable ABI, you would still need that unsafe block.

I’m not so sure that dynamic libraries always reduces the size. Specially with libraries that are linked by a single binary.

With static libraries, you can conditionally compile only the features you’re gonna use. With dynamic libraries, however, the whole library must be compiled.

EDIT: just to clarify, I’m not saying that static libraries result always in less size. I’m saying that it’s not a black and white issue.

I think you completely missed the point.

The problem is not that the sign exists, the problem is that people don’t see nothing wrong with it.

If you were a Jew, how would you feel if you saw Nazi flags on a men’s rights protest? Would you feel safe knowing that men a Nazi is safe around men? (Which probably means many of those men are nazis/nazi sympathizers themselves.).

That’s how men feel when they see sexist messages in feminist protests go uncontested.

They should’ve looked at their star software product: Microsoft access.

Now presenting: Access Intelligence

You can’t be that blind. At pretty much every women’s rights protest there is at least someone with a sign up that reads something like “All men are rapists”. Sure, the protest might not be about that. Sure, not everyone agrees with that kind of statements. But there’s not much opposition either, so that kind of sexist message appears all the time in the news. Furthermore, those spewing sexist bullshit call themselves “feminists”, so young men think that feminism is like that, and now they hate feminism too.

EDIT: just as an example, right after writing this comment I saw this other one: https://lemmy.world/comment/13322514 it’s impossible to time it better.

Hardware signing stuff is not a real solution. It’s security through obscurity.

If someone has access to the hardware, they technically have access to the private key that the hardware uses to sign things.

A determined malicious actor could take that key and sign whatever they want to.

Editor/IDE, whatever. People claim both about jetbrains.

If you want a purely editor-thing:

Whatever vscode does with Ctrl+D (I don’t know the name). Ctrl+D is probably the hotkey I use most in vscode (probably more than Ctrl+S), yet CLion doesn’t have that. I’ve searched multiple times the whole settings for it.

Those two examples are just the ones that most recently occurred to me, it has a lot more issues. For example the lack of a staging area. You can’t “git stage” in CLion.

And I don’t think that the git integration is free from criticism. Git integration is one of the most important features of IDEs. It’s absolutely valid to criticize it.

The autoformatter also doesn’t work correctly when developing in remote. Which means that unless I want my PRs to have thousands of lines of whitespace changes, I can’t use the auto formatter.

Now I don’t know if this is a CMake issue or CLion. But at one point It was "#include"ing a struct from a header file I had deleted 1 hour previous to the build failing. The only way to fix that was to create the file again and delete it again.

These complaints might seem small. But put together they are hours of wasted time that you don’t expect from the “best” of something.

Don’t need to go all the way there. I always heard that jetbrains make the best editors. Yet when my job forced everyone to use CLion I saw that it was just a lie. The editors aren’t good, they are just expensive.

There are 2 easy examples:

1. Remote developing sucks. Loading a remote cmake project takes ages. Yet if you remove the temp directory it’s almost instantaneous. Except when you do it too often and clion refuses to sync the files, then you’re fucked because there isn’t a “sync” button, it only happens automatically.

2. The commit log is awful. It doesn’t by default show you the commit/branch you’ve checked out, it shows the chronologically most recent commit. There’s no “go to checked out commit” button either, you have to write the hash in the search field. Which btw the search is trash. If you write 6 of the characters of the hash it shows “there are no results”, yet when you write the 7th, suddenly your commit appears.

In Spanish, chupa means either suck or lick depending on context.

Chupa chups are lick licks.

Damn. Alacritty has no features?

The thing about UB is that many optimizations are possible precisely because the spec specified it as UB. And the spec did so in order to make these optimizations possible.

Codebases are not 6 lines long, they are hundreds of thousands. Without optimizations like those, many CPU cycles would be lost to unnecessary code being executed.

If you write C/C++, it is because you either hate yourself or the application’s performance is important, and these optimizations are needed.

The reason rust is so impressive nowadays is that you can write high performing code without risking accidentally doing UB. And if you are going to write code that might result in UB, you have to explicitly state so with unsafe. But for C/C++, there’s no saving. If you want your compiler to optimize code in those languages, you are going to have loaded guns pointing at your feet all the time.

I recently came across a rust book on how pointers aren’t just ints, because of UB.

fn main() {
    a = &1
    b = &2
    a++
    if a == b {
        *a = 3
        print(b)
    }
}

This may either: not print anything, print 3 or print 2.

Depending on the compiler, since b isn’t changed at all, it might optimize the print for print(2) instead of print(b). Even though everyone can agree that it should either not print anything or 3, but never 2.

If you want to use instructions from an extension (for example SIMD), you either: provide 2 versions of the function, or just won’t run in some CPUs. It would be weird for someone that doesn’t know about that to compile it for x86 and then have it not run on another x86 machine. I don’t think compilers use those instructions if you don’t tell them too.

Anyway, the SIMD the compilers will do is nowhere near the amount that it’s possible. If you manually use SIMD intrinsics/inline SIMD assembly, chances are that it will be faster than what the compiler would do. Especially because you are reducing the % of CPUs your program can run on.

They should be paid though

Spaniard here. Not only does my company not pay me for lunch time. It also demands it to be at least 30 minutes long. How is it even legal to force my unpaid time to be a minimum amount?

I don’t know why you are being so rude. I thought it was the rust community that was known for being toxic?

It’s not my opinion on what the unsafe keyword means. That’s its purpose. Nobody ever wants to write unsafe code on purpose. The unsafe keyword was created to allow safe programs to be created in rust that wouldn’t be accepted by the strict rust compilers.

In a Venn diagram, there are 2 circles: safe programs (1) and programs that are deemed safe by the rust compiler (2).

Circle 2 is smaller than circle 1 and entirely contained inside it. However, there is no reason to not let people write programs from circle 1 that aren’t in circle 2. The unsafe keyword exists to enable programmers to write those programs in rust. However, it comes with a warning, now the programmer is the one responsible for making the program inside circle 1.

A crate having the unsafe keyword doesn’t make the crate unsafe. The unsafe keyword just tells the compiler: “I know that what I’m trying to do may lead to memory safety issues, but I, as the programmer guarantee you that the codeblock as a whole is safe, so turn off some of your checks”.

Using the unsafe keyword in rust is no much different than using a C library in rust.