If you need, I can pose as a consultant and tell them to use whatever you want.

Which - out of curiosity - is what? My personal projects I go 100% vanilla and implement all my own controls as custom HTML elements (sort of like web components, but I typically avoid shadow DOM because it's more headaches than it's worth).

But my personal projects don't have the same level of seriousness as a business project does.

With all the time and code you guys spend and write on devRant peripherals, you could have made sox clones by now. At this point just steal the SVG assets and republish them, dfox isn’t even active enough to shut down the site let alone sue you for stealing.

@Lensflare I don't quite see myself working with Swift or Kotlin in the foreseeable future, unfortunately. I do quite like Swift though, maybe I'll spend a weekend with it one of these times.

@Lensflare That's the tragedy, isn't it? Excited to learn it, but crushed by the reality that it'll only ever benefit me in personal projects or academically.

@Lensflare I think so because on a daily basis I work with other people's code and I can barely think of any place besides a really techy place that will actually use algebraic data types, let alone a language that implements them.

@Liebranca In reference to what you actually said, I agree. From my reading, the real benefits of functional languages is they're optimized for recursion (or, more to the point, they're more optimized to turn recursion into something actually performant!)

From the code I've been writing, it's a lot more difficult, but the code ends up being shorter and a lot closer to what you're actually trying to do.

Like, I saw a quicksort (unoptimized) that was essentially just the algorithm in plain f#. There was barely any implementation, it was just "here's how the algorithm works, here's how to say that in f#, done"

https://fsharpforfunandprofit.com/p...

@Liebranca I spent today studying F# and I can confirm the stdlib is the main drawback: it's designed to be compatible with the .net framework 100%, so the function calls are not curried by default, they're tupled. So insted of calling them in a functional way, you call them in a traditional c# etc way;

F#:

print "hello %s" world

F# Standard library:

print("Hello %s", world)

Which was a major disappointment, so I'll be shelving this functional thing and moving to Haskell when I get the itch again. Shame.

