neurotrace

I'd love to see some performance metrics and if there are any guard rails against circular dependencies.

I'm a fan of using the extensions the author mentioned when I'm exploring a problem space. I scaffold out the overall design for the problem in terms of modules and functions so that the code reads correctly, type checks, and works for an extreme subset of inputs. Anywhere that I haven't actually implemented the real solution I put in a "NO-MERGE" comment. Then when I feel that I've solved the problem at that scale, I can go through all of my NO-MERGE comments and implement them correctly. As the name implies, these are never merged in to main/master. They just act as bookmarks which should be obvious when reviewing my changes.

Personally, I try not to commit any TODO comments. They're sort of like warnings. Unless you're religious about clearing them out, they're just going to build up and be ignored.

I'm honestly surprised at the response to this article. I'm not involved in the Rust or Go spaces enough to have any strong opinions. This article was, yes, a little aggressive in tone but presented very honest and accurate information about a language that the author clearly has experience in. It seems like a lot of the people complaining in the comments didn't actually read the article. The author even explains how those who have bought in to Go may not want to hear what they're saying and it's right. No one wants to hear that their baby is ugly but sometimes it's the truth.

To those who do use Go: someone can call your baby ugly and you can still love it.

> Why would you be worried about vendor-lock if you haven't built anything?

When else would you worry about lock-in? The early stages of a project involve setting up the foundation. If you build your foundation on vendor-specific tech, you've just locked yourself in or signed yourself up for a very painful transition in the future

If JS had no effect on the experience of the page (or the loading of it) then no one would write it. Personally, I don't generally mind running a bunch of JS but I understand why people don't. I use both the modern web and Gemini

I've gotten so used to seeing variants of Wordle that I read "Redditle" and immediately thought it was some sort of Reddit-based Wordle

You're right. Lifting a coffee cup with poor ergonomics isn't going to cause any injuries. Typing for hundreds of hours over many years in a poor position can lead to problems such as RSI.

Good point. I have always run integration tests with Postgres etc. and have found value in it. I do think that you should have a substantially smaller set of those sorts of tests though.

Not OP but I avoid default exports unless I need to do a lazy import. For me, there's a few reasons: consistent naming, easier importing, encourages importing what you need, avoids weird situation where you do both a default and named import.

Consistent naming: since I named the exported thing, that's what the consumers will call it as well unless they go out of their way to do `import { X as Y } from '...'`. This is useful because it helps ensure all consuming code looks similar at least in it's usage of modules. More familiar code is easier to read and reason about. It's also useful for looking up usages of something. I know I can run $IDE's version of "Find Usage" but sometimes it's easier to just Ctrl+Shift+F > X.

Easier importing: If I have something exported as X then I go to a module that isn't using it and I type X, my editor will suggest I import it from the appropriate module. This _can_ work on default exports but only if you use the same name as was used internally at the point of definition. That kind of defeats the benefit of default imports where you can use whatever name you want without hassle and it's your responsibility to make sure you match the names correctly.

Encourages importing what you need: when you default to named exports, you default to pulling in the bare minimum to do the job. Consider the opposite case. Someone imports some monolithic chunk of code as a single object then does `library.thingIWant` with a bunch of different things. Now you've got a larger possible space to look at when trying to load all of the context of a file in to your head. This is also useful for tree shaking. Assuming you've written your code in a well-defined manner and are using a smart build system, it can more easily eliminate dead code because it knows you never import certain pieces of a module. This applies to both your code and code from third-parties.

Both default and named imports: This is common when working with React. You'll see `import React, { useState } from 'react'` or similar. I don't have a rational answer for this but it rubs me the wrong way.

> Finally, in terms of organization, I want things to be organized by function, not by feature.

I found this super surprising. I much prefer doing things by feature than by function. Where it goes is a function of which page/view/route it's on. If it's a general purpose component that is used on multiple pages (like `Button`) then, sure, it goes in `src/components`. Otherwise, it goes in `src/routes/app-section/components`. Truth be told, I've taken to doing a setup like this:

    src/
    - routes/
      - app-section/
        - effects/
          - some-action.effect.ts
        - ui/
          - app-section.component.tsx
          - index.ts
          - some-component.component.tsx
        - app-section.route.ts
        - app-section.types.ts
        - index.ts
        

`effects` basically holds your business logic, `ui` contains section specific components and exports the top-level component via `ui/index.ts`, `thing.route` hooks up the route to state management, `index.ts` provides a bundle for hooking up the effects to your effect system and the route component itself. The `name.type.extension` naming scheme clears up the tab name confusion problem. Maybe I should write my own article about this ;)

I'd argue that you should have thorough unit tests for each service to ensure that they always respect their public API. Additionally, in a monorepo you can share type definitions so regardless of the service, you know for sure that you're using the right API. If all of that is in place then you can test the integration by just mocking out those services rather than testing their API n times.

If you're in an environment where you have limited/absence of type checking then you're right. In my experience, most problems that come from the integration of networked services come from not properly accounting for all possible responses. You're expecting to get a 200 response and a field of `x` but you got a 204 so the response is empty. That sort of thing.

Absolutely. I recently dropped in to a job where I was led to believe I'd be spending most of my time architecting applications but I've spent most of my time on ops stuff. Every engineer is expected to have more than a working knowledge of AWS, Terraform, and Kubernetes. I don't know how anyone gets anything done

> And in the next few sections it includes someone who wants to build on the proposal including using type hints to optimize code.

This changes literally nothing about the JS language. JS engines already attempt to determine the types of things to optimize the code they generate. Type annotations would just allow them to make more aggressive optimizations.