Subsentient

As soon as I saw mmap(), I knew this wasn't a true native allocator. So yeah, not quite so insightful after all.

Location - Phoenix. Remote is acceptable. I could consider relocating for the right job. Technologies: C, C++, Rust, Python, Lua, C#, shell, heavy embedded Linux experience, wrote an init system in C when I was a teenager.

I can say that I'm a very good firmware engineer with a lot of experience tinkering with Linux and know most of the C language by heart. Currently doing contract work but looking for a more permanent position.

I have a lot of experience in audio/video, access control, extensive multithreading, and low-level networking (BSD sockets)

Nice. Not as impressive as bash, but got a ncurses clone of breakout/brick attack in C. https://github.com/Subsentient/bricktick

I am delighted to inform CrowdStrike that they have just done additional, extensive, damage to their brand, and will no doubt have just emboldened those who were tempted to sue them.

Your unethical behavior and abuse of the DMCA will be used to punish you. If you succeed in getting ClownStrike taken down, you will be hated even more.

Have fun annihilating your brand, reputation, and customer/industry trust and goodwill.

They will not fix this. Indeed, regulation is required, but meaningful change requires a functioning, coherent government with institutions that are not fully enclosed in regulatory capture.

The United States is falling apart, and it is no longer capable of solving its own problems. Now, inertia keeps legacy systems functioning, until fascism and/or balkanization a-la USSR takes over.

Write your own. Wrote one fairly recently in good-ole-sepples that uses UNIX domain sockets and pushes around half a gigabyte a second on weak ARM hardware. Domain sockets are great. Shared memory is even better. If you need a portable solution between processes, not threads, I recommend domain sockets and a simple binary protocol for high throughput.

>TypeScript for C++

Visceral disgust reaction.

Rust apparently wants to reverse its warning logic and instead of banning unsafe{} inside unsafe fn(), they want to require it and make it a hard error.

It's true, what intelligence I have (not particularly impressive) has already caused me enormous suffering.

Yet, there's this piece inside me that tells me that "the only way out, is through".

Sometimes, I think about what I really want. What I want most in the universe, for myself. There's plenty I want for everyone else. I seldom let myself think about what would be good for me lately.

Sometimes, like tonight, I do know what I want for myself. It's impossible, but it's my greatest desire for my life.

I want to be "uplifted". I want my brain capacity to be expanded by orders of magnitude. I want to understand, I want to comprehend, I want to see it all and fully understand the shape and implications of all things in my sight. I want to be more than a human mind. I want to be far, far wiser. It's not power I want. It's knowledge. It's understanding.

Watch all the funding dry up and the researcher get framed for some random, stupid crime, with just enough prison time to make sure he won't see the inside of a lab again before he's too senile to use it or dead. Could also be a slip in the tub etc.

There's a lot of money in suffering, and if you think there aren't people sick enough out there to do real horrible shit to protect that income stream, you're kidding yourself.

How do you think this fucked up civilization was twisted into the giant pulsating tumor it currently is?

Finally, a software fad that I actually want to support! About time I get one!

SQLite is more than good enough for an awful lot of things. Most of the time that I do see software using MariaDB etc, I think to myself "they didn't need a server model for this, SQLite would have been fine".

This is the type of vibe I go for typically: https://www.youtube.com/watch?v=wAmg7h0ov5o

My personal rule of thumb is that if someone is making gurglings about X possibly happening in the future, I will probably take some steps to make it easier if X does indeed happen in the future. If it's something I think is pretty much universal, I don't bother. "What if X" is not good enough, you also need "they were talking about/speculating about X". This rule tends to serve me well.

On every PC I have, the Ukraine "live feed" video at the top manages to start playing on its own as soon as I'm not looking. It doesn't do it at predictable times, but it usually does it as soon as I scroll down a bit, so I have to scroll up to turn it off. https://www.cnn.com/europe/live-news/russia-ukraine-war-news...

As someone who uses both Rust and C++ frequently with a good understanding of both languages, I can say that Rust is for the mostpart more pleasant to work in, but Rust's handicap is that it makes working in raw pointers when you really have to quite painful.

