1,022 karma · joined October 29, 2020
I was sympathetic to that idea then, it sounded good in theory, however in practice it was horrible.
Today I enjoy coding in "bloated" languages with only a few external dependencies.
20 year old software is rarely a problem, I'm running Office XP on Windows 10 without problems.
With that said, I think proper tooling can solve much of the problems with unsafe memory languages. Question is then, why doesn't it happen? Are developers uninformed, arrogant or just lazy? Is forcing it into the language the only way to solve this?
No overusing of weird macros, no large structs to define (IUP uses void pointers) or other C-isms that can be hard to translate over language barriers.
I tested to write bindings for PHP over FFI and it was trivial.
Main drawback is that the Mac support is experimental.
Less strict code is something that you can throw away and rewrite without too much effort.
This has the implication that you have bulkheads (like in a ship) to separate high value and low value code, thus you have to avoid code that is toxic (i.e magic) that spreads between them, e.g. ORM entities.
When using the type system correctly you don't need 100% coverage, now I'm not a Python programmer so I don't how feasible that is with that type system, but in PHP I use the type system extensible and I don't write that many tests anymore, except for legacy code or when I need to test something specific, like an algorithm. By using the type system you can catch most programmer errors, and combine that with routinely throwing exceptions for any unwanted state, you will detect most bugs.
The way unit testing has been interpreted and implemented it has become more of a nuisance than a help in fast moving projects. Usually what happens is that the team refactors some unit and then multiple test breaks and then time needs to be spent rewriting these test, but what that means is that the tests were actually useless after they where committed if you can change them as you like, when you change a test you are no longer testing the same thing.
Thus tests can also can be graded, from high value tests, i.e stable, and low value tests. Depending how you organize your code, high value tests will usually test a larger set of functionality in one run, like a system (or integration) test from call to finish, these should never change regardless of much you refactor. High level tests should only change when your business logic changes.
Low value test typically involves a lot of mocking and stubbing, those are pretty much pointless to commit after you implemented your unit. Too much mocking and stubbing is code smell.
Sentry client v1 (Raven_Client) you can configure the client in different send modes (curl_method), sync (default), async (curl_multi), exec (fork)
https://docs.sentry.io/clients/php/config/
For Sentry client v2 I think you need to configure the Transport layer to use async
https://docs.sentry.io/platforms/php/configuration/transport...
e.g PHP
https://apps.microsoft.com/store/detail/python-311/9NRWMJP37...