Hacker News Reader

I can not wait to never have to type interface{} again.

kbdon MonoLisa – A font designed for developers

Agree, I bought some merch from the author as thanks :)

kbdon MonoLisa – A font designed for developers

<opinion>They are not helpful and only serve to obscure...</opinion>

Personally -- after originally thinking like you -- I really enjoy ligatures in my code. I disable them for my terminal though.

The same font can work both with and without ligatures, so it's not a negative if a font supports them. You can choose whether to enable them.

kbdon MonoLisa – A font designed for developers

  $ brew tap-info "homebrew/cask-fonts" --json | jq -r '.[].cask_tokens[]' | rg victor
  homebrew/cask-fonts/font-victor-mono-nerd-font
  homebrew/cask-fonts/font-victor-mono

kbdon MonoLisa – A font designed for developers

Highly recommend Fantasque Sans Mono for a realistic take on the "comic-style" coding font - https://github.com/belluzj/fantasque-sans

kbdon MonoLisa – A font designed for developers

Unfortunately not available to compare on https://www.programmingfonts.org/

While I'm here: Victor Mono has been my programming font of choice for a while now: https://rubjo.github.io/victor-mono/

Oh, look at that, the Victor Mono homepage has a font comparison slider that allows you to compare it to MonoLisa! MonoLisa advertises that it's wider than other monospace fonts, and you can really see that in the comparison. One of the things I appreciate about Victor Mono is that it is narrower than many other monospace fonts (while still being very readable), allowing you to fit more code side-by-side.

kbdon Quitting Dgraph Labs

Building a database is such a hard undertaking. I have to give a shoutout to RethinkDB, which also had cool tech and also failed commercially. And then if you have success as open core, AWS will just fork and offer a hosted version of your software. Good luck continuing Dgraph as open source.

kbdon I’m porting the TypeScript type checker tsc to Go

I'm super bullish on Zig, but it's a bit early to bank on for production things as the language is still changing/being developed.

To give another example of where this came up: they were discussing using Zig for the Ruby JIT, but despite really liking Zig the team decided to go with Rust because of its maturity: https://bugs.ruby-lang.org/issues/18481#note-21

kbdon Typed Config Languages

Yeah that's why I was asking about Cue's eventual goals with libraries like Serde. I assume eventually they'd like to be able to auto-generate type definitions for a target language, but I don't know.

> Cue does not due this, it parses in a "dynamically typed" manor, then uses the type system to evaluate the turing complete (or close to it) expression language.

As I understand it Cue would help in two ways currently. 1. It would be able to type-check existing yaml files to catch things like the "no" case. 2. if you write your config in Cue, it would output properly-typed yaml to avoid things like "no".

kbdon Typed Config Languages

As has come up in this thread already, any discussion of typed config languages nowadays that doesn't mention Cue (https://cuelang.org/) seems incomplete. They really seem to be tackling the problem in a thorough way. I hope it catches on.

