hyperbrainer

Wow, thank you so much for taking the time to do this. I love all of you guys in the rust community.

> Would https://docs.rs/tracing-subscriber/0.3.19/tracing_subscriber... help you?

Indeed. This is brilliant.

Okay this is really funny because I was messing about with generics relating to the Write trait just yesterday, leading to much frustration.

> you find yourself propagating a generic bound up an entire hierarchy of data structures and functions using those structures

And I did exactly that. I did eventually get around to using dyn Write, but that still gave me headaches because of how I cannot use impl Write as a result type in closures, which I need to do if I want to use tracing_subscriber::fmt::with_writer() and pass in these trait objects.

Despite being this close to the solution, I somehow again wound up propagating generics back at least four functions.

I ended up not writing any generic-based stuff and resigned to just manually writing each type's implementation out, but I am going to tinker with this again today. Hopefully, I can use your advice.

Thank you so much for taking the time to write this. Means a lot!

> there was something satisfying about C in the old DOS days, where you could make a pointer to video memory and scribble on it

Exactly.

It's hard to pinpoint the problem, because I love and adore Rust. So, thank you for all the work you have put in -- it's a great language.

I feel like my biggest struggle is simply how hard (tedious?) it is to properly work with generics and some more complex applications of traits. Any time I am working with (especially writing, somehow reading is easier) these, I always take an ungodly amount of time to do anything productive.

I am almost certainly sure this is a skill issue -- I am simply not "Rusting" like I am supposed to. Maybe I overuse generics, maybe I rely on traits too much, maybe I am trying to abstract stuff away too much. But this is one of the reasons I want to also explore other languages in the space, especially ones which make it impossible for me to make this so complex.

Don't get me wrong -- all of this complexity is a joy to work with when I can use my brain. But sometimes, it's just too much effort to do stuff, and it feels like I could be getting away with less. Curiously, I never had a problem with the borrow checker, even though people often complaining about how much it forces them to "stop and think".

Another thing is that C, for some weird reason, always feels "lower level" than Rust, and seeing it gives me some sort of weird satisfaction that Rust does not. Maybe it's just a greener grass syndrome, but wanted to mention it nonetheless.

All this said, I want to just emphasise, that despite this shortcoming (if it even is one), if I were forced to choose a language to spend the rest of my life with, I would not be the least bit sad to only ever use Rust again. I absolutely love it.

Unfortunately, it seems to use a GC for the safety, which makes it unsuitable for a variety of tasks in the systems programming domain. Seems to me like an alternative to Go more than Rust or C or Zig

I think the problem is that some of the more advanced things related to generics or traits are half-baked or maybe somewhat function only in unstable, leading to horribly written code, or code which takes far more complexity to run than it should.

The full language is indeed even further ahead of Rust on the spectrum I am looking at, but this seems like a cool effort. I love proof-based languages and dependent types, so this is an absolute win.

What intrigues me quite a bit relative to the main topic of the HN thread is Low[0]

> Low is not only a language subset, but also a set of F* libraries that model a curated set of C features: the C memory model, stack- and heap-allocated arrays, machine integers, C string literals, and a few system-level functions from the C standard library. Writing in Low, the programmer enjoys the full power of F for proofs and specifications. At compile-time, proofs are erased, leaving only the low-level code to be compiled to C. In short: the code is low-level, but the verification is not.

[0] https://fstarlang.github.io/lowstar/html/Introduction.html#t...

V looks exactly like one of the languages I was talking about. Some controversy about the project, it seems like, but very cool nonetheless. Even if it doesn't actually work like described, the description seems quite interesting.

> But I've had a few issues with the safety aspects of the language. Breaking through the checker isn't that difficult.

What do you mean? Can you "break through the checker" outside of unsafe blocks?

I love Rust, and will continue to use it. But sometimes it feels like "too much". If you have programmed in Rust, you know what I mean. I want to use and experience a language that is to Rust almost like what C is to C++.

This is primarily an educational exercise to see how people find compromises that work for them, and languages in the same space as Rust using alternative strategies.

I don't mind the language having substantially worse "something" as long as it can be a smaller alternative for Rust, for the lack of a better word. Of course, there always needs to be some compromise. I don't mind that. I just have two requirements, and am curious to see how people have tackled that problem.

Not a technical difference, but I think Mercury is somewhat more "commerical" in that it's out of development and can be used in real projects, compared to Curry, which is very much in development.

Which is despite, a decade of attempts, still missing dependent types. Time to embrace Idris.

Or embrace logic + functional programming: Curry. https://curry-language.org/

Austral's specification is one of the most beautiful and well-written pieces of documentation I have ever found. It's section on error handling in Austral[0] cover everything from rationale and alternatives to concrete examples of how exceptions should be handled in conjunction with linear types.

https://austral-lang.org/spec/spec.html#rationale-errors

I was quite impressed with Austral[0], which used Linear Types and avoids the whole Rust-like implementation in favour of a more easily understandable system, albeit slightly more verbose.

[0]https://borretti.me/article/introducing-austral

You are looking for Ada.

Tcl is another language used in the domain; it is rarely used outside of some sectors, but lots of interfaces for embedded systems are written in Tcl, especially in the Electical/Computer/Electronics Engineering sector.

IMO, the implementation of event handling is easy and simple, while being incredibly powerful. It may not fill the same niche as C does, but as a glue/scripting language, it's really good. Furthermore, the Tk library allows easy development of GUIs without much hassle.

Outside of embedded, you can also find it used for automation and testing -- SQLite famously has many millions lines of Tcl code for testing. [0]

[0] https://sqlite.org/testing.html

SDL does have a platform-agnostic render library for basic stuff, and you can integrate Metal into it pretty easily.

Needs (2018)

If only there was an editor which could act as an interpreter for Lisp directly ...

Any sufficiently complicated piece of code contains an ad-hoc implementation of Lisp.

Oh, I didn't see the typo. Thanks!

For some reason the silverbullet link in the website is broken if I copy it or just click it. But typing the exact same thing works.

I know of these. Almost added a disclaimer too -- that was not my point, as I am sure, you understand. Also Ocaml has a GC, unsuitable for many applications common to systems programming.

> Both have the big restriction that the two functions involved are required to have the same signature.

I did not know that! But I am a bit confused, since I don't really program in either language. Where exactly in the documentation could I read more about this? Or see more examples?

The language reference for @call[0] was quite unhelpful for my untrained eye.

[0] https://ziglang.org/documentation/master/#call

I couldn't actually figure out whether this TCO being done "fairly well" was a guarantee or simply like Rust (I am referring to the native support of the language, not what crates allow)

It's interesting especially because it seems like companies today pour tens of millions into "accessibility", but I never see a thing's usability in terms of simple and easy-to-do-what-I-want UX fall in to the same category.

AFAIK Zig is the only somewhat-big and known low-level language with TCO. Obviously, Haskell/Ocaml and the like support and it are decently fast too, but system programming languages they are not.

Actually, you are right.

Any language with decent TCO won't do that. Python is the only big language that I can think of that doesn't do it.

> > A recursive algorithm is a depth first search. Any loop that explores candidates/neighbors without sorting the candidates is a BFS.

BFS is also a recursive search. Even in the case of non-recursive search, the only difference is whether you use a queue or stack.

Apart from that, great article.

This is great!