@Liebranca seems like it’s a trope in the functional space :(

@12bitfloat @retoor ya, my opinion is definitely an outsider's one, that's why I said it was null from the start. I don't know much about Linux or Rust so I'm just guessing. I've seen some of the drama between Linus and the Rust for Linux community and that's basically all I'm working off, besides the two days I spent with Rust before getting bored and moving to Zig instead (fun!)

This is actually a real thing! I watched a YouTube video on Film Noir last night.

Noirvember has a wikipedia page!: https://en.wikipedia.org/wiki/...

As someone who wrote a fairly large JS-only backend and then abandoned it exclusively for the reason it was JS-only, let me give some insight (TypeScript only has a subset of these issues, the build system actually is really nice for adapting JS to the back-end):

- It's great for really small stuff. I still recommend it as a backend for dev servers, simple game servers (like slither.io, whatever), etc.

- It scales horrendously. I was even using modules, not CommonJS, and shit was just awful. Refactoring only worked half the time, so once you write code and start to use it, you're basically stuck with it.

- Performance *does* stink. You can point to benchmarks where bun outperforms assembly or whatever, but at the end of the day, you're writing a scripting language that lives on the stack. If you need to do something that requires high performance, you're going to need to write it as a micro-service that your backend calls out to.

... more, but I'm out of comment space.

I don't really give a shit about the memory safety of Rust. You can write memory safe c code, and c code that is the age of the Linux kernel (plus, the extra set of eyes helps, being the largest collaborative software project on the globe) typically is memory safe anyways.

It's mostly just that c *will eventually* fall out of style. It's already largely out of style. Business applications simply are not written in c anymore. While most devs can make their way around in a c codebase, there are vanishingly less c professionals that work with it daily. That's a bad thing.

But a newer tool, like Rust, that genuinely finds its way into non-niche business applications regularly, has a professional pool to pull from. People that use it at work, then come home and work on open source projects for fun or whatever.

In the next few years I'm honestly expecting a fork of Linux to be completely re-written in Rust, without Linus.

I'm torn on rust-for-linux.

For one, I'm not a Rust dev, so my opinion is largely null anyways.

I am a c/c++ hobbyist, though, and updating the tool chain isn't that bad of an idea from this perspective.

I think the Rusty conversion will be good, but it will take time. A bunch of lifeless hacks will half-implement buggy versions just because they're Rustacean fanboys and want Rust in Linux. We're probably in that stage now.

Then, once things get noticeably bad, genuinely good devs will step in and either replace or fix the shit-tier code hastily written by the hardcore Rustaceans.

Well if it's an internal tool, then that's a horse of a different color, especially if all 8 people are also responsible for maintaining the database.

There should still be a prod and dev environment though, and there should still be a promotion process for database changes from one to the other.

At least the Sr. eventually came around to admitting their mistake. You could be stuck in a bureaucratic loop of "I'm the sr on this project and what I say goes. We already started this way and now your job is to implement it until it's 5x as complicated as it needs to be and you want to kill yourself"

the zip format is an archive format with optional compression. It uses the DEFLATE and INFLATE algorithms along with LZ77 (or something like that idk) run-length encoding (RLE).

Choose a language that you want to learn (maybe haskell? :D) and implement it with UTF-8 file name compatibility!

@12bitfloat well, they sort of need to, or else the global economy will take a dip.

And they sort of won't, so buckle the fuck up I guess.

@spongessuck I've been using insider starting this week (at home, not work).

I've had my fonts reset in VS22 without even so much as an *update*. No idea why.

Well, VS is a monster codebase made out of at least 58 different technologies and before VS 2015 (or so, I don't really remember) you couldn't even *uninstall* the program.

That probably has some clues.

We worked with RAGs at work.

After a few months, we stopped working with RAGs at work.

It's a retarded system that cannot be perfected, only a % of accuracy will be achieved.

Semantic search SUCKS for specific information. For example, if you have a bunch of data that says "my phone number is xxx-xxx-xxyz" and then you ask "What is Sandy's phone number" it will say "I have no fucking clue!" because RAGs suck dick.

The best approach is hybrid - have a RAG that searches both a semantic index AND a traditional index. This way, you get both semantic and literal matches.

But it's still just throwing more money at the bullshit and hoping it grows into a flower. For us, it never did, and we got bored of spending money.

Good luck!

To be fair, if it exists in c, it also exists in c++. There was probably no rush to implement something that's already available.

@Lensflare I got iOS 26 the day it came out and have used it daily every day since. I generally can read it, but the old UI has a 100% success rate and the new glass is more of a 96% success rate. And I don’t even like the way it looks so it just got worse for no real reason!

Yeah well, when you get paid retail wages, you’re not a tech bro. You’re a retail salesman.

I returned a router the other day and he said “what’s wrong with it” and I said “the 5 ghz band has no internet access” and he was like “okay what’s wrong with it though”

Really awkward but what do you expect, an engineer?!

It should be allowed. Just like googling should be allowed. You should be allowed to use all the tools you normally use. It’s not a quiz, it’s an assessment of your skills: toolchain included.

That being said, you should be judged on your AI usage appropriately. Just like if you were to copy and paste your whole interview from Stack Overflow, using AI to generate your entire interview should be a FLUNK. The company wants to evaluate your productivity, yes, but they also want to make sure you can do work without grinding to a halt if AI spits out the wrong answer. Maybe get ahead of the game and give interview questions that AI struggles at or is difficult to solve with AI.

Hating on tools is for perfectionists. Us guys that need to meet deadlines don’t care about tools as much.

Without looking it up, here's my interpretation:

HashMap is just a regular hash map with an array on one side storing hashes, and a value on the other side (depending on implementation, this is typically a list due to collisions in hash maps)

HashMap = HashMapEntry[ {bin hash, HashMapValue[ ]} ]

LinkedHashMap sounds like the same thing, but linked list driven?

LinkedHashMap = Root = {bin hash, HashMapValue[], Node next}

@12bitfloat no idea frankly, all my comptime stuff is generally just lookup tables.

@Lensflare Zig was the first place I tried comptime code gen, and it was seamless. Completely wonderful, in fact. Barely any limits at all, you just write regular code (which *reasonably* can be comptime), denote the code and all of its inputs and outputs as comptime, and done.

As someone who got their degree in database design, this would be fun actually :)

xcodesucksanddontevengetmestartedoncontacts

I googled it (do not own a mac, just a poor boy) and it looks kinda cringe. I imagine it gets a lot worse if you actually try to use it. That's my honest take on the new liquid glass stuff (I have an iPhone, I'm not *that* poor of a boy).

The new iMessage app on my iPhone in particular seems really janky. The liquid glass in general is a little hit-and-miss (I HATE the outside shimmery border effect) but the new iMessage app, despite having some nice features like background pics now, just works like ASS. Scrolling up and down your messages is so janky, going from the list of messages to the chat view is janky, sometimes the bottom of the most recent text gets cut off, etc etc. It's so obviously the first version of this software that it's painful.

In 5 years, when they shake out all the kinks, liquid glass will be okay. Right now, it's *just* okay.

@BordedDev you mean Cherno? Cherno mentioned on my fucking 15-people-left dev ranting app?!?!?!?

Unrecognized symbol "hey" at line 1: "hey babe just letting you know I severely miscalculated the level of bullshit that this thing at work would be, and I need to finish it today or else my boss will crawl up my ass and tear me a new one from the inside-out. Love u". Maybe you meant to type that Into iMessage?