To be fair most of typing problems in Rails can be solved by having contracts and an operation pattern, kind of like Trailblazer, although they went a little bit too far lol
I'm writing a small side project app using Next.js. I found out the bad way that i18n support is quite bad. Sure, you get an i18n router, but you have to manage translations on your own. There are libraries to do it, which are fine, but translations only work in the front-end, there's no way to, for example, use translations inside an API call (!!).
Also, halfway through they decided to push a new Next.js version (still in beta) so you''ll need to move all your `/pages` to an `/app` folder, with a completely new structure.
I wanted to learn something new so that's fine, but something like Rails, Django or Laravel would have allowed me to develop way faster. I'm quite disappointed.
Can you elaborate on "manage translations on your own"?
I am working on dev-first localization infrastructure after being frustrated with i18n from a dev perspective myself. Your remarks seem like they fit into the infrastructure approach I am taking. See https://github.com/inlang/inlang
Playadito is great. There's a kind of Yerba Mate that is easier on the liver and stomach now called Cachamai, and there's some alternatives too. It normally comes in with extra flavors such as Mint, Orange, etc.
I'm Argentinian, been drinking Mate daily (sometimes several times a day) since I was ~18 (32 now) and that Yerba is great :)
Really? (Didn't have the time to listen to the talk.) I'd like to know if it was somehow measured, ie. how much of the Elisp code is still not adjusted to use lexical scoping and how much of such code would break by switching to lexical scoping. You can still opt-in to dynamic scoping by using defvar (and it's been a standard practice since forever), so the only scenario where old code would break would be where a called function accesses local variables from the calling function, like you would do in TCL with upvalue. I suspect that's a pretty small percentage of all the Elisp code in the wild; plus, this would be caught by the byte compiler, without the need to run the offending code. In any case: the change of the default is welcome, though not very important, as we've all already got used to putting `lexical-binding: t` at the top of every Elisp file :)
WSL is great. I use my personal computer for gaming, but I also like using it for side projects, and dual-booting is a pain in the ass. WSL makes it super smooth to have a proper dev env. I can use gvim from Linux just fine, with a bit of configuration I can even share clipboard.
I think it still has a few rough edges,but fortunately I haven't had to deal with those. Also recently they added support for systemd which is awesome. Most packages "just work".
Both Bun and Deno aim to be batteries included, shipping Typescript and a test runner etc., by default. Deno initially aimed to diverge from Node and conform to the web platform as much as possible, i.e. use ES Modules and Web APIs over custom APIs. They've moved back towards Node over the last while to get more adoption. Bun broadly aims to be Node compatible, but they seem to try to stick to Web APIs too. Bun seems to value performance as a primary concern, with start-up time being an often-discussed metric. The value being improvements to local developer toolchains or fast starts in edge environments. Deno seems to value developer experience, with the goal being an overall better Node. They also benchmark performance against Node and seem to be faster in some places but not others. Finally, Bun uses the JavaScriptCore engine from Webkit, which it seems can be faster than V8 in some situations.
This is the perspective of a relatively detached observer who has played with both a little and kept up with their development somewhat but hasn't done a serious project with either.
Bun is an all-in-one JavaScript/TypeScript bundler, runtime, package manager, and transpiler focused on being being fast and a drop-in replacement for Node. Much of it is written from scratch in Zig.
Bun also adds many runtime APIs like a builtin websocket server, FFI, Bun.mmap, SQLite, Bun.Transpiler and more.
`bun dev` let’s you use bun’s transpiler for frontend code
`bun install` is an npm client you can use with Node and it installs packages 20x - 100x faster than npm/yarn/pnpm
`bun run` let’s you run package.json scripts really fast