Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
berkes
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
59 ms
·
961.
▲
by
berkes
3y ago
I was in the Donau valley two years ago (a gorgeous place) and the local train station for a village of under thousand people had fully mechanical operation! As in: levers, pulleys, weights that had to be cranked up, springs and even those
962.
▲
by
berkes
3y ago
Wholeheartedly disagree. I've yet to come across any git repo that didn't, at some point, commit the all_mypasswords.ini (or, just as bad, the .env.backup). I've only once ever seen a repo that had ENV vatlrs committed (where
963.
▲
by
berkes
3y ago
I've ran from such places. Luckily for every such management, there are many more managements that understand the correlation between short term and long term gains.
964.
▲
by
berkes
3y ago
I'd like to believe that "everybody" and "nobody" in your story aren't as black-and-white. Many people see the value of unit testing. And see how TDD actually shapes your code to be testable and (accidentally,
965.
▲
by
berkes
3y ago
> And prod defaults may not make _any_ sense for dev They are actually rather dangerous even. You certainly don't want your dev (or test CI) to reset the database if you are accidentally connected to prod. Same for email-endpoints,
966.
▲
by
berkes
3y ago
> dumb debug consoles have accidentally exposed env vars Huh? If the app can read the secret, then the app can... read the secret. Maybe I'm misunderstanding what you call a "debug console", but if this is anything running
967.
▲
by
berkes
3y ago
Ubuntu. I'm guessing you are referring to "swapping", though? If it's just one user process, it'll be killed by the OOM killer¹. That application will just be gone: poof. And for the rest you'll probably not no
968.
▲
by
berkes
3y ago
I've never encountered this with "many apps" starting to OOM, but many times with one process OOMing. That one will simply crash and everything else continues to run unharmed.
969.
▲
by
berkes
3y ago
I too have this "sandbox" directory. I use it for what you say. But also for troubleshooting, bugreports or a stackoverflow question. Just throw up a new project, hack around in it for an hour, and most often the problem/bug
970.
▲
by
berkes
3y ago
Python, PHP and JavaScript have significantly better performance for cpu-bound programs. E.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... And I have measured ser/de for PHP, Ruby (and Rust, we
971.
▲
by
berkes
3y ago
You'll really need to come with some backup of your claims. Because it simply isn't true. FP has been around for 10 years now, making phones, learning, scaling up. They sold close to a million phones every year since 2020 (last ye
972.
▲
by
berkes
3y ago
> The performance of Rails serializers is still a nightmare Well, The performance of Ruby is still a nightmare. Not just serializers. It's that serializers in Rails are the most prominent place where you'll have cpu-bound perfo
973.
▲
by
berkes
3y ago
There is no agreed upon definition of "strongly typed", so it depends on your interpretation of that term. Ruby is not, however statically typed, nor does it have a type checker (well, there is sorbet and RBS) Those are fixed term
974.
▲
by
berkes
3y ago
> Everything becomes a custom cut, often in multiple dimensions and all earlier errors cascade all the way to the end. Unrelated, but that sounds exactly like many software projects I've been unfortunately part of.
975.
▲
by
berkes
3y ago
Also, many of these controlled studies must be taken with a grain of salt. Where the "grain" and the "salt" are the actual details, variables and boundaries of the study. Aside from what you mention -longevity- many othe
976.
▲
by
berkes
3y ago
But you too make exceptions, right here. All I'm pointing out, is that people who oppose strong static typing on the base of "but we don't want it everywhere" are drawing the wrong conclusions, because, indeed, we don&#x
977.
▲
by
berkes
3y ago
Who is arguing for mandatory static typing? Even the article we're discussing points out there are cases for no- or dynamic typing.
978.
▲
by
berkes
3y ago
"Truly understanding what goes on" and "static typing" are in no way correlated, let alone causations. You are making a false dichotomy. It's perfectly possible to work in a dynamic codebase without understanding th
979.
▲
by
berkes
3y ago
I'm worried that the reluctance of the Ruby community to adopt some typing, might push it further into obscuration. For me, full time Rubyist for over a decade, it was enough to "jump ship" to Rust and TypeScript. It's o
980.
▲
by
berkes
3y ago
I doubt anyone is arguing that our bash scripts should be typed, or our quick "remove_currency_from_bank_csv.py" must be statically typed. The article puts a few cases forward. What the article is discussing, however, is the major
981.
▲
by
berkes
3y ago
sorry, but [citation needed]. I highly doubt that what you say is true. When I go the homepage of e.g. Kobo e-readers, two of their four sales-points are that the reader is confortable on the eyes. Same for the kindle, where the first two
982.
▲
by
berkes
3y ago
The point on invoice-numbers brings another issue to mind. We model our domain(s) using DDD, and often "The ID" really is best left a thing with meaning. Customer-id, Bank-account-number, invoice-number, email, etc. At least withi
983.
▲
by
berkes
3y ago
> anywhere outside of HN Did you forget the entire industry of ebooks and -readers?
984.
▲
by
berkes
3y ago
We solved that with UUIDS and updated_at and created_at columns. The latter the default sort in all views and queries. So the btree/indexing issues were hardly an issue. Whenever you fetch a set of rows, they will be bounded by these t
985.
▲
by
berkes
3y ago
Doesn't that still leak (statistical) information? It may not be technically security, but e.g. knowing your competitor just added N products to their shop, might be a security issue for the business.
986.
▲
by
berkes
3y ago
> So strong typing doesn't help you there at runtime, it just blows up differently. It really does, though. Not with the Java-type of strong typing (still allows null) but with the Rust type of strong typing. Simply because it moves
987.
▲
by
berkes
3y ago
I agree entirely about that tech debt. I've built, sold, grew and failed several startups myself. Many with Rails at the center. I've been building with Rails for way over a decade, so I'm well aware of the "options"
988.
▲
by
berkes
3y ago
I dare you to have a look at your rollbar, sentry or other exception logging of a rails project. And I'll put money on it, that the top 5 exceptions has several 'undefined method x' (probably on nil) errors. Those warrant uni
989.
▲
by
berkes
3y ago
> serious learning. That's another problem I have in this narrative. Productivity isn't measured by throwing an inexperienced developer at something and then looking how fast they get stuff done. That's learnability. I
990.
▲
by
berkes
3y ago
Not in my case. Rust, for me, is much better for productivity than my other major languages Ruby and JavaScript. The main reason is type enforcement, which is why -for me- typescript is much more productive than JavaScript. A large categor
More ›