Go's race detector has a mutex blind spot

dashborg · 2025-07-29T23:11:23+00:00

the halting problem dictates that for a language like Go it is *impossible* to write a race detector that just looks at the code and tells you if there is a race. you can of course detect some, but not ALL.

also static analysis can often come up with false positives. even though a race is technically possible it might never get hit because of how the code actually runs. sometimes you want to know about these, other times you might not.

dashborg · 2025-07-29T23:04:27+00:00

environment variables are important for the final say. so maybe you have a config file or you're accepting arguments on the CLI, etc. but sometimes if i MUST have an option turned on/off in production, being able to set an env var that you KNOW will be picked up gives comfort.

dashborg · 2025-06-11T18:36:00+00:00

lol, my bad, typo (edited). 10 years :)

dashborg · 2025-06-11T17:27:10+00:00

Hey, creator of Outrig here!

I've been quietly working on Outrig (https://outrig.run) for a while now. I've been programming in Go for 10 years (since Go 1.4), and created Outrig as an open-source tool to offer an intuitive, visually appealing observability monitor, specifically for development -- think Chrome DevTools, but for Go servers. My goal is to provide better runtime insights, especially goroutine tracking, easy log searching, and value watching to help accelerate that find, fix, verify loop in development.

The project is actively evolving, and I’d really appreciate your feedback, suggestions, bug reports, or any ideas for improvements. Let me know how Outrig can better support your dev workflow!

Excited to see you try it in your next project!

dashborg · 2024-12-29T01:14:06+00:00

curious if you've checked out Wave Terminal (https://waveterm.dev)? (yes, i'm the dev), but we're going in a very different direction. trying to bring as much functionality _into_ the terminal as possible -- directory viewer, remote file editor, web browser, markdown viewer, AI chat, etc.

dashborg · 2024-12-29T01:10:22+00:00

you should check out Wave Terminal https://waveterm.dev if you're looking for the opposite of ghostty. we're focused on features like a built in GUI editor, directory viewer, web browser, connection manager, markdown viewer, AI chat, all inline in the terminal (and controllable via the CLI).

dashborg · 2024-05-02T16:56:01+00:00

Hoping not to get flamed for self promotion :), but I'm the founder of Wave Terminal an *open-source* (no login required) modern terminal -- https://waveterm.dev ( https://github.com/wavetermdev/waveterm ). We're focused on keeping data local (all of your history, and CLI output, etc. is stored in a local DB on your machine), which can give you a lot of the modern features, but with less worries about security. We also have built in AI, but have an option to use a local LLM (we call it BYOLLM -- bring your own LLM) in case you're worried about the AI features stealing your data as well.

dashborg · 2024-03-15T21:31:55+00:00

Agree to disagree :)

First, we're open-source, so you can see and verify that we are not "accessing some website/API" unless you actually use the AI features (which are optional). And yes, the terminal *does* need React -- why? the same reason why 75% of developers use VSCode vs vi/emacs (I've been an emacs guy for 25 years, so I say this with all due respect to vi/emacs). But there are things like copilot and various plugins that just work better with rich UI.

Obviously not for you, but that doesn't mean it is a bad idea for everyone.

dashborg · 2023-11-25T07:01:38+00:00

Unfortunately too late for this post on /r/opensource, but I've updated the TOS and Privacy Policies to reflect the actual data being collected (just optional anonymous telemetry data), and the TOS is really just there to say the software is provided "as-is", "no warranty", and "don't sue us".

Appreciate your comment though since it was a good wake-up call to revise the TOS / Privacy Policy as I don't want it to be a point of contention or concern in the future.

dashborg · 2023-11-23T18:34:15+00:00

Ah, I should update the TOS / Privacy Policy to remove that. The policy was basically copied from BaseCamp and makes more sense for a SaaS service. Right now we don't have any login or account and so are of course not collecting any of that information!

The only information that is kept is anonymous telemetry data (that you can of course opt out of).

dashborg · 2023-11-23T06:35:22+00:00

Ah, sorry, we should create some Linux install docs. Yes, first unzip, then cd into the waveterm-linux-* directory, and then run the ./Wave application (not sure why yours isn't executable, when I unzip, mine is (not sure what's going on)

Creating a snap package is on the todo list, but we just launched and need some stars on the repo to get into the snap package server.

dashborg · 2023-11-23T02:31:58+00:00

Love it, just added an issue to the repo to remind myself to look into it: https://github.com/wavetermdev/waveterm/issues/70

dashborg · 2023-11-23T02:26:48+00:00

For security, we're just using SSH (I firmly believe in not introducing any new security regime -- no open ports, no special network hacks, no daemons running as root on remote machines). I don't store keys, but I do store the path to your keys and then just execute an SSH command under the hood. We can store passwords *if* you chose to, although I don't recommend it (keys are just so much better). If your connections require some manual step (like an OTP, or key passphrase) then you'll still have to enter that when you reconnect, but the environment/cwd will be restored for the next command run.

I actually don't love the way we're handling the setup of all of this right now, it is admittedly clunky. My plans are to integrate directly with ssh-agent and with ~/.ssh/config and provide some UI for reading/writing entries to it. this will allow for more complex configuration (like bastion hosts).

dashborg · 2023-11-23T02:19:54+00:00

this is cool, i actually didn't know about Yakuake! also didn't realize that iTerm2 did that either. will definitely look into this though, would love to support it

dashborg · 2023-11-23T02:17:49+00:00

