ibraheemdev

If you're referring to map[K]V, that's not true. Go doesn't have generics, it uses some compiler magic under the hood specifically for the map type [0]. The generics proposal is being implemented from the ground up.

[0]: https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...

I don't want to be that guy, but have you tried Rust? If so, what makes it not the C replacement for you?

> Node.js came out in 2009, a full ten years after HTTP/1.1 (RFC 2068) and it's original http-parser is full-on spaghetti code, doesn't conform to the RFCs for performance reasons, and is considered unmaintainable by the author of it's replacement

That's because of the way the parser is written. There are other simpler parsers that are much more readable.

The Rust compiler is a great example of one that is very beginner friendly. Diagnostic (error message) issues, of which there are many, are a relatively easy way to get started and learn the codebase. The community is also very friendly to new contributors, and you can learn your way around the compiler and choose to work and learn things that interest you. There are certain things you'll need to know for certain parts of the compiler, such as some graph theory if you're working on Rust's MIR, and you should read a high level overview of how compilers work. Compilers are a huge, never-ending field of study/work. Start small and work your way up from there.

Didn't Scala futures also inspire JS promises, or was that published beforehand?

Well you said "maps are generic in the same way that they already are in Go", which I took to mean that Go already has monomorphized generics under the hood, they just aren't exposed publicly.

Go's nested struct syntax actually makes doing so quite nicer than Rust :)

`interface{}` used as a type is almost exactly `Box<dyn Any>`.

Yup, it's a common misconception that Go language designers are anti-generics. They wanted to include generics, the reason they were left out is that there was no clear way to include them without significant downsides:

> The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?

> I would be happy to learn about implementations that somehow manage to avoid all three of these bad outcomes, especially if there were good written descriptions (papers, blog posts, etc.) about what was hard and why it's a good approach. I'd also be interested to see good written descriptions of trying one of those approaches and what went wrong (or right).

- Russ Cox (2009): https://research.swtch.com/generic

Well the interface's method set is empty, not the underlying type.

> the maps are generic in the same way that they already are in Go.

Go maps are actually not generic in the same way they are in other languages, there is just a single map struct with type descriptors used to do some compiler magic: https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...

`interface` isn't a type, it's the keyword used to declare an interface:

   type Foo interface {
     Foo() int
   }

`interface{}` is simply a shortform for an interface with no methods.

Or someone who thought it was interesting and wanted to share it with others, not knowing that it had been posted before.

It would be great if someone compiled a list of important libraries missing from the ecosystem.

Java will throw a ConcurrentModificationException. Go can cause undefined behavior.

Was the tweet taken down?

To each their own. I personally love my monolith init.lua :)

There are replacements for most/many popular packages (that I use at least). Many people do prefer lua packages over vimscript ones.

Hm, mine worked out of the box with `nvim-lspconfig` and `completion-nvim`. What 3 different plugins are you referring to?

For anyone else who couldn't find the changelog, it's in the commit message:) https://github.com/neovim/neovim/commit/a5ac2f45ff84a688a094...

One little-talked about advantage of Lua support is that you can now write your vim config/scripts in one of the various Lua transpilers like moonscript [0], or maybe even typescript [1]!

[0]: https://github.com/leafo/moonscript

[1]: https://github.com/TypeScriptToLua/TypeScriptToLua

[2]: https://github.com/hengestone/lua-languages

If anyone is interested in migrating their config to lua, or doing some basic scripting, there's an excellent and pretty comprehensive guide here: https://github.com/nanotee/nvim-lua-guide

It's already on the arch and brew repos.

Lua is much nicer for scripting, yes, but support is not there yet. There are a couple missing APIs, and just some overall verbosity that is still being cleaned up and worked on last I checked.

And, ALE has LSP support.

For anyone wondering: https://github.com/asvetliakov/vscode-neovim

I can't find a source, but I know Brave has had upstream Google issues in the past. Unfortunately, from what I've heard, Gecko is not very developer friendly, so Google is pretty much the only option.

Like all of his videos, Jon Gjengset's live coding session on lifetimes is excellent: https://www.youtube.com/watch?v=rAl-9HwD858

Ah okay, so Devise does lookup the user in the database to authenticate. I guess it's not applicable to my premise then.

For 2 and 3 I was mainly referring to Identity, although I'm not sure how it works internally. For 1, I think the main issue is that when someone logs out, or you log someone out, you aren't guaranteed that they are actually logged out. There are cases where this does matter.

How does Devise handle 'revoke all sessions for this user'?