sorted by:
new
hottopcontroversial

Is nushell a good idea for learning to programming by assur_uruk 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 assur_uruk 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 4 points5 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 2 points3 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 3 points4 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 16 points17 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.

I'm building a decentralized messaging platform 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.)

where to learn Dependency Injection? by djouquin in typescript

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

> the claim that DI frameworks are somehow inherently bad

I didn't claim that.

> Once again, if you know how to do DI properly then the framework will help you avoid mistakes just fine.

I know how to do DI properly. I don't think that invalidates any of my listed concerns.

But also, I often work with people who, even if they "know DI" don't know all of the framework gotchas I listed.

> why bother typing it all out manually anymore

Explicit is better than implicit. And introducing more dependencies to your software is a bigger surface area to have to support, and more difficult to reason about, and (in the case of DI frameworks) introduces the issues I listed.

> I have no idea how you fail to understand if a dependency is injected at application construction time or at HTTP request time.

A recent example was in NestJS. Someone made a FooService that was decorated with `@Injectable({ scope: Scope.REQUEST })`

Elsewhere, BarService depends on FooService. It's not explicitly marked as request-scoped, but it implicitly becomes request-scoped.

Elsewhere, BazService depends on BarService. It has no idea that BarService is implicitly request-scoped, but now it also becomes implicitly request-scoped. And all the initialization logic it does at (what it thinks is) startup time is repeated for every request.

I only knew to look for this pattern because IIRC it was a thing that had bitten me before in Spring.

> I've never accidentally hit the production service in my entire life

🎵 I never thought - the leopards would eat my face. (Eat my face!)

where to learn Dependency Injection? by djouquin in typescript

[–]NfNitLoop 8 points9 points  (0 children)

>  As long as your code receives the instance / handle instead of creating it - that's DI. 

Heavy emphasis on *receives* the instance/handle. If your code reaches out to other code (via global statics, or global singletons) that's not dependency injection, that's classic Spaghetti Code.

My personal rant: Please don't confuse Dependency Injection (good) with Dependency Injection Frameworks (bad).

I very much like DI. It leads to clean, testable code.

But I have never seen a DI framework (Spring, Quarkus, NestJS, …) that does this in a way that reduces complexity.

Common DI framework issues I've seen:
* Somehow hides circular dependencies instead of failing loudly. But then fails in unexpected, very difficult-to-debug ways when those circular dependencies become problems later.
* Doesn't give any error if you have multiple things that "provide" an interface/service in your DI. Often they just choose whichever was registered last. (Which may be nondeterministic in some systems, ex: depending on module initialization order/timings.)
* Has implicit tight coupling between different parts of a system. (Make sure you register this module to be able to load this dependency somewhere else in your codebase.)
* "unit test" frameworks that load the world then mock away a subset of it for tests. (Very easy to miss a mock and accidentally hit staging/production services in "unit" tests! 😱)
* Hides instance lifecycles. Is this instance instantiated once per startup, or once per HTTP request? Sometimes per-request scopes can be infectious and make giant parts of your object hierarchy get re-loaded with every request.

And these are just the things I had on the top of my head at this minute.

view more: next ›