TwentyPosts

`async` is neither multi-threaded nor single-threaded by default. It all depends on the underlying runtime.

Rust's Tokio runtime, for example, is multi-threaded by default and makes progress on several tasks at the same time by using multiple threads.

> Threads are far more heavy than async

This sounds like an issue with the implementation of threads and scheduling in common operating systems, and I don't see how replicating all that functionality inside of each sufficiently large programming language is remotely taken seriously.

But also, you didn't respond to what I even said. You claimed that async is 'beautiful and natural'. I disagreed. You...fell back to a performance claim that's uncontroversially true, but irrelevant to what I said.

Is it really though? All I personally care for when it comes to "doing multiple things at the same time" is frankly Rust's scoped threads API: Create N threads, have them perform some computations, then join them at the end of the scope.

How is this not more natural than creating various state machines and passing around all sorts of weird highly abstract Future-objects?

No? How does that even follow? That a standard should codify common expectations insofar possible (without breaking rigor) is irrelevant to whether you "should" only use standardized languages or not.

>Pixel camera was underwhelming

Are we looking at the same phone? Everyone I know loved the camera and I could've sworn it came out on top in that one phone camera elo ranking

Seeing that the last time I tried to use Zig–completely inexperienced, trying to do completely basic stuff–I hit a compiler bug within two hours, I'd say that "not ready" is about right.

To be fair, the latest Github version had the bug already fixed, but it's still a sign the language is basically still in an alpha stage.

Please, anything but that.

I find it hard not to view stuff like this as a "if Rust gets to be in the kernel, then so should C++!".

Do you have any source for this? This would be quite shocking for me, if true.

Granted, it's been long enough I don't even quite remember the exact issues I had, so take it with a grain of salt. It was definitely primarily weird edge cases, and might've been related to plugin use.

This is one area where NeoVim afaik comes out on top: Vimscript isn't fast, and NeoVim allows Lua plugins via the embedded LuaJit, and those should be significantly faster.

At the same time, NeoVim lacks many, many of Helix' features unless you use plugins. That's fine, of course, plugins and customization are part of what makes NeoVim so great.

Anyway, can you name a few NeoVim features you miss in Helix? I still use NeoVim now and then, so I'd be happy to learn more, even if it's something small.

Even the suggestion that vim is fast is funny to me.

Vim feels sluggish compared to NeoVim.

NeoVim feels sluggish compared to Helix.

Damn, I wish I had known about this earlier.

I guess my hope was that the program would just terminate immediately the instant it tries to throw an exception while -fno-exceptions is set, thus ideally preventing any further action from the program.

Well, my hope was that we'd have a guarantee that the program is in fact just going to terminate, and the process is going to die.

That's probably not great and might leave data in a bad shape, but it seems better than "undefined behavior" aka no guarantees whatsoever, no?

Could you elaborate on that? I'd love to see an example of this. Are you saying that even relatively simple code (using eg. std::vector) could easily cause UB if -fno-exceptions is enabled?

Were these blind tests?

It's laughably easy to grab a temporary e-mail and set up a throwaway account in just a few minutes. I did it for Twitter just a few weeks ago, even.

Surely someone on HN is capable of gritting their teeth here, and understands that Eric doesn't want to have to set-up a whole account and e-mail verification system.

"coproduct type"

Convenience instead of historical baggage, maybe?

Bard is honestly fine, I think? It wasn't particularly impressive when they first rolled it out, that probably had a significant impact on peoples' perception.

Still not sure what the "killer feature" here is. Is there even one? Or is it just "something like vs code but in Rust and faster and slicker"?

I'd give it a try, but I am very happy using Helix, which is pretty novel in its own right.

Clearly they should not have passed linear algebra without this understanding, and you're free to fail then if they didn't personally manage to correct for it by the end of the term.

...There's sexual torture content in Blindsight? Or in his short stories? Having read several of them, I really don't remember anything like that. Can you note some examples?

To flip the question on its head, why bother with C++ when you can use Rust?

Fwiw I don't remember seeing that many posts for Cosmic DE here. In fact, it's the first time it really stands out to me. Maybe I forget, could definitely be the case.

Either way, looks like a cool project? I don't quite get the pitch yet, but sure, looks cool

Absolutely powerful move.

How did this play out after that for you? Or him, for that matter, if you know.

>not all functions always need their error checked - as an obvious example, fmt.Println.

I agree, but a lot of other languages handle this much better. In Rust (predictably!) you receive a Result type, and if you don't want to check the error you either .unwrap() it or apply the ? operator to pass it up.

I feel like making "let's not check this error" explicit rather than implicit would be an improvement. Currently in Go it's impossible to tell whether someone forgot to check an error, or if they omitted the check intentionally.

As an aside: I feel like if you are ever in a situation in which fmt.Println returns an error, then whatever situation you are in is already far, far beyond saving. Maybe fmt.Println should just panic on an error, that seems better than output silently being dropped!

Do you have any evidence for this? Seems like a pretty severe accusation.

> Things like dynamically updated graphs are nearly impossible to write in Rust Just curious, have you tried to handroll these, or have you used libraries? (eg. petgraph, though I don't know if it'd suit your usecases.)

I'm a Rust connoisseur, but I'd agree with 'nearly impossible to write', which is why I'd (first of all) try to grab a library, assuming I'm doing anything complicated with graphs. If it's very simple and specific, I'd try to go through the list of possible graph representations (eg. adjacency lists), and pick a suitable one, but never store nodes directly, rather store indices (while the nodes are stored in some sort of vector).

Fwiw, I didn't mean to imply that they don't know any language theory, just that the language doesn't seem to reflect it. I don't think this itself should be a controversial statement, by the way, Go aims to be a simple language, and the last thing it needs is monads.

Frankly, I'm just the type of person who doesn't understand why it is possible to silently drop error values in Go (even accidentally), see

  f, err := os.Open("foo.txt")
  g, err := os.Open("bar.txt")

  if err != nil {
      return
  }

while the language is simultaneously very strict about eg. unused imports.

It seems like a pretty severe flaw for a language that takes pride in its explicit error handling, and a deep dive into why this flaw was acceptable to the creators would be really interesting.

For now though, instead of sum types we ended up with features such as named returns (???). I imagine some of the complexity here was about not wanting to introduce an explicit tuple-type, since a Result<S, E>-type doesn't compose with multiple returns. (I feel like there should be some workaround here. Maybe anonymous structs + some sort of struct/tuple unpacking, but I could see it getting gnarly.)

> I'm not entirely sure what you mean when you say that Go doesn't use interface types for its error handling, since the language-defined error type is in fact an interface type.

What I meant is that this specific usecase of sum-types (ie. error-unwrapping) is not something that interfaces in Go are used for. Error-handling in Go is done via multiple return values. This goes against the common claim that "sum types and interfaces are too similar/have the same uses", and should count for something, considering that explicit error handling is a big component of Go.