If you need full raw pointers with aliasing mutable pointers, the fact that fn drop() takes a &mut T is a problem that can only currently be worked around with fugly hacks, like nesting your data type in another pointless structure, not to mention the giant pile of ambiguous UB that you risk whenever pointers and references interact that could so easily be avoided if Rust would just implement an -fno-strict-aliasing switch, but the devs refuse on what appears to be ideological grounds. The result is that for unsafe Rust, you get about the safety level of C much of the time, because RAII and many language facilities are not safe to use. Unsafe Rust is currently so dangerous that I feel much safer reaching for C++ for some of it. Mutable reference uniqueness, I think, should be enforced by the borrow checker and NOT by pain of inescapable possible undefined behavior at the assembler level.

Now for C++.

C++ is lacking a LOT of useful safety features that Rust comes with baked in, such as Mutexes owning their data, the borrow checker, a good, fast atomic reference counting type, and things that translate to more safety indirectly, like algebraic enums, assignable and movable arrays, tuples built into the language, etc. Generics in Rust, however, are significantly more painful to write due to the lack of duck typing. Perhaps the Rust devs felt that duck typing was too "dangerous" for templates, but because they're statically evaluated, these issues almost never materialize, and so in practice duck typed templates are almost always superior to Rust's generics.

C++ is definitely more mature and pragmatic as a language, but Rust is probably better for systems programming overall, at least if they fix their goddamn unsafe UB stuff.

As for move semantics, that book isn't for "what you MUST do to keep things semi-safe!" though it contains some stuff to that effect. It's more about optimization and tricks from what I can see. Move semantics take a little while to wrap your head around, but once you know the basics of C++'s move semantics, you can pretty much figure out what's going to happen by looking at a class' definition briefly.

Haskell gives me headaches. I write a lot of Rust, which has elements of both. I think their approach is pretty good, though sometimes regular inheritance would just be easier.

I don't hate OOP. I don't love it either. I tend to write my code in a mix of procedural and diet-OOP paradigms. It tends to produce less state, less inter-dependencies, and doesn't require abandoning stuff like mutable state.

Why do I want mutable state so bad? Because it's the easiest, least abstracted solution to the problem much of the time, and closer to what the compiler will actually want to generate.

I think trying hard to stick to a single paradigm is folly. I like mixing and matching according to the task I'm attempting to accomplish, and I have a firm conviction that my code benefits from this ideology. Encapsulation I do value, but not as a "hard no". I use access specifiers to tell you "you probably don't want to mess with the guts of this thing, it can take care of itself better than you can."

As for inheritance, I don't use it very often. I like how C++ has no base "Object" class. A lot of the time I'm basically writing structs with methods, and I think that's often the right approach.

Eh. I just cast both to a bigger integer type where possible, which in practice, is almost always. So if I'm averaging two uint32_ts, I just cast them to uint64_t beforehand. Or in Rust, with its lovely native support for 128-bit integers, I cast a 64-bit integer to 128-bit.

Can you still install Linux on the new switches? If so, I might have an interest in one. If not, it's just more walled garden garbage.

The big issue I had with learning Rust is not the simple stuff -- I could write safe Rust fairly quickly. The problem I continue to have is that many internal behaviors of the language are totally undocumented and inexplicable. For example, implicit reborrows. They happen everywhere, but it's still just a pile of unicorn farts as far as documentation. The idea of a language with no documentation for a given syntax is horrifying. Rust does very well in documentation for beginners, but if you actually want to understand the language, if you want to know what's really happening, you're usually fucked.

Well I have nothing useful to add other than my personal priorities for a job, in order of importance. I'm a whiney little bitch when it comes to this stuff.

People/Environment -- If I hate the people I'm working with, I'm not going to stick around long. I've quit jobs for that reason before, and I would do it again. I have a low tolerance for assholes. For example, worked for a vending machine OEM that shall not be named. Boss was filthy rich and said "oh we'll pay for you to go out here to X!" and then had me ride a fucking Greyhound. I should have bailed right then and there, but I gave it a try, since I was young and fairly new to actually getting paid for my work. Guy had a new secretary every other week, and they always looked like they were one sharp comment away from swan-diving into a wood chipper. I've never seen office workers with that much terror in their eyes and voices before. Needless to say, I didn't stay with him long. Paid well, but getting technical specs, tools, and the data I needed for projects was like pulling teeth from a methed-out rhinoceros, and that proved to be the last straw. I remember once I was told to my horror and disbelief that they had literally completely lost core technical specs that I needed for the project, then they wanted to know why work was progressing slowly. At that point I just quit. Tried to ship his equipment back to him but the cheap motherfucker wouldn't even pay for the shipping, then just stopped talking to me when I asked him to. Guess he didn't care about the vending machine parts. Ironically they were worth more than the shipping, and totally worthless to me.

