sodapopcan

Up-ranking, down-ranking, and straight up blocking sites is a big one for me. No more scrolling past w3schools or geeksforgeeks for this guy!

Also, it's built in that sites with a ton of ads are down-ranked.

Actions are clearly affected too but not represented on the status page.

Oh boy there is a whoooooole fun thing on that here: https://github.com/prettier/prettier/issues/7475

And ya I also don't appreciate having to care about formatting for my code to compile and not being able to put debug statements at column 1 so they stick out like a sore thumb, though I suppose the solution to the latter is to stop being a puts/print debugger but, like... no :)

Gotta love that this comment has the most replies :D

I don't understand how people prefer curly braces, a character that is almost always has other meanings within the same language, instead of something like `end`. To that (ahem) end I don't understand how people prefer `end` to the exceptionally clear `endif`. Turns out different people have different preferences :D

I wouldn't say that `:!bash` is the most illustrative example of its impact. It bites you when you run any command that spits out a prompt, most commonly a [Yn] prompt. You can't use `:!` for these in nvim.

Speaking purely technically here, vim9/L has an actual standard library tailored specifically to Vim. Lua has no standard library and you just end up delegating to vimscript anyway. But ya, if you want to use Lua for whatever reason then it's a pretty hard sell. But that's sorta what OP is getting at... how to make it more attractive.

> Of course this still does not mean that people will want to learn yet another scripting language

I understand this sentiment and that there are certainly psychological blockers in having to learn too many languages, but vim9 is very simple to learn. It is much closer to a "familiar" language than Lua. Plus, you are going to have to be familiar with Vim's standard library anyway. I believe they are adding more and more helper functions but Lua plugins are full of `vim.cmd` and `vim.fn`. I don't dislike Lua as a language at all, but I much prefer "scripting Vim" in some sort of "VimScript" :) But to each their own.

It's not, though. A bunch has been stripped out (interactive :!, :view, etc) and time only time will tell how much further they will drift apart.

> Admittedly I speak as a software engineer primarily building CRUD apps

Ya, this is the majority of us.

Private repos exist for a reason. It's reasonable that if you don't want humans seeing your code that machines should also not see your code.

You're right. I was probably drunk.

Fun until it actually asked me to identify myself... which was pretty much immediately.

Haha, ya, this is along the lines of “You can’t send HTML over HTTP without JSON.”

No idea if anyone was complaining, but if building in CI it shaves off some pennies (or more?) no?

Yes! This sums it up perfectly. To the latter point, it's more so a tool for building design systems that comes with a [very large and thorough] default implementation.

> and perhaps most importantly there's a "right" way to do just about everything your web application will ever need to do

A good chunk of chaos in Rails apps is caused by people who either insist they know better than the out-of-the-box solutions, or they “just prefer it my way.”

A "marketing" way of putting it is: "Exceptions are reserved for situations that are truly exceptional."

Already said by two sibling comments in all the detail I would have, but I wanted third it: as a subscriber to boring technology myself and actually never been one to jump on new shiny tech, Elixir/Erlang is the epitome of "boring technology." Elixir does a lot on its own you can often cut out the need for a lot of other dependencies.

Ya, "let it fail" is a semi-unfortunate tag line. A lot of people think it means literally to not handle any errors ever and get really frustrated.

Yep! It's leveraging pattern-matching and guards as well as looking at code itself for inference.

Thank you for the full story here as I just gave the issue a cursory glance. As someone quite ingrained in Elixir, I see an issue referencing specific patch versions of Elixir and OTP and immediately understand it's very specifically targeting that specific Elixir/OTP combo. But depr brings up a good point that not everyone is immediately going to understand this, especially newcommers to the language and it’s generally hard not to just read the headline.

TL;DR: Erlang/Elixir/etc are high level languages and the virtual machine they run on, the BEAM, is optimized for speedy IO but is not so great when it comes to intensive CPU tasks. You'll want to write the latter in a good systems language which is what libraries like this provide (you get C bindings out of the box, I believe).

The semantics can certainly be argued, but a type system is sort of on its own tier of as far as language features go. Most importantly, there is only going to be one backward incompatible change which is the spec syntax, otherwise it is just leveraging how we already write Elixir.

Ah ya, I do see how the optics of this could give off that impression. I don't use this library myself, but the issue is with Elixir 1.15.7 & OPT 26.1.26 which is VERY different than "It doesn't work on OTP 26." Certain patch versions of Elixir and OTP have caused problems before (sorry, I don't have a citation) and this particular issue looks like it's related to dependencies not syncing up on the config change?

I do think more libraries should give that little "We're still maintained" notice as people not totally ingrained in this might not realize. To some, the fact that there have been no issues reported now that we're on OPT 27 and Elixir 17 would be an indicator that all is well.

It’s pretty common in the Elixir ecosystem for these types of libraries to not change very much. Elixir itself doesn’t change too much so these libraries stay solid without needing frequent updates. It doesn’t mean people aren’t using them. Some libraries even put disclaimers that they are actively maintained even if they haven’t seen an update in a long time. It’s something that takes some getting used to for some people (including myself at one point).

> I think one of you has one in mind and the other the other.

This is very possible.

How are plural names linked to those things, though? I have a low-care level for naming conventions so long as there are conventions. Many successful frameworks use plural tables names. Though I agree singular probably makes a little more sense, especially since it eliminates the need for inflection code.

I don’t really follow. My focus wasn’t on the naming but the location of responsibilities.

Along the lines of what OP is talking about, part of the problem is that Rails has no service objects, so I have seen a handful of different ideas of what they mean (probably no more than 10).

The one I've seen he most is stuff like `UserRegistrationService` or the like. These things can end up getting scattered and in general, I would rather just talk to the business object, ie, `User.register` which can delegate to a more complex private object handling it. It's basically "inverting" things. The win here is that things are more discoverable (You can look at the user object and see a list of everything it does) and more importantly draws better boundaries. This way the web layer only has to know about `User` instead of `RegisterUserService` and `DeleteUserService` etc.

Again, services can work and aren't inherently bad, but plain MVC can certainly also work.

> * It's my view that MVC (and therefore Rails otb) is not ideal by itself to write a production-ready app, because of the missing service layer.

This is quite the claim. I despise service objects, personally. They end up scattering things around and hurt discoverability. There are other ways to do modelling that scale very well. There are a few blog posts on it, here's one from someone at Basecamp: https://dev.37signals.com/vanilla-rails-is-plenty/

This is of course very OO which I'm not a huge fan of. Elixir's Phoenix framework, for example, uses "contexts" which is meant to group all related functionality. In short they could be considered a "facade."

In any event, if you like services you like services, they can work, but saying MVC isn't enough for production-grade is a bit misguided.

I do agree that model callbacks for doing heavy lifting business processes is not great, though for little things like massaging data into the correct shape is pretty nice.