Yes, in general, but also there are cases when you realize you can, idk, parse a CSV file in 0.2 seconds instead of 200 seconds. That kind of improvement unlocks a new level of tinkering.

As for the language itself, it's going to be more verbose than your Python code. Cons: you'll have to spell out a lot of things that you thought were obvious assumptions. Pros: you will be able to look at a page of code and know with a great degree of certainty that there are no hidden gotchas. No monkey patching, no __init__. Basically, it just does what it says on the tin.

And finally, about the std lib and batteries: there's HTTP(S), compression algorithms, hash algorithms, RNG, I/O, the basic data structures you'd expect, JSON. Third-party libraries, if you choose not to vendor, are handled by including the repository url in a file (also automated by a CLI command), and then adding it to the build script (not automated). The `zig` command handles fetching and ensuring sanity, but otherwise assume a bit of elbow grease will need to be involved.

In my experience, this (for now) is mostly aspirational. It's obviously a major goal, and there are clear milestones outlined on how to achieve it, but in practice the initial compile of an empty project or the excruciating pause when you `direnv allow` and ZLS needs to be (re)built are not what I'd describe as "terrific".

Such a brave stance against a claim literally nobody has ever staked.

In my case, when I start a little Typescript side project, instead of drowning in the sea of npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime/etc I can just use one thing. And yes, only some of those are Pokémon moves and not actual tools from the JS/TS ecosystem.

So, hopefully, the tech people involved in choosing a database for their project understand that, and do their own correctness and performance testing before making a decision. As for the business people, the tigerbeetle.com landing page doesn't mention Zig at all, although it probably will come up when they "ask AI" for a comparison. So, yeah, probably some risk. Perhaps the LLM will also point out the Jepsen report on Tigerbeetle to offset it.

The latest x86_64 Linux build is 136MB. (https://zed.dev/docs/linux#downloading-manually)

As for your list of grievances, they all seem to boil down to the respective LSPs not doing their job? Does Ctrl-Alt-l (lowercase L, not Shift+i) include the language's server in the context menu, and are there any errors reported for it if it does?

Vote in elections, local and general.

Comments URL: https://news.ycombinator.com/item?id=47551847

Points: 62

# Comments: 39

Anyway, I skimmed the file for you this time, and basically you're either correct or wrong, depending on your definition of "error checking." The code handles error conditions by aborting the process. Seeing as it's a standalone CLI program and not a library meant for reuse, safely shutting down with a meaningful message sounds like fair game to me.

I am guessing that Python, like Ruby, is dynamic enough that it's impossible to detect all typos with a trivial double-pass interpreter, but still.

Wonder if there was ever a language that made the distinction between library code (meant to be used by others; mandates type checking [or other ways of ensuring API robustness]), and executables: go nuts, you're the leaf node on this compilation/evaluation graph; the only one you can hurt is you.

How about "Hey, your Bean ain't sprouting"? :)

I'm sorry, I feel like I'm not communicating this properly. Um, have you ever discussed with someone a book or a TV show that was translated into your language? Did you have problems referring to the exact parts you liked or disliked? :)

  class Bean {
    private boolean sprouted;

    public void sprout() {
      this.sprouted = true;
      // ...
    }
  }

  data Bean = Dormant | Sprouted
  
  sprout :: Bean -> Bean
  sprout Dormant = Sprouted
  sprout Sprouted = -- aw, beans, we could have modeled
                    -- this state as impossible to construct,
                    -- but you chose runtime checks, so
                    -- here we are.

Imagine all the hours saved that are currently spent on tired tabs vs spaces debates, or manicuring .prettierrc, etc etc. The color of the bike shed might matter (sometimes a lot) to some people, I know, but it's storing bikes away from the elements and thieves that is the goal, not obsessing over optimizing something that is demonstrably a subjective matter of taste.

I guess Unison is the closest to this platonic ideal right now? https://github.com/unisonweb/unison/issues/499