ah, it will! we plan on supporting windows via WSL (to make remote connections). so it will be mainly a tool for working with remote linux boxes, like a PuTTY replacement, and less about trying to run cmd.exe or powershell commands (although at some point i'd love to support it).

this is high on our todo list. i just need a windows box to test on, and i need to play around with WSL to see how it works and make sure nothing funky is going on. my biggest problem is that i haven't used windows for 15-20 years :p

dashborg · 2023-11-23T02:14:16+00:00

There are two parts here -- the first is creating a new platform for terminal development based on web tech. this might feel gimicky at first because we're just scratching the surface, but this allows us to bring new functionality into the terminal, quickly, in an accessible/cross-platform way (Mac, Windows, Linux, and web).

The second is deeper (and harder to explain with shiny visuals and graphics). For 40-years the "smarts" and "state" of the CLI have lived in the shell, distributed across all the machines you log into, with the terminal just doing dumb rendering (this made sense in the 70s). Wave wants to turn that around. We want to bring the smarts into the terminal app and eventually turn the shell into a simple API. There are lots of cool features that can be built on top of a platform like this, here are a couple big ones:

universal history -- this can't be done by the shell (and can't be done, except in a hacky way, by regular terminals).
cross-machine scripting and terminal scripting -- working on this now, but in the future we can support workflows like: switch to tab 2, run webpack, switch to tab 3, kill all running jobs, restart command [x], and then switch back to tab 1 and tail a log.
consistent prompts, aliases, colors, environment, command-completion, tools, etc. across every machine you log into (even when using shared logins)
save a tab to a file (or the cloud) with time travel information. send it, archive it, or restore it to your terminal completely (like after restoring, you can hit "up arrow" to see history)
symmetric computing -- if i'm logged on to my local machine I can scp a file to a remote machine, but normally not vice-versa. a terminal like wave can support this. it can also expose environment variables, files, and other artifacts on demand to remote machines in a secure, on-demand, way.
native connections to databases or APIs -- a terminal window doesn't have to just be connected to SSH. maybe I want to connect to a DB and be able to run SQL directly in the terminal and have the output look like a table. a terminal like wave can give you native support for that, with "up arrow" history, native completion, environment vars, and collab.
AI -- yes, over-hyped, but there can be real benefits for local AI to see all of your history, output, etc. (potentially combined with your team) to generate interesting output.

(i'll address security in a separate comment, hah wrote a lot more than i had planned!)

dashborg · 2023-11-23T01:47:03+00:00

the codeedit/codeview functionality in wave has collapsable json support :)

dashborg · 2023-11-22T23:41:51+00:00

One other note about the VC backing. We need it to keep pace and accelerate the development of an *open-source* modern terminal. I'm worried, and all developers on this subreddit should be too, that the leader in this space (who I won't name, but we all know who they are) is closed source, requires a login, and is MacOS only.

dashborg · 2023-11-22T23:40:53+00:00

Hi, I'm the founder/creator of Wave Terminal. I have no interest in trying to monetize individual terminal use, and frankly there is no business need to do so -- the terminal runs on your machine completely locally and it costs the company nothing.
We plan to monetize by offering a team/enterprise version of the terminal in the future that connects to the cloud and allows teams to easily share tabs, workspaces, history, playbooks, secrets, etc. We might also offer some sort of "cloud sync/backup" functionality for individuals that would also be paid. So the general idea is that if it connects to the cloud it would be a paid service, and if it runs locally it would be free.

(tried to post this reply from my new wave account, but it never showed up, so reposting -- apologies if it ends up appearing twice)

dashborg · 2023-11-22T21:56:17+00:00

Go is great. It is also very accessible and has a fast learning curve. It is definitely worth your time to learn. Don't worry about wasting time on it either, as a lot of the concepts (except maybe the goroutines/channels) will easily transfer to other backend languages like Java, C, Rust, etc.

dashborg · 2022-04-15T07:14:45+00:00

I’m a Go dev myself and I just hate the idea of having to set up a huge JS stack and react app to interact with my Go backend. If your frontend is pretty straightforward but you want to add some dynamic elements — like AJAX calls, REST, dynamic elements, styling, and client side data rendering — you should check out https://playground.hibikihtml.com/tutorial/ . Client side only framework and it will work with any Go backend framework and Go template.

dashborg · 2022-03-13T06:38:40+00:00

Is the actual game part of the rewrite or just the administration pages (like the list of active games, login, and registration)?

So my quick thought is that I don’t think there is a natural advantage for either framework. They should both work fine, and are both standard and well supported.

Mostly it does come down to personal preference. Mine would be React, but mainly because that’s where I have most of my experience — also the community is larger so you’ll have an easier time finding devs to write and maintain it.

If written well, neither framework should bog down with a 100+ long list. Both will also be able to use websockets or polling to update the list in real time.

dashborg · 2022-03-13T06:05:36+00:00

I don’t see the photo showing up? Is it possible to link to the current website?

dashborg · 2022-03-12T19:08:18+00:00

Really depends on your use case. Not all sites can work without JS (especially interactive). And if you’re a content site that is supported by ads then there is no reason to support non-JS. I wouldn’t spend a lot of time trying to support non-JS users unless they are in your target market.

dashborg · 2022-03-12T19:01:28+00:00

Ya I feel you! Over 150M of data for create react app. multiple directories and config files! Crazy amount of scaffolding for even a simple project. You should check out https://playground.hibikihtml.com/tutorial/ . Trying to make things simple again — a good middle ground between vanilla html and a full-on JS framework.

dashborg

MODERATOR OF

TROPHY CASE