SoraNoTenshi

I believe the Binja folk originate from the CTF folk.

It is of course an exaggeration, but that's what is somewhat annoying to me. But dismissing this point by just saying me "get better" after literally years of using Rust is a bit of a weak point, or am i in the wrong here?

And it's not even that i dislike the language, but this is evangelism to just dismiss the point of my argument with "skill issue". A tool isn't supposed to be difficult, it should help you in whatever you're trying to achieve, not making it more difficult.

It also drives me insane when i dump the problems i have with Rust about this exact issue, that i usually have to restructure my code to satisfy the compilers needs, and they come at me with the "Skill Issue" club...

I honestly don't even know what to respond to that, but it's kind of weird to me to honestly think that you'd need essentially a "PhD" in order to use a tool...

There's also a fundamental difference in Zig and Rust. Ever tried reading std code in Rust? If you have, you would notice one thing really quick: it's borderline unreadable. It's a hornet's nest of Generics over constraint generics calling into indirections.

Of course, this isn't meant to be a defense for the lack of documentation on Zig's side, but in my experience, Zig's code definetly is much easier to read, just because for the fact, that Rust's std code is akin to C++'s stl.

One of the personal grimes i have with Zig is, that `anytype` makes the function contract kind of meaningless, because you can't see what is expected purely on the function definition.

I mean reading through the article it was only considering author's present perception which is a bit too naïve in my opinion.

Out of my head, the benefits of having a `build.zig` that you learn right from the get go is, that you kind of have to dig a bit into the eco-system a bit. Also how the buildsystem works, etc. which then in return makes it muuuuch easier later on if you have a bigger project, to properly utilize the power of the buildsystem.

I can also only consider my perspective here, but I've done quite a bit of Rust now (and work with it for over a year now, full time as well), and i can tell you as much: I would be thrown into icy waters if i need to do anything with a build.rs.

I think that'd require a different Datatype than a Raw pointer. Allocating heap memory is a side-effect that's not really predictable, if you take all the factors into account. However i can see a world where this may be possible because of virtual memory, but i don't know how.

Dependent Types could help, although i am unsure if it helps with raw pointers.

I am not entirely sure what the Author is criticizing? It looks like a comparison to Odin rather than any critic.

And also: I don't quite understand most of the Arguments. UB is often a way to ensure that certain optimizations can be made (if i remember correctly.) Also there just are certain facts that when you have full control over memory, some things can just not be predictable. (Accessing invalid pointers as an example)

Verbosity is mostly subjective. Most of Author's concerns were path lengths, which can easily be "fixed" by redefining the path into a constant. `const debug = std.debug;` I also think the Argument towards "it looks like java's println" full on is a bad argument. Especially because `std.debug.print` does something completely different.

The whole "critic" towards `build.zig` also seems like it's done with without good faith. Yes it's daunting at first. Yes it requires to learn about the build system in the beginning. Sure those are all very real Arguments, author just doesn't want to mention the benefits of it.

Then half of the arguments about comptime i also don't quite understand. It seems like it is building up the main point of the argument, but then you just get hit by a statement. So no explanation no nothing. Talking about lazy evaluation and a little bit of how SoA makes things worse (which i have no clue how that matters in this context) and then saying it's violation "no hidden control flow" is not really getting the point i feel like.

This looks interesting to me, as i am currently using GlazeWM, but a lack of scriptiness makes it a bit of a hassle for me to use, it also sometimes is glitchy especially with a specific set of applications i use.

I will make sure to give Jwno a try, as i have had Janet on my radar for quite some time already. Maybe it will solve some of my concerns i have with GlazeWM. :)

Very nice project, i think the way you navigate is implemented spot on!

Although i have some questions / concerns: - "Command mode" (`:`) seems a bit more different compared to Helix / Kakoune and maybe even VIM. I would have also expected to be able to change the theme like so.

- I couldn't find (after just a bit of skimming around the docs) how to adjust the sizes of e.g. the file-tree. Or well, even change to a different window. I like the concept of having multiple windows within the browser, but couldn't really figure it out.

Also, layouts may be a neat idea to implement, so that e.g. the file browser will always spawn on the exact same location of a defined layout (may as well be pre-defined) - Theme browsing is a little bit slow i feel like, not big of a deal, just something i noticed.

- The docs may also need a way to change from selection based movement (e.g. via Token / ts node) back to character based.

- The gui may need some improvements, maybe it's just subjective perception, but having a small window with all the options there is good, but i couldn't intuitively tell whether or not those were all the options (e.g. in <SPC> mode). Also i am fairly certain there were more options.

- A builtin tutor is also a neat idea, considering that your editor looks very young, i am sure you thought of that, but it's a really easy way to get new users comfortable with using it.

Anyway, very neat project! I will keep an eye out and eventually try and daily it, at least for a week. The structured editing you implemented is REALLY GREAT, like better than i could have done it (or even thought about).

I'm in my mid 20s, but already have ~4 years of professional experience.

Basically for me this "day of productivity" can extend to up to 3 days, but yes the cycle in general is always to some degree: Productive -> Lazy -> Something inbetween -> Productive -> ...

Very surprising to me was that there is a semantic difference in <i> and <em> (the same is also the case with <b> and <strong>) apparently, also PDA readers for e.g., blind people are also aware of this semantic difference.

What was also surprising is that there is a Slider as well as Color picker element.

Fair enough i am not much of a web person myself, but i know that a lot of webpages have their own custom JavaScript implementation of those elements (if needed).

  Location: EU, Germany, Munich

  Remote: Yes, only!

  Willing to relocate: Not for the next ~2 years

  Technologies: Back-End | Rust, Go, C, C++, Zig, Linux / Windows / macOS, SQLite, generally interested in almost all Languages / Technologies and eager to learn new things.

  Résumé/CV: Request via Mail

  Email: [email protected]

Hello, I am a mid-level (~4 years of professional Experience) Developer, with mostly professional experience in Lower-level Programming (currently, C++) and Back-end Development (Go, C++, C# and a bit of vanilla Javascript). I code in my spare time, love to do that, and have recently (Oct '22) started to more regularly contribute to open-source projects, in which i have also learned Rust quite a bit better and enjoy my journey so far.

I would say i have a strong system-programmer mindset, however, i believe that my area of interest for a Full-Time job would be more in the area of backend development.

I also have a very deep interest for Cybersecurity topics, Games and even good engineering practices.

Interesting take.

For me it was quite the opposite, regular Linux distributions annoyed me because after having them set up, some stupid mistake (either from my side, or from upstream, unsure about this) caused my whole bootloader to break, rendering my system unrecoverable (maybe not for every, but for me it was/is).

When i learned about NixOS, allowing you to essentially set up your whole system declaratively, it was so compelling to me, that i just went with it. Yea i don't really like / know the language very well, but it's a lot better of an experience than any prior Linux experience i made.

Writing stuff (usually visually) down with a Pen + Paper, also helps me a lot, especially when i try to understand a problem i have. And afterwards i try to explain the problem to myself.

Helix will get plugin support sometime, it's basically a matter of when not if. Also; the scripting languages seems to become an S-Expression like lisp dialect.