I like Rust and have an ambition to learn it as well (I've had a few false starts...). One of my issues that I have is that every (slight exaggeration) library that I seem to come across is still at version 0.x.y. Take this library as an example. 0.1.0 was released in 2014 and it still hasn't had a 1.0.0 release, is there an aversion to get to 1.0.0 in the rust community?
Readit Newsliambigelow commented on Bzip2 crate switches from C to 100% Rust trifectatech.org/blog/bzi... · Posted by u/Bogdanp
liambigelow commented on Egui – An immediate mode GUI written in Rust egui.rs/... · Posted by u/josephcsible
Demo pages like this are fun, and technically impressive when compiled to a browser environment. But I suffer from a lack of imagination so these widget demos don't really help me envision what an egui-powered app can do or might look like.
Does anyone have any examples of fun things that use egui?
[https://truncate.town/](https://truncate.town/) is all egui (after the main menu)
liambigelow commented on Rust library for building no-boilerplate CLI apps github.com/JeffrayZhang/t... · Posted by u/PaulHoule
"Ideally CLI flags merged over top of environment variables merged over top of configuration files."
I used to wish for that too but I have changed my mind. I think in real world applications with many options it is preferable to not allow every option to be set in every way.
Environment variables shine for properties that vary per instances which share config files and for system properties (think $GOMAXPROCS).
Secrets should never go in the command line nor the environment.
There is no one size fits all. Arguments, environment and config files have different pros and cons and should be used accordingly.
Yeah I agree, and do the same. Likewise some config gets complex and can only be reasonably set through config. I prefer when I have a system with one base configuration struct where certain fields can be tagged as available on the command line, another subset in the environment, etc.
liambigelow commented on Rust library for building no-boilerplate CLI apps github.com/JeffrayZhang/t... · Posted by u/PaulHoule
Not a library, but I have a template repo [0] I made precisely for this purpose (since I found libraries aren’t as flexible as I needed). See it in use at [1].
Edit: If there’s demand I’d be willing to better document it.
Ah nice, will peep — in the interest of sharing here is my latest "template" that gets copied from project to project: https://github.com/CloudCannon/toolproof/blob/main/toolproof...
liambigelow commented on Rust library for building no-boilerplate CLI apps github.com/JeffrayZhang/t... · Posted by u/PaulHoule
Looks nice! I like the approach.
My holy grail will still be landing on a good multi-layer configuration setup for Rust CLIs. Ideally CLI flags merged over top of environment variables merged over top of configuration files.
Twelf [0] was close in unifying things, but I had some friction. Lately I've been using Schematic [1] to handle the environment + config layers, and then just a manual implementation of Clap arguments layered on top.
liambigelow commented on Tidal Lays Off Staff as Dorsey Pushes for "Startup Mindset" fortune.com/2024/10/30/ja... · Posted by u/fatfox
Why do people use tidal when Apple Music exists?
I prefer Tidal’s UI and album management. Tidal also has a good notification system for new releases, and otherwise gets out of the way. I moved to Tidal from Apple Music, but would move back if I had to over any other options.
Also, Tidal has been working on opening up more of an API which is hopefully a project that doesn’t die with this announcement.
liambigelow commented on Show HN: We built a FOSS documentation CMS with a pretty GUI kalmia.difuse.io/doc/... · Posted by u/arch1e
Using Rust for markdown parsing seems like the epitome of driving a racecar to the grocery store- I’m curious if you have any metrics as to how much build time was reduced with that over using something like Node. I’d guess it’s <10ms.
There can be more of a difference than you might expect. In static site generators, Eleventy is about as fast as you can get in the JavaScript world, and is still 2-3x the time for Hugo in Go [1]. A couple orders of magnitude more than <10ms in this test which is predominantly markdown parsing.
Anecdotally, for large or extra large sites, the build performance gap between even Eleventy and Hugo can be quite large. And the gap from either of those to the newer JavaScript tools like Next.js is enormous.
liambigelow commented on Show HN: Truncate, a word-based strategy game truncate.town/... · Posted by u/liambigelow
Really enjoyable. Disagree with some of the comments here about wanting to be warned if you're about to lose a battle - losing battles can be strategically advantageous to dispose of unwanted letters and free up board space. It's possible to fight back from near defeat - even a total wipeout - and long back-and-forth fights across the board can happen. I definitely don't want to be prevented from sacrificing.
Maybe a mode where you can see a preview of how a move will play out before you commit the move would help.
I do agree with some of the other comments that the letter probabilities seem a little unbalanced, but that could just be the tendency to remember runs of bad luck in the letter draw.
In terms of dictionary feedback: I'd love to see at a glance on the board which words are 'real words' and which are not. Some sort of visual highlighting of the letters that are in a word would be great.
Having the dictionary always available would be great, rather than having to click twice to get into it, then click again to focus the lookup field.
The AI never seems to use swaps. Is that deliberate?
Thanks for the kind words!
Many good notes, we'll look into a lot of that. And yes currently it's deliberate, but I think we can squeeze some AI swaps in!
liambigelow commented on Show HN: Truncate, a word-based strategy game truncate.town/... · Posted by u/liambigelow
I've spent a bunch of time playing this over the last couple of days. Overall I love it and I keep coming back to it.
There's one thing I find really frustrating, though - the dictionary is incredibly idiosyncratic, including stacks of 'words' that normally I wouldn't expect to be accepted while still excluding some that I'd think are way more usual in this kind of game. (I'd guess this is where some of the confusion on 'why did my attack fail' comes from?) I basically have to look up every word every time.
Could we either have the dictionary visible all the time for easier access, or (better option IMO) add a highlight that shows which adjacent letter groups are in the dictionary? Not sure how this would work on mobile without mouseover, though, it might need a separate 'commit' tap after placing and seeing the results.
Good ideas! Thanks for the notes :)
Yes dictionary is a tough thing to nail down perfectly — to start with we're going to highlight existing words on the board that are invalid, but have a similar line of thinking around the "commit" tap after placing, at least behind some learning setting. There'll be a changelog screen for when things like that make it in :)
In general: People usually aren't too concerned about it.