HN user
It might be the opposite. Python apps still get written despite the performance hit, because understandability matters more than raw performance in many cases. Now that we’re all code reviewers, that quality should matter more, not less. Programmer time is still more expensive than machine time in many cases.
I've used XFCE for a 2011 laptop, it was about as fast as LXDE but better polished. Windows was unusable there, and XFCE made the computer feel brand new. Only the modern websites that would still cause slowness, but the OS was great.
I have noticed that static type checking often enables people to build systems more over-engineered than they could without it. It's not a coincidence that factory-factory-impl happened in Java, not Ruby.
The train of thought is “what is everyone using? I’ll use that too”
It's not just small typos, it's the ability to explore apis, the standard library, go to definition, quickly catch any error at the location it happens, not having to memorize large models and their field names, the list goes on.
I can work without an LSP, but when I'm searching for a new language that would be used by a team (including Junior devs) it's hard to justify something missing the basics of good DX. I haven't tried it with Cursor though, it might be less of a dealbreaker at this point.
I agree with all your points but last I tried, the VS Code LSP was terrible. It’s hard to justify a new language when even the basics of autocomplete, inline errors and go to definition don’t work well. Part of the reason was that any function can be called on anything, which pollutes the autocomplete list.
Has the LSP situation improved yet? Similar issue with Crystal lang, which I enjoy even more than Nim.
And if keeping in local storage a list of all pages, you can create an index html automatically in a predefined format which makes it more of a database rather than loose documents.
Not sure why this was downvoted, but I’d be very interested in learning how well does pglite compares to SQLite (pros and cons of each, maturity, etc)
It is ironic how “rewrite it in Rust” is the solution to make any program fast, except the Rust compiler.
This. Making something super customizable is a lot harder to implement (code being too generic, hard to reason about and debug) and often presents a worse UX ("why are there so many options??"). Having the UX design team interview and consider the needs of each user role interacting with the application, and ensuring the app displays/asks only the appropriate info for each user, hiding the rest and adopting smart defaults (instead of requiring everything), is easier to implement, safer and produces more intuitive interfaces than highly customizable ones, in many cases.
https://anvil.works/ uses Python
Yes, but in practice, is the difference significant enough to matter? I’m genuinely looking to see if I’m missing anything when favoring Python type system over Go’s.
I’m assuming that Python code base didn’t have thorough type hints. What if it had? Would Go still feel safer? I know these aren’t checked in runtime, but Python type system seems more thorough than Go’s, so shouldn’t a Python code base fully typed be even safer than Go? If so, why not?
(I know Python type checks aren’t mandatory, but for this question assume that the type checker is running in CI)
I’ve been having a different experience. Asking Claude to fix the bug again and again is annoying, so I’m still working on “pull pieces at a time, understanding each” so I do fix the bug myself when it’s faster to do so. In fact, the majority of times I’ve been using the LLM to build tiny libraries for me to avoid the need for the LLM in the running app. Kind of like StackOverflow on steroids. I don’t feel as the glue, but only having a superior tooling to get info I need fast.
The language and stdlib feel like a more polished Ruby, though I haven't explored it in deep. The tooling, last I checked, is what's behind - the interpreter didn't work for simple apps, and the LSP is slow and full of bugs.
Yes, I believe so because it uses global type inference. I would gladly add explicit types everywhere instead of this to use Crystal if it had decent tooling, because everything else about the language is really perfect.
Hey, just a shoutout that I love this platform, had a lot of fun playing several games with my nephews, high quality games with almost zero ads, kudos!
Our team considered Render but dropped for the same reason. We’re looking into Aptible right now, not as well known but seems focused on HIPAA compliance.
I like it. It’s an elegant solution and you can easily make higher order components from this.
That's not pedantry, that's clarifying, haven't thought like that before. Thank you.
I was curious about that as well. Since most services implement an email based Forgot Password feature, and 2FA tokens are also often email based, why isn't magic links the default approach now? Seems to be just as secure as password+2FA but easier to use (and probably to implement, as well).
By the title, I thought the article would explore some of the downsides of this approach that I might be missing.
Yes, with Solargraph. It uses type inference most of the time, and when it can’t guess the type, you can add YARD comments. Intellisense also works well (autocomplete).
There is often opposition - if the company I work for asks "what should we build the next app on?", React is the default answer that doesn't need convincing anyone, while SSR is much harder to sell (even when it makes complete sense).
This seems an interesting approach, if sufficiently safe for most cases. What if, when creating an account and choosing a password, the app enforced very long passwords but suggested a default, random one like in your example? This would have most of the benefits of the suggestion in the article (high entropy) while still not removing the choice of the user to pick their own preferred password.
Does your company also use 2FA? I'd be curious to see if very long passwords are secure enough to not need the 2FA anymore, as most methods are annoying to the user.
Doesn't the WAL mode solve the high concurrency write situation? If it can't be relied on busy season, why the push for Sqlite in production?
Nope, but working with fewer/smaller dependencies (like Kemal) it seems more manageable. Also, the feedback from type system is much faster than the full build, so I've noticed I don't need to run the app to test every small change like I do with ruby. There is also an interpreter mode available for testing, but I haven't tried it yet since that currently requires building the language from source. I'm hoping the interpreter will solve that DX issue entirely once it's ready.
Have you tried Crystal? I got the same "oh, they got this right too" feeling about everything as well.
This VS Code might be relevant to what you’re asking: https://dev.to/ko1/rstfilter-vscode-extension-for-your-new-r...
It prints the results of executing your code line by line, next to your source code.
Perhaps it’s not that they are boring, but fearful. I can’t recall a single time I mentioned these words in a conversation that weren’t abruptly interrupted with “there is no absolute truth!”. If the rebranding helps us calm down and think about it without fear, it might be worth it.
Seems very promising!