YorickPeterse

> I also don't like how there looks to be an upcoming split in the plugin community when Vimscript 9 releases and the neovim community will ignore it while plugin authors in the vim camp (e.g tpope) may start moving their plugins over to it.

Honestly Vimscript 9 always felt like a serious case of "not invented here". Bram could have easily chosen one of many existing languages, but instead decided to take Vimscript and make it even more bizarre (this was even more so the case at first as IIRC block delimiters for example were really odd).

Setting that aside, you could also argue that people moving their Vimscript plugins over to Vimscript 9 is a problem on their end because it makes the plugins incompatible with NeoVim. In other words, the argument is basically silly.

The documentation is there, but it's a bit lacking/confusing here and there. It's also mostly foundational work, and you still need to cobble things together (either manually or using a plugin).

With that said, you can build things quite nicely with it. For example, I have a custom linter setup, custom loclist/quickfix list formatting and populating from LSP data, and a bunch of other things; all using the foundational work coming in NeoVim 0.5.

If anybody is curious, you can find my NeoVim configuration here: https://gitlab.com/yorickpeterse/dotfiles/-/tree/master/dotf...

p.s. In case anybody wonders "why Lua?", for me this mostly comes down to this: I hate Lua, but I hate Vimscript even more.

Your argument as a whole seems to come down to "Some _may_ abuse it, so we shouldn't do it". Frankly that's about as weak as an argument as it gets.

Somebody could use a spoon to murder people. That doesn't mean we should stop making spoons. Similarly, some countries or individual politicians may try to abuse environmental related policies to further their personal agenda. That doesn't mean we shouldn't call for more strict regulation.

Simply sitting around doing nothing out of fear of doing _something_ (but wrong) isn't going to get us anywhere.

> What if I told you, you can’t have a gas powered car anymore because it’s killing the planet and humans?

I don't have a car, so that's fine. Also there's this thing called "an electric car". You should look it up :)

> What if I said the same thing about all oil powered ships and planes?

I'm not sure where this "it's either A or B" mindset comes from, but it's not a particular intelligent one.

Just because we need to stop destroying our environment doesn't mean we have to stop doing _everything_ that involves fossil fuels. Long term maybe, but not necessarily all at once.

> Because I feel the planet is worth saving, can I force you to abandon all fossil fuels despite the massive financial cost and the limits on things and experiences you can enjoy in the future?

When given the choice between no fossil fuels and no Earth, I think the choice is easy. Fortunately we're not quite there yet, so I'm not sure what point you're trying to make.

There's nothing totalitarian about holding people responsible for the long term damage they do to the environment. It should also be painfully obvious at this point that a more passive approach does very little.

Erlang has been doing this for the better part of three decades. Of course Erlang doesn't compile to native code, so at least that's a difference.

Oh I don't know, how about: solar, wind, nuclear, hydro; plenty of ways to power a railway network without the need for fossil fuels.

The real challenge here is likely governments simply not wanting to invest in this.

This is just the same excuse as the age old "Boys will be boys" excuse. Just because somebody is different doesn't mean they can be a creep and general unpleasant person to work with, without there eventually being repercussions.

In the past people have suggested we rewrite GitLab in Scala, Haskell, Node.js, and IIRC also regular Java.

I think it mostly comes down to "I didn't write it, so it's bad" :)

> Automatic changelog via push tags

Worth mentioning: we don't support generating changelogs when pushing tags. What we did add is an API that can be used to generate changelogs. This API takes a range of commits to use for the changelog. What we support here related to tags is automatically using the tag of the last release as the start of this range.

I always felt RAM wasn't so much a downturn, just too different from their past work (which was the reason I liked them so much).

I suspect the reason is the duo simply wanting to do different things. After all, they've been Daft Punk for almost 3 decades.

> It's disheartening to explain this over and over again, but these frameworks are a-ok because user's expectations for the web have grown astronomically.

Users absolutely don't give a shit about you using Grunt, Gulp, Burb, Babel, and the billions of other tools. They just want to pay the meal they ordered online.

> 2. Hot-standby instances can't be used for anything serious since all queries are dropped regularly (I believe it's not safe to use "hot_standby_feedback" config to overcome this issue).

Hot-standby instances are fine. We've been using these for GitLab.com for a number of years now, and never have they caused any issues. We do have some code in place that retries queries when they are cancelled by the hot-standby, but IIRC this doesn't happen often.

Over the years I've learned there's a class of users that simply don't read.

Example: for GitLab we stopped using the repository that used to host the code for GitLab CE. All issues were closed, and when you create a new issue there's a template active that basically says "Don't create issues here". In spite of that, people still create issues here, and in some cases don't even bother changing that template.

I think the challenge here is that there aren't easy to use solutions for this. For donations there's Patreon, GitHub Sponsors, etc; but for invoices I'm not sure if there's an equivalent that makes sense.