For anyone who knows more about Cue: right now you can go from Cue<->yaml (in fact, their docs on yaml also use the "no" case as an example: https://cuelang.org/docs/integrations/yaml/) to integrate with existing systems, but I suppose eventually the goal would be to have direct support in libraries like Serde?

kbdon The time might come when we add some JSON specific command line options

Happy to hear about xh, thanks for mentioning it. I recently ran into a problem where HTTPie didn't support HTTP/2, so I had to fall back to curl. The ticket for HTTP/2 in HTTPie is still open https://github.com/httpie/httpie/issues/692

Happy to see that xh supports HTTP/2 out of the box.

kbdon The time might come when we add some JSON specific command line options

The page actually says that jo was an inspiration for the syntax supported.

kbdon Kosovo pulls plug on energy-guzzling Bitcoin miners

This reads like it was written by a bot… except for spelling errors. I can’t even tell what it’s supposed to mean.

kbdon Cog resurgence

I’m disappointed by the HN crowd in this thread. Almost nothing brought up as a “similar tool” to Cog actually does what Cog does. Except ‘ot’ who gets it because they actually implemented something similar. I guess this is evidence of Cog’s uniqueness.

kbdon Cog resurgence

That doesn’t seem similar to Cog, in that it doesn’t maintain the templating code in the output.

kbdon Cog resurgence

You haven’t taken the time to understand what Cog does. It’s not equivalent to a tempting engine like Jinja or PHP… or f-strings.

kbdon IPython 8.0

I’ve been using ptpython for a while because of its autocompletions. Really excited for that to come to ipython, but from a quick comparison ptpython’s still seems a bit better. You get automatic dropdowns where you have to hit tab in ipython (though it does seem faster than it used to be), and ptpython favors autocompleting arguments in the function signature.

IPython is more robust in various ways than ptpython so I’d prefer to switch back but maybe it still needs a bit of improvement. Open to suggestions if there is configuration I’m missing.

Seems like a great release though with tons of code cleanup.

kbdon Zig 0.9.0

Zig is full of good ideas and seems to be a truly serious attempt, by very talented developers, at improving the “C level” of the stack. I put my money where my mouth is and have a recurring donation to the Zig Software Foundation every month. Lots of people are excited about it. Dunno why you thought it was “ready for production” at a 0.x version though. They’re actively working on the self-hosted compiler and there are breaking changes every release still fyi.

kbdon Why Rust Is the Future

This is indeed a superficial article:

> Rust vs Python: advantages

> Rust is well-designed. Rust allows for putting statements in a lambda and everything is an expression, so it’s easier to compose particular parts of the language. Python lacks it. Rust doesn’t have classes so the object orientation is not as evolved as it is in Python. Python also comes across with the necessity of writing more tests, production outages, or runtime crashes. Rust makes it less expensive to identify and fix possible bugs.

kbdon Go Replaces Interface{} with 'Any'

> and if I want to know where an error come from, I need to wrap it in an errors.New() because no exceptions = no stacktrace

Zig manages to provide traces with very little overhead:

https://ziglang.org/documentation/master/#Error-Return-Trace...

I am baffled as to why error handling in Go remains so impoverished.

kbdon Go Replaces Interface{} with 'Any'

> because eventually you have to do...

Emphasis on eventually instead of at every single function call.

kbdon Go Replaces Interface{} with 'Any'

This is fantastic. It'll make Go feel much less weird. eg from the diff:

  []interface{}{1, 2.0, "hi"} -> []any{1, 2.0, "hi"}

Now that Go is going to have generics, all we need is sugar syntax for early return on error -- like more modern languages such as Rust and Zig have -- and Go may finally be pleasant to program in!

kbdon Hammerspoon – Lua-based powerful tool automation of macOS

Don't miss https://github.com/dandavison/delta. I use gui diff tools much less nowadays because I can get such great diffs in the terminal.

kbdon Hammerspoon – Lua-based powerful tool automation of macOS

Awesome, you made my day better knowing that it helped someone. Thanks for your comment!

FWIW the rest of my (Mac-based) system config is all open source (both the files I linked are in the same repo) so feel free to steal anything else.

kbdon Hammerspoon – Lua-based powerful tool automation of macOS

If anyone cares, here's my config: https://github.com/kbd/setup/blob/master/HOME/.hammerspoon/i...

It shows off a tiny bit of what you can do with Hammerspoon:

  - window and app management
    - keyboard shortcuts for common apps (eg. hyper+T for text editor, hyper+B for browser, hyper+S for shell)
    - if you can code a tiny bit of Lua there's no need for apps like Spectacle, Rectangle, Moom, etc. because it's easy to position apps wherever you want. eg. hyper+L arranges my browser+editor+terminal in a standard layout, and I have other shortcuts to set apps to halves or thirds of the screen, or to another monitor.
  - fuzzy-find popups (like Alfred/fzf) are built-in. I use it to choose audio input/output.
  - a replacement for Caffeine (menubar icon to keep computer from going to sleep)

I have my "hyper" key bound to caps lock using Karabiner Elements (but it still works as a normal caps lock if you hold it for half a second). Here's that config: https://github.com/kbd/setup/blob/master/HOME/.config/karabi...

kbdon Hammerspoon – Lua-based powerful tool automation of macOS

The language used for this is incidental. The important part is all the OS interfaces exposed. If you know Python, you'll feel comfortable in Lua quickly.

kbdon The fish shell is amazing

Comparing the "plugin hunt" between vim and zsh is a bit much. I use three for Zsh, just syntax highlighting, autosuggestions, and fzf-tab. I don't use a Zsh plugin manager.

kbdon The fish shell is amazing

I'll put it this way: Nu shell seems perfectly supportive of my philosophy that a shell is basically a REPL for a computer, and they're taking the ergonomics of an interactive REPL along with the programming language that powers that REPL seriously.

The thing is, there's currently NOTHING GOOD for "shell scripting". Shell sucks (yes it does), so for anything more than very short things I'd rather write Python. But Python sucks for shell-like things, parallelization, it has slow startup, and you also can't do things like put environment variables into your session or change the working directory, so you often wind up writing shims (eg. Broot's br alias - https://dystroy.org/broot/install-br/).

Yes I've looked at Xonsh but maybe the additional syntax is offputting to me. Like, I wouldn't use it as a shell over Zsh (how's Xonsh's fzf support? I don't know, but I know everything's going to support Zsh), and I dunno if I want to use its syntax extensions over just Python. Though It's always on my list of things to re-explore, and maybe it'll click one day. But it being based in Python makes it feel slow (I wrote my prompt in Zig to get it to be fast...)

This is relevant to mention: I wrote a small Python library (https://github.com/kbd/aush) that's basically a DSL for subprocesses, so it tries to make it more convenient to do shell-like things. I find it preferable to shell or Python alone most of the time. Here's an example of its use in my script that creates a new Python project: https://github.com/kbd/setup/blob/master/HOME/bin/create-pyt...

I haven't figured out a convenient way to implement shell piping well with Python's pipe operator, or pass through interactive output directly (so things that "update" the display, like poetry and npm don't behave the same as they do interactively) so it's still .9 status, but it works really well for what it is, and you can always write "regular Python" along with it.

Anyway, Nu seems to be an attempt to put a "real" programming language REPL in my shell, from people who have serious language experience, so I'm hopeful it'll be great.

kbdon The fish shell is amazing

That's a cool argument for Fish for beginners. When you spend thousands of hours in a shell that doesn't matter as much. I don't see any benefit for someone who has Zsh set up well, but yes you do have to google once how to configure auto-completion and so on.

kbdon The fish shell is amazing

> what do you like about Nu shell specifically?

A whole bunch of things:

1. abandonment of POSIX shell syntax. We can do better. I'm happy with Zsh being POSIX-compatible, and that will always be there.

2. a focus on structured data. Nu basically has hierarchical dataframes built-in, along with lots of facilities for their manipulation. There have been a few other attempts at this but the benefits are obvious. Rather than figuring out how to `awk` your way through whatever text output a command generates, command output in Nu is structured and everything can be handled in orthogonal ways.

3. modern conveniences built-in, like syntax highlighting, and AFAIK they want to include features like "do something when you cd into a directory" that we currently need more tools for (i.e. direnv, which I highly recommend!)

4. serious technology. The people behind it are experts and JT has been showing off (https://youtu.be/3o8b_QcrFHc) the engine that enables trivially parallelizable loops. No more need for `xargs`.

5. I hesitate to mention "made in Rust" as a feature, but using a modern language for core infrastructure does matter.