Hacker News .hnnew | past | comments | ask | show | jobs | submit | wmedrano's commentslogin

Zig gives you more control than Rust, which should theoretically lead to a higher performance ceiling.

There's not much magic in Zig. Keep hitting goto-definition and you can eventually see the OS switch statements and syscalls.


Neither Rust nor Zig give you any more control than the other. If you want raw pointers or inline assembly, Rust supports that.

Technically true, but unsafe Rust is much harder to deal with because it makes assumptions (sometimes very non-obvious) regarding aliasing that Zig does not. You might think you can avoid problems by using T* rather than T&, but every accessible local is effectively a T& so it's still very easy to do something you're not supposed to.

Try it if you want full control over every memory and IO operation and "drop". If you hit "goto-definition", you eventually get to see the OS switch statements and syscalls. There's not much magic.

Do not try it if you are scared of memory management and memory leaks.


We're talking about ~1 trillion $$$ valuations here tho

From the user interface perspective though, it does essentially look like you've pulled all of google3 into your disk.


But is it a local disk? The post above says that one uses Chrome Remote Desktop.


It’s not local storage, but a file system that makes it look like local storage. Even on machines with chrome Remote Desktop it is still stored remotely. So remote to the remote.

Luckily, they still support the text editor + CLI tools workflow so I can still use Emacs effectively.


We've moved on from Git5. Although it was a pain, I kind of liked that Git5 made the monorepo less monolithic to my editor.


Do you mean local checkouts? There's a similar workflow with at least mercurial? Dunno about jujutsu.


You don't really need it anymore - CitC let you do views (mapping just part of the monorepo into your filesystem via FUSE) since about 2013, and then that functionality just got built into Piper. When I returned in 2020 you'd have a file at the top of your source tree that included all the relevant file mappings as well as any Blaze flags needed to build the project, and you could just point your IDE at that and it'd map in just what you need.

The history of Google's relationship to version control is even more interesting than editors - it went from CVS in 1998 to Perforce (P4) in 2000, then gcheckout and g4 in ~2006, then OverlayFS was invented in 2008, git5 came out in 2009, CitC obsoleted OverlayFS in ~2012, Piper built this all into the VCS in ~2013-2014, while I was gone from 2014-2020 apparently we got hg and jujutsu frameworks, and then when I got back in 2020 you'd just check out a .blazeproject from your IDE and everything would magically work. Many of these started as 20% projects (I used to have lunch with the guy who invented OverlayFS; interesting character and one of the best programmers I knew) and then got folded into the "official" way of doing things once grassroot adoption showed the execs that this was how people really wanted to work.


Haven't tried. But there are "IDEs" (Unity) that are really hostile to the idea that your project directory is not a fast local disk that they can both fill with garbage and use fsnotify on everything.


+1. CitC and it's relationship to version control (perforce/piper) is central to all development.

Let's say there were 100M file in the monorepo (an underestimate). You obviously never want to do a git clone of that. But what if clone and checkout were free? That's what CITC did. Creating a new workspace took less than 1 second and got you a FUSE filesystem that looked like it had everything in the repo. But nothing was actually downloaded until you opened files. And your local changes were also stored in the service. And this was available to the CI machines. See where I am going. CI did not have to clone the repo and apply your branch. CI just had your changes available. If you were just testing your 10 files there was no cost to having 100M other source files that were unrelated to your project.

This solves many problems that git worktrees attempt to address, but 10 years earlier, at less local disk cost, and more performant. I miss that.


When I joined in 2016, it CitC would make it look (and still does) like you had the entire monorepo on your local filesystem on your machine.

Git5 would copy some directories but builds would still fallback to files from the monorepo if you didn't track them. It was convenient for me since I could just grep and do fuzzy matching from my editor. Now I have to do some extra work to avoid grepping the entire monorepo. LLMs sometimes still try to grep the entire repo lol.

Now, you could use a perforace, mercurial, or jj interface and it works fine.


I use a workstation specifically to improve latency. Needed to get approval at some point to get a refresh though.


like a workstation under your desk? is the latency bad when you remote access it not in the office?


Yeah, under my desk. I rarely remote which is a good excuse for me to disconnect from work anyways.


I tried going from a budget Lenovo Linux to a Macbook Pro after graduating from university. The hardware was solid, but it is probably my most disappointing purchase.

Right now, I'm extremely satisfied with my workhorse Linux desktop and less so satisfied with my Linux laptop battery life, but I mostly use desktop anyways.


Do you have a screenshot? I just tried Zed out on Linux and biggest issue was that it assumed an rgb subpixel layout.

- https://pasteboard.co/ZDnQm80dHANx.png

- Top is wezterm which is correct.

- Bottom is Zed which uses rgb.

- Both are using Inconsolata though wezterm claims size is 16 and Zed is at 18. I don't have any screen scaling.

*edit formatting


https://wmedrano.dev

I'll write more this year, I promise


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: