TwentyPosts

They're 'laughably simple' on a conceptual level. Adding them to the language in retrospect might genuinely be a bad idea at this point.

The thing which I am personally salty about is that they weren't there to begin with, and that the language wasn't built with them in mind.

The claim wasn't that they are unaware, the claim was that it doesn't seem to show in the design of Go.

I think Go is a perfectly fine language, and I respect the goal to stay clear of complexity, but when looking at any particular Go feature, then it's easier to explain the decision with "They are used to thinking in terms of C-idioms." than with any particular brilliance or awareness of PL-theory.

When I did research on this topic ages ago I read both of these links, and I'm very familiar with the arguments.

I also vehemently disagree with them, and I think that the way code is factually written in practice is on my side: People who propose sum types commonly refer to the Option<T> or Result<S,E> types in Rust. These are types which are almost exclusively used as return types.

Interface types are the opposite. They're used as input types, and almost never to distinguish between a concrete, finite list of alternatives. They are used to describe a contract, to ensure that an input type fulfills a minimal set of requirements, while keeping the API open enough that other people can define their own instances.

The fact that Go in fact does not use interface types for its error handling is a pretty good argument in favor of that, I'd say.

The thing is, at this point it doesn't matter, sadly. Adding sum-types to the language now would be unsatisfying. You would really need proper integration as the primary tool for error handling in the standard library (and the ecosystem), and that's unlikely to happen, even less likely than a Go 2.0.

EDIT: Just to make it clear, I think not wanting to add sum types to the language is understandable at this point. The real shame is that they were not in the language from the beginning.

Ehhh, I see absolutely no evidence that the Go developers were particularly aware of theory. It really feels more like they just were used to thinking in terms of C, and built a language which is kind of like C.

Go also has some really weird stuff in it, such as named return values.

Frankly, the lack of sum types hurts the most. The language would just be a lot better with a unifying Result type in the library. And don't give me any of that "oh, they tried to keep the language simple!" stuff.

Intuitively, sum types are laughably simple. Everyone understands "It's one of these possible values, so you need to check which one it is and then handle that situation." They are more simple than enums on a conceptual level! Sum types are just not how C-programmers think about the world.

Wait what? Do you have an example or more information on this?

They are, at least in my opinion (degree in mathematics). This might be a terminology issue. Not all fields use exactly the same terminology.

Was anyone else unsatisfied with this article? Yeah sure, queueing theory is cool and fun and interesting but this article is really just a short list of used abbreviations and falls woefully short of genuinely interesting content.

You'll get more out of reading the Wikipedia article on queueing theory and on M/M/1 queues.

Saying that Rust "has exceptions" is dishonest. What matters isn't whether they technically exist, but if and how they're used.

In idiomatically written Rust you will never obtain an exception/panic (unless there is a bug), and exceptions are not used for control flow. This is not the case in Java or C++ or many other languages.

I don't know, works on my machine. Basically any game I play works immediately out of the box. Last bigger issues I remember is Elden Ring crashing when opening sometimes.

Otherwise it all just works immediately, no issues at all.

You can't..."reason about your code" in Rust? Look, maybe there's a reasonable take in there somewhere, but the way you put it just makes it sound like gibberish.

It sounds like you're just hoping for either a dynamically typed language (eg. Python) or for a language which is fully type-inferred (eg. Haskell). Which way is it?

How 'high-level' are you hoping for here? Haskell? Rust has very high abstractions, but I guess the fundamentals are based around giving you control over low level stuff, which seems like a good balance to me. I'm not sure what specifically you'd hope to do which you can't do in Rust.

> which I'm pretty sure beats both Julia and Mojo

Sometimes "showing the code" is not enough. Show me the benchmark.

>(and the discussion on whether they are actually sound is still open!) Do you have a reference for this? Frankly, maybe I shouldn't ask since I still don't even understand why stackless coroutines are necessarily self-referential, but I am quite curious!

The iPhone works because it's a device you'll look at all the time while operating its touchscreen.

The car touchscreen doesn't work since you need to operate buttons without directly looking at them, purely by tactile feel.

This is not a problem touchscreens we're able to fix so far, and I don't think this will change any time soon since there's just not enough ways for a touchscreen to provide this level of tactile feedback.

std::variant comes pretty close, no?

Let's not forget "Zero features."

(Speaking with love as an i3/Sway person.)

...but why? It seems like a great, simple concept, and not one that seems very expensive to maintain. What's the reasoning here? Like, what sort of returns did they expect here, and why weren't they met?

Can someone tell me roughly at which point a tool like OpenTelemetry becomes interesting? It seems complicated, at which point should you bother with it instead of just handrolling simple stuff and eyeballing it?

Remind me, how is this a good thing again? Especially considering that (if you write modern C++) the compiler should optimize away bound checks most of the time (and in all critical places) either way.

Eh. The existence of Rust (and Zig, to a lesser extent) prove that you can, in fact, have both: Highest performance and safe, properly error checked code without any sort of UB.

UB is used for performance optimizations, yes, but all of these difficult to diagnose UB issues and bugs happen because C++ makes it laughably easy to write incorrect code, and (as shown by Rust) this is by no means a requirement for fast code.

I feel this, sort of. I taught myself how to code by writing a Python bot (among other things), and eventually needed some sort of database handling to make things work. I decided on teaching myself basic SQLite, and just did it raw with `sqlite3`.

Currently 50% of my anxiety when it comes to my bot is related to database matters. There's no type checking so I gotta be careful when writing them, and stuff might blow up weirdly at runtime. Refactoring tables is also a major pain, or at least was until I (sort of) figured out a 'routine' of how to do it.

It's doable, and I assume that teaching myself some basic SQL and using it in production was a great learning experience, but once I'd reached the point where I was inventing database migration tooling from first principles and considering how to implement that, I realized that I probably just want to look at SQLAlchemy again.

If you're not a Vim person yet and not super invested in learning Vim keybinds specifically, may I recommend Helix?

Helix has much better default keybinds, it has a lot of stuff built into it which would require extensions in Vim, and it has a much smoother learning curve (partially due to better keybinds, and partially due to the fact that it will show you which options exist when you eg. press `g`).

As an example: Moving to the start or end of a line is just `gh` and `gl`, which makes a lot more sense than Vim's keybinds. It's still going to take a while to get used to modal editing, but if you don't care about learning vim specifically, then I think that it's an improvement in every single regard.

My personal favorite feature is the multi-cursor editing, especially when coupled with the `s` key.

Ah, that Linux user feeling. Feels like a lot of people in the scene use Windows, which still surprises me considering how tech-y it all is.

Meanwhile, I am still trying to figure out how to really get started with making my first demos. I can write a basic shader with ShaderToy, I can write a raymarching algorithm and do a few cute tricks with it...and now what? How do I turn this into a "proper" demo?

Even just guidelines on the entire compilation step would be appreciated, or knowledge on how some fairly standard examples of demos were compiled, and which tools were used.

Minor differences in syntax are not what makes programming (in general, and when it comes to learning a new language) hard.

As an aside, I really like that I can grep source files for a keyword such as `fn ` and get a good idea of how many functions I am defining, and where they are. This gets especially powerful with multi-cursor editing.

When it comes to the overhead issues of unique_ptr, I always think of this video here:

https://youtu.be/rHIkrotSwcc?t=1192

At 26:50 he gets into how this relates to ABI, and how 'fixing' some of this would require a pretty severe ABI change, as well as destructive move semantics, which would require a severe change to how C++ works.

I frankly don't understand C++ well enough to fully judge about all of this, but everything he says seems entirely solid, and showcases how unique_ptr is in fact not zero-cost, and can in fact be a significant performance trade-off when you really need that extra bit of performance.

> Rust occasionally forces my hand considerably harder (e.g. RC<RefCell<..>> vs std::shared_ptr<>)) in the direction of performance compromise. How so? Is RC<RefCell<T>> more expensive than std::shared_ptr<T>?

I can't say I ever understood how and why async became such a big feature for Rust. I feel like I might understand someday (when I have more experience working with async code) but for now it kind of feels like adding it to the language was a massive, severe change which severely shaped the development and future of the language for years (async traits are still a work in progress!) and I just don't understand whether async was truly the right approach here, or the one feature to prioritize above all else.

As far as I know the community is (was?) still a bit divided on async, mainly because it's rough around the edges, and makes for bad compiler errors.

I wouldn't be surprised if 15+ years later people will think of async as "Probably great for its time, but there are better concurrency paradigms which we should shift to." similar to the shift from inheritance to composition.

To be fair, several years ago Jordan Peterson seemed quite genuine and earnest about wanting to do good in the world...and then his Benzos coma happened, and he was out cold for several months in Russia or something bizarre, an it's very, very obvious that he has never recovered from that.

Like, we're talking some amount of genuine brain damage damage which he's just stuck with now.

Twitter was also just not a good place for him at all. Some people just get sucked into that sort of stuff, even though it's terrible for their public image, and even though there is so much more they could be doing. Anyone remember how people made fun of eg. Richard Dawkins and Neil deGrasse Tyson for being obnoxiously atheistic on Twitter? Yeah, it's a bit like that.

Oh hi Zeno. Don't get me wrong, I love your game a lot, and have played it a lot. I also agree that a lot of very popular games have some pretty severe flaws, though they're often of a different nature.

Anyway, when it comes to Hyperrogue's flaws: 1. The menu is incredibly weird and difficult to navigate. I know a few people who never even knew that certain options existed, since they were hidden a few menu options in. I sometimes have to search for stuff if I didn't start the game in a while.

2. Sometimes there are areas which are rather monotonous and easy, and where you'll be tempted to just 'race' through the area by using scrolling as your main movement method. This works great, until it doesn't, because RNG decides to spawn two enemies in the worst possible locations and you're suddenly locked into a game over. Misclicks can also result in an instant game over, and they happen now and then. In theory it'd be possible to just take things slowly all the time, but this can quickly get really boring when covering large distances. The princess quest is a good example: Very cool idea, but the actual quest gets very tedious. Because of the nature of the area you have to play slowly, but it can be a long, long distance until you actually reach the princess.

tl;dr: Dying with 100+ treasures in Hyperrogue is frustrating since it can happen out of nowhere, and avoiding it would force you to play incredibly carefully and slowly, and/or to avoid some of the more interesting/dangerous lands. If you die you have to start over from scratch, but the game imo doesn't really benefit much from that, and it just forces you to redo the early areas of the game, which isn't that compelling, since the gameplay in these areas is always going to be the same.

Ah, Hyperbolica. I just wish it had more going for it. It feels a lot like the sort of cute educational tech-demo game which you'd show school children/teenagers if you (for whatever reason) wanted to teach them about hyperbolic geometry.

Don't get me wrong, I'm glad that it exists and hope that it inspires some more hyperbolic games (and makes it easier for other people to get started), but game-wise it's incredibly thin, and doesn't have much (if anything) going for it apart from some hyperbolic geometry (which makes some things slightly weird or quirky).

Hyperrogue is much more of a game. It's arguably not a great game (it has a bunch of oddities, and I'd argue some pretty severe flaws), but it does much, much more with the concept, and some of the worlds are genuinely quite compelling.