Another thing I don't like about Ruby is how much the community has embraced the Clean Code brand of readability snake oil. It's easy to come by the opinion that any function over 5 lines is a code smell and over 10 lines it's outright bad. I've even heard the view that if-else statements are a code smell and I should always try to replace them with different classes that have the same interface. To be fair, that only happened twice, but that's two more times than I've heard it from users of any other language. I think that the Python community usually strikes a better balance between avoiding excessive function/class length and avoiding excessive indirection.

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

Points: 3

# Comments: 0

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

Points: 1

# Comments: 0

I'm not saying you're definitely wrong, but if you think that LLMs are going to bring qualitative change rather than just another thing to consider, then I'm interested in why.

Interesting, what's your recommended resource for learning more about this?

I think so too; that said, the language could definitely be better. It suffers from a lot of primitive obsession. Instead of structs, you often find either vectors or lists with predefined element positions; instead of map, ordered map, and multimap types, it's just various kinds of lists everywhere. They're not even used consistently: for the same thing, one package may use an alist and another a plist.

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

Points: 286

# Comments: 143

I'm curious about your experiences with these concurrency models - which are easy to get right, and which are endless sources of bugs? I'm particularly interested in use cases where there are lots of long-running connections and correctness matters more than performance: chat servers, MMORPG servers, IoT central systems, etc.

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

Points: 10

# Comments: 3

1) It enables better separation of concerns, Twelve-Factor App style. For example, user-installed programs no longer need to connect to a logging daemon or execute a complex daemonization dance [1]. They can just run like a normal command-line program and dump logs to stderr.

2) It cuts down on integration problems, shell script glue, and the amount of different config syntaxes you have to know. Its architecture is modular with over 100 different binaries, so you can still pick-and-choose components and do privilege separation, but because these components are all coming from the same vendor, you know they're going to work well together.

3) It can do certain things far more reliably because it's willing to use Linux-specific APIs. For example, thanks to cgroups v2, it can supervise a process correctly no matter what kind of weird forking strategy the process is using.

Since this project is intended to be compatible across Unix-like systems, it won't be able to use Linux-specific APIs, so advantage 3 is gone. It looks like it dropped many components of systemd, so advantage 2 is partially gone too. Is this project just about getting some cross-cutting concerns into the init system and having better scheduling of service startup?

[1] https://www.freedesktop.org/software/systemd/man/latest/daem...

For me personally, the biggest improvements that could be made to C aren't about advanced type system stuff. They're things that are technically simple but backwards compatibility makes them difficult in practice. In order of importance:

1) Get rid of null-terminated strings; introduce native slice and buffer types. A slice would be basically struct { T *ptr, size_t count } and a buffer would be struct { T *ptr, size_t count, size_t capacity }, though with dedicated syntax to make them ergonomic - perhaps T ^slice and T @buffer. We'd also want buffer -> slice -> pointer decay, beginof/endof/countof/capacityof operators, and of course good handling of type qualifiers.

2) Get rid of errno in favor of consistent out-of-band error handling that would be used in the standard library and recommended for user code too. That would probably involve using the return value for a status code and writing the actual result via a pointer: int do_stuff(T *result, ...).

3) Get rid of the strict aliasing rule.

4) Get rid of various tiny sources of UB. For example, standardize realloc to be equivalent to free when called with a length of 0.

Metaprogramming-wise, my biggest wish would be for a way to enrich programs and libraries with custom compile-time checks, written in plain procedural code rather than some convoluted meta-language. These checks would be very useful for libraries that accept custom (non-printf) format strings, for example. An opt-in linear type system would be nice too.

Tool-wise, I wish there was something that could tell me definitively whether a particular run of my program executed any UB or not. The simpler types of UB, like null pointer dereferences and integer overflows, can be detected now, but I'd also like to know about any violations of aliasing and pointer provenance rules.

EDIT: This would combine very well with my suggestion from the previous comment: make the cards glow in the card selection stage, make the selectable objectives glow in the objective selection stage, and make the die glow when it should be rolled. That would let you get rid of two microfrustrations at once: the hints that cover the UI and the die that can be clicked but doesn't roll. If you also replaced the modal tutorial popup at the start with a top or side button, that would drop the UI microfrustrations to zero.

Also, I've just noticed that the cards are a bit blurry when zoomed in on hover.

I hope the feedback was helpful!

Same bug here, in Firefox 128.

Also, while we're making suggestions, would it be possible to replace the tutorial balloon boxes with something that's less in the way? I like built-in hints and don't want to turn them off, but sometimes they can be a bit annoying when they cover up parts of the game UI. I would prefer some kind of animated glow behind the parts of the game I'm supposed to click on (cards, bars, or the die) plus a statically positioned explanation box to the side or on the bottom. That would make the hints unobtrusive enough that there would be no need to provide an option to turn them off.