It's an amazing piece of marketing to corner anyone who dislikes a certain hassle as being mentally deficient - that's what "skill issue" means in this context.

> that's what "skill issue" means in this context.

“Skill issue” definitely does not means “mentally deficient”. It comes from the videogames world, where it is used to disparage the lack of training/natural ability of other players; frequently accompanied by “get good”, i.e. continue training & grinding to up your skill.

Do I have to put the pieces together for you? What is the relevant skill in programming? Problem solving. It's not aim or timing or hand-eye coordination lmao.

Not sure I get your point. One can definitely "get good" at problem solving. Isn't that the whole purpose of Leetcode and whatnot?

I struggled with Rust at first but now it feels quite natural, and is the language I use at work and for my open-source work.

I was not "mentally deficient" when I struggled with Rust (at least that I know of :v), while you could say I had a skill issue with the language

Not saying that Rust is necessarily easy to pick up, but hundreds of thousands of people use Rust without a PhD in any subject.

Try and appreciate the humor in what you're replying to without fully discounting the point of it.

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.

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 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.

> 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.

He just pointed out to us language skimmers that it's a potential chicken egg problem, which we may not have considered. Perfect for this kind of article. Whereas pointing out its merits would just be recreating part of ziglang.org

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.

Well theoretically if you compiled the whole system with Zig or Rust, you could eliminate that undefined behavior of invalid pointers right?

You'd need an OS that supports it, but it seems viable that the OS using allocators could know what happens at any given pointer.

To do it statically though, and with enough detail, I suppose it would take something like Idris with dependent types, and I'd imagine at that point it would be a pretty tough exercise.

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.

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).

Thank you for trying!

For character-based movement, simply press 'z' to enter the column mode.

Regarding the built-in tutor, yes I really have to put in the effort, because it's so much harder than authoring documentation.

And yes, a lot more has to be improved, Ki needs a lot of polishing around the edges.

> For character-based movement, simply press 'z' to enter the column mode.

I did eventually find this in the documentation, under the "regexp selections" section. I think it should be more prominently displayed in other sections, since it's a natural thing to want (at first).

I am enjoying the editor (as a current helix user), and looking forward to trying it more.

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).

> 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.

It is in the names:

<em> = emphasized, as in "this part of the text should be emphasized in whatever way the styling dictates

<i> = italic, just a way to style directly

<strong> = strongly emphasized

<b> = bold, just a way to style directly

<i> and <b> do not make a statement about semantics, they are for styling, and probably not much used in modern valid HTML, or at least should not, if you have CSS available. <em> and <strong> make statements about importance of a part of text, in whatever way you want to style that. It just happens, that the default styling for those is italic and bold.

  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: dream@neoncity.dev

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.