Integrity -- I look for a company that isn't actively making the world a worse place. I don't mind boring code, as long as I can write it well and be proud of what I've created at the end of the day. What I do mind, however, is predatory practices, unethical dark patterns, and user-hostile design and terms of service. If I think you're Facebook 2 Electric Boogaloo, I won't apply in the first place. If I think you're the "good guys" however, you'll have undying loyalty. *Sidenote: Sickens me to hear that so many of my fellow developers are willing to worsen the world for an extra zero on their check.*

Technology -- You must be asking me to use a language/toolkit/etc that won't make me want to blow my brains out every day at 5:01pm. I can work with tools and languages I don't particularly like, but do not, for example, ask me to build you an Electron app, PHP backend, or Java app. I will walk rather than endure that. Maybe some help in an emergency, but if you make that my main duty, I'm done. I'm fussy, but that's just me. It's very important to me personally to be able to respect the tools I'm using.

Autonomy -- I hate being micromanaged. I'm not incompetent. I've created programs with hundreds of thousands of lines of C++ and Python code by myself. If you second-guess every tiny decision I make over long periods, I will descend into quietly loathing you at the very least.

Money? -- I'm not a greedy person, but don't insult me. At least pay me something close to market. There's great irony in that statement right now, as I'm not making even close to what I'm supposed to (basically poverty wages for some of these months), as I'm trying to help a tiny startup keep its head above water because the boss is actually a decent guy and someone I respect. I suppose it illustrates just how much the kind of people I work with matters to me.

I suppose for OS utilities targeting a specific platform only, that makes sense. But for portability, you sure as shit shouldn't be trying to write a custom GUI using the native OS GUI toolkit for all three platforms. It's surprising how many make this mistake. It's like they've never heard of Qt and are surprised development takes forever.

While that may be partly true, Electron inherently attracts low-skilled, incompetent programmers due to its 'easiness', while in reality JS isn't that much easier than, say, Python. Not only do you have to deal with dumber programmers writing the code, but what people forget is that CPU and RAM usage isn't just some metric you see in htop or Task Manager. Electron apps are much slower than native apps at doing almost anything, sometimes to the point of obscenity. That was a big reason we were forced to ditch Electron, the WebKit bullshit was just too much for what we were trying to do. No matter how many bugs I fixed, it was still a bloated sack of shit. Qt was easy to write. Sure you had to put a few #ifdefs here and there, but for the mostpart, it was portable, easy, and Qt Creator saved us a ton of time compared to baking our own. If you write any application in "native" widgets for the host OS, shame on you. That is definitely the wrong way to do things in almost every case nowadays. That said, Qt and GTK+ provide so much better of a user experience with only slightly increased difficulty. It's hard to justify Electron.

The company I work for hired several incompetent devs who wrote an abortion of an Electron client. It very nearly killed the company. I finally convinced the boss to let me rewrite it in Qt, and now our feedback is far, far more positive on the UX. Qt and GTK+ are one of those things that work "well enough" on the big three, especially Qt (GTK+ has serious theming issues on macOS), and it's hard to justify Electron as long as Qt or at least GTK+ exist.

Fuck Electron. I've seen what it can do to a product firsthand. If you get a competent web dev, it might work, but it will be slower than snail shit. Just write it in Qt. You don't need to use C++, Qt has bindings for many languages, including Python, Rust, JS with Qt Quick, and even Lua. Myself, I don't mind modern C++, though in many cases I prefer Rust.

Just reading the title of this post gave me a most perverse hearty laugh. I strongly applaud the deranged motherfucker who decided that implementing a quantum computer in SQL was worth the effort. Next up: D-Wave emulator in COBOL.

Interesting. I've hit this bug before, but not often in Python as far as I can remember. I guess if I need a huge list of something, I'm more likely to look to a dict than use a list with normal indexes.

Joke's on you. I don't have any good days. :^)

Just like the heretics are usually the most deeply principled.