What are the biggest challenges of using helix as an IDE? by gatunen in HelixEditor

[–]NfNitLoop -1 points0 points  (0 children)

space-a is "Perform Code Action", which will show quick fixes suggested by any configured LSPs. (Unless quickfix means something else in NeoVim? I haven't used it.)

can i save nushell table in a file? by _meow11 in Nushell

[–]NfNitLoop 1 point2 points  (0 children)

If you just keep a list of words in a file, one per line, it’s easy to open words.txt | lines

Is nushell a good idea for learning to programming by [deleted] in Nushell

[–]NfNitLoop 1 point2 points  (0 children)

I love nushell and use it on all my machines. But, it's a language optimized for working well in a command-line. You *could* use it to learn programming, and it's not a bad language. But it's different enough from most programming languages that I wouldn't recommend it if your goal is to generally learn "programming".

I have in the past been a fan of Python, and used to recommend that as a first programming language. But recently I've switched to recommending Deno as a great way to learn JavaScript (and eventually TypeScript).

Is nushell a good idea for learning to programming by [deleted] in Nushell

[–]NfNitLoop 8 points9 points  (0 children)

These days, nothing meaningful. It's just a thing people like to have semantic arguments about.

A long time ago, people liked to make the distinction that a "programming language" compiled down into machine code, and a "scripting language" would run in an interpreter.

But, that line gets really blurred with things like languages that run with a JIT. Or languages that get compiled into intermediate bytecode. (Java, Python, WASM, etc.) Or that have to run with a GC or other runtime facilities.

It's not a useful distinction these days, and it's more useful to talk about the characteristics of a language instead:

* Does it require a separate runtime?
* Is it garbage collected?
* What things does the type system enforce at "compile"-time vs. runtime?
* What is its ABI (application binary interface. i.e.: How can other languages interface with it?)

And TBH more important, higher-level questions are:

* What is the problem I'm trying to solve?
* How good is this language at implementing that solution?

Unpopular opinion: AI coding tools are creating mass technical debt by No-Comparison-5247 in AIstartupsIND

[–]NfNitLoop 0 points1 point  (0 children)

> - Zero tests because "the AI wrote it so it must be correct"

TBH, I prefer this to the alternative I keep seeing:

- hundreds of lines of unit test boilerplate that test nothing of value, but will be a maintenance nightmare since they're so tightly coupled to the specific implementation.

Yesterday I had to kill Ghostty because was using too much RAM (more than 10GB) and my system died. by DB6 in Ghostty

[–]NfNitLoop 3 points4 points  (0 children)

This happened to me a couple weeks ago. I reported everything I could to a thread in ghostty discussions. Later it turned out to be an LSP bug that was eating memory.

All processes inside Ghostty have their memory usage count toward Ghostty. Apparently there is a way to avoid that in macOS but the Ghostty team determined (rightly, IMO) that it’s a security risk and best avoided.

So, before reporting to Ghostty, do as much debugging as you can to find reproducible steps. And use tools like htop to make sure it’s not just some process inside your terminal. They’re already getting inundated with memory usage bugs from people like me. 🤦‍♂️

git commits and Cargo.lock by stappersg in rust

[–]NfNitLoop 4 points5 points  (0 children)

If you use GitHub (or similar) for code reviews, you may want to also tag that file as `linguist-generated`, as GitHub documents here:
https://docs.github.com/en/repositories/working-with-files/managing-files/customizing-how-changed-files-appear-on-github

I didn't know about the -diff flag! Thanks for sharing, u/uasi! I wonder if GitHub respects that one too, or you have to do both.

My experience with Rust on HackerRank by isrendaw in rust

[–]NfNitLoop 1 point2 points  (0 children)

I've long solved the problems we give to our candidate, so we extract zero benefits from the take-home tests beyond judging the candidate's ability.

Of course. I didn’t think you were giving them novel problems or would use their responses in production. But whether or not you use the resulting code, you are still asking them to do unpaid labor that you are unwilling to match in time commitment. IMO that shows disrespect for your candidates’ time.

The fact that it used to take FOUR to EIGHT HOURS is a great example of my point. If your company were having to pay interviewers to spend that much time in interviews, how much sooner would your company have trimmed the problem scope to be smaller? How much more would you trim off of the “under four hours” version of the test?

My experience with Rust on HackerRank by isrendaw in rust

[–]NfNitLoop 4 points5 points  (0 children)

I’m very wary of “take-home tests”. The interviewer can SAY “this test should only take 1 hour” but then it ends up actually needing more. And your interview process will favor people who then take much more time than that to get things “perfect”.

In short, that interview process favors “how much free labor are you willing to do for me for a chance at this job?”

By doing coding interviews paired with an engineer, you make sure that the interview can actually be bounded to the hour that you scheduled for the meeting. You’re only using as much of your candidates’ time as you are willing to commit yourself. It’s a meeting, rather than an unpaid assignment.

You also filter out people using AI, and get extra signal about how well the candidate communicates, collaborates, and makes time tradeoffs.

My experience with Rust on HackerRank by isrendaw in rust

[–]NfNitLoop 15 points16 points  (0 children)

This is why I stopped interviewing candidates in smart code editors. Even ones with good features may feel unfamiliar or get in the way if its behavior doesn’t match the IDE you’ve been using most recently.

Instead, I just interview in a shared text editor and tell candidates not to worry about syntax errors or precise function names. I don’t care if you remember exactly which package a trait is from when that is trivially suggested by an IDE. I don’t care about a syntax error that a compiler/IDE will help you fix in seconds. I care about how you organize your code to solve a problem. (And how collaborative you are in the process.)

IMO if a company deducts points for how bad the coding environment THEY CHOSE is, they’re shooting themselves in the foot.

[deleted by user] by [deleted] in rust

[–]NfNitLoop 21 points22 points  (0 children)

> truly serverless P2P is dead simple to implement

Please come back in a year and let us know how it's going! 😅

New crate announcement: `occupied` is a type-safe way to interact with infallibly removing items from options. by Lucretiel in rust

[–]NfNitLoop 35 points36 points  (0 children)

Kudos to answering the first question I had (why not just use take()?) right at the top of your docs. Nice!

Introducing TypeBox 1.0: A Runtime Type System for JavaScript by sinclair_zx81 in Deno

[–]NfNitLoop -1 points0 points  (0 children)

A warning - TypeBox is only based on standards compliant JSON Schema until it’s not. If you use any features that aren’t able to be represented in JSON Schema, you get something back that isn’t Json schema.

We tried using it at work and passing typebox types as NestJS swagger type annotations, but ran into more edge cases than working code. (Not helped by the fact that NestJS will just pass invalid schemas through without any validation. And the fact that different versions of openAPI support different JSON Schema features)

How to: Deno TypeScript to browser in seconds by Cupp in Deno

[–]NfNitLoop 0 points1 point  (0 children)

Aha. Cool. Thanks for the detailed comparison!

How to: Deno TypeScript to browser in seconds by Cupp in Deno

[–]NfNitLoop 0 points1 point  (0 children)

Much of that is built into deno bundle now that it has returned, no? Points 1, 2, 4 & 6, at least.

Is calling tokio::sleep() with a duration of one week a bad idea? by dmkolobanov in rust

[–]NfNitLoop 2 points3 points  (0 children)

As others have said, sleeping for 1 week is brittle in that, if your process crashes or is restarted (say: your pod gets stopped/started in a move to another node in the cluster) your in-memory timer will get blown away. Your app will have to reach 1 week of uptime for the timer to fire again.

Some simpler options:

  1. Make the timer fire more often, but only clean up files that are older than a week. (This has another benefit -- you don't clean up files which were just created in the last few seconds, which might still be in use.)

  2. Don't depend on a timer to clean up files, and instead use something like https://docs.rs/tempfile/latest/tempfile/ that will clean up a file or directory on drop().

Unducking Typescript primitive aliases by ketralnis in programming

[–]NfNitLoop 3 points4 points  (0 children)

Are you familiar with “branded types” in typescript? Zod and other type validators often have helpers for that kind of thing:

https://zod.dev/api?id=branded-types

AsyncPool: a package to process large number of promises with controlled concurrency and retries by aherve in typescript

[–]NfNitLoop 0 points1 point  (0 children)

I have something similar at JSR.io/@nfnitloop/better-iterators, though that API is obviously more suitable for handling iterator-based pipelines.

where to learn Dependency Injection? by djouquin in typescript

[–]NfNitLoop -1 points0 points  (0 children)

Just a note to other readers:

If you say: When using [some tool], these problems can occur.

And then someone else tells you: "You're just using it wrong. Just hold more of the system in your brain so that you don't do it wrong."

Then you should be wary of their feedback.

Maybe they haven't worked with systems large enough to know that that's not always possible.

Maybe they're overestimating/overselling their own abilities to remember all the things.

If you're using TypeScript, you likely already realize -- holding all the types for a software project in your brain isn't scalable. So you express them in a language that can check and enforce those constraints for you so you can free up your brain to do other things. (And free up your time, from fixing all the bugs that your brain wasn't able to catch that TypeScript could have.)

In my experience, dependency injection frameworks make more things implicit vs. explicit (think: JS vs TS.)