How exactly does V know when/where to release memory?

> Can you imagine what life on Earth would be like if the cosmic background radiation was the brightest thing around?

We'd probably be dead. This also has nothing to do with dark mode.

> Cannabis is legal

It's technically illegal by law, it's just condoned/tolerated under certain regulations. There have been plans to make it fully legal, but it's not really going anywhere if I'm not mistaken.

While the main HQ is in San Francisco today, it started out in The Netherlands. There's still a Dutch subsidiary and office, but it's mostly used to employ people.

Beyond the syntax looking a bit similar, Crystal is a very different language. Porting over a production application such as Shopify isn't something you do in an evening.

What I never understand with discussions about COCs is that a lot of people seem to act as if COCs are to blame for how they are enforced, and that this is somehow a new thing. Before COCs were a thing, projects would still arbitrarily enforce rules, and not always the right way. This is nothing new.

I personally applaud the idea of a COC, much like software licenses. It's just a bummer that a lot of people out there in a leadership position don't know how to fairly enforce them. It also doesn't help that many COCs are poorly written, much like when an engineer without legal experience tries to write a license. Hopefully this will get better with time.

The repository storage size is 10GB [1]. I wouldn't consider that "extremely small".

[1]: https://docs.gitlab.com/ee/user/gitlab_com/index.html#accoun...

I've tried Tridactyl, Vimium, Saka Keys, Vimium C, and Vim Vixen. Of these, I found Vimium C to work the best and have the least overhead. Tridactyl added a consistent overhead of around 100 milliseconds when loading page, while Vimium and Vimum C added only about 20 ms of overhead.

In terms of features, I think Tridactyl is the most feature complete, but I found Vimium C to be more enjoyable to use. For example, Vimium C seems to produce better hints (e.g. fewer cases of hints for something you can't click on), when compared to Tridactyl. I also prefer Vimium C's "Vomnibar" over the Tridactyl interface, especially with a bit of tweaking to the theme.

I recall we considered this at various stages a few years back. I think this was around the same time we introduced our chatops integration.

I don't know the exact details and can't speak for others, but I suspect GitLab realised that chat(ops) tools are hard to sell and our time is better spent elsewhere. It's a shame though, having Gitter/chat directly integrated in a project (properly, not using e.g. an iframe) would've been pretty cool.

I've found it's not so much the distribution, but the desktop environment, combined with an HiDPI display. I think I haven't had the need for any special changes in years, other than maybe changing the hinting style based on personal preference.

> Another question is which language loads modules the fastest (afaik Ruby is kind of slow when it comes to `require`).

I think both Python and Ruby loosely follow a similar model. The difference is that IIRC Python caches bytecode files, while Ruby compiles them from scratch every time. Not sure how big of a performance impact that has, especially for simple cases like this.

And just to toot my own horn, using Inko (https://inko-lang.org/), I get:

    inko /tmp/test.inko # 0.470 total

Note that this invokes the horribly slow Ruby compiler currently in use. If you invoke the VM directly on the compiled bytecode, it only takes about 10 milliseconds to run. Using the `master` branch:

    vm/target/release/ivm /home/yorickpeterse/.cache/inko/bytecode/release/43/38021ddc9a3449ace13288a2fac894d1d3e2aaa.ibi # 0.008.8 total

In this case all modules (including the standard library) are included in the bytecode file, meaning no disk IO is necessary, and modules can be parsed in parallel.

This is something dynamic languages like Ruby and Python can't do, as loading modules is something that can be done anywhere at any time, so you have to process them one by one.

I find this hard to believe. There are plenty of companies out there providing some kind of product built on top of another (e.g. a language), without registering the name of said product as a trademark of their own.

To me it sounds more like you didn't get the things you wanted, and instead decided to try and take them by force.

A language licensed as the GPL likely would not see any users, as programs built on it would link to it (or at least parts of it, such as the standard library); thus requiring either an exception clause, or that all software using the language also be licensed as GPL.

IIRC the AGPL is better for this, but most GPL licenses are just blacklisted by companies; reducing the likelihood of the language catching on.

This is also how we do Staff Engineering at GitLab: you're expected to spend most of your time writing code. What changes is how you go about doing that, how you communicate things, what responsibilities you have, the expectations of you, etc.

I helped out with parser as well for a while, though it was mostly documentation, triaging issues, that sort of thing. I think I still have push access to the Gem, as at the time the project had a bus factor of 1 (= whitequark).

Anyway, I remember just how frustrated whitequark would get every time CRuby decided to make some random syntax change. I have a lot of respect for the current maintainer(s) for putting up with the ever growing complexity of the Ruby syntax. I hope Ruby stops changing the syntax on a regular basis, but I doubt this will happen any time soon.