These are not normal teething problems, it's straight up poor poor software and the claims about the supported features are quite simply lies right now. Last time I looked at the compiler, it was basically doing search and replace to generate buggy C code.
With React Native, you're betting on a framework. With Flutter, you're betting on both a framework and a new language. Flutter also works on a much lower level than RN, which means it would be harder for them to pick up the development if the need should arise.
That point also ignores the fact that spanish workers are indeed cheaper than german workers. You can't focus on the unit of measure (the currency) while ignoring the accompanying number...
What does he spend his days doing? I wrote a configuration file years ago and I still use it for multiple projects. I only had to update it when upgrading between major versions of webpack.
> 1. The prior and new behavior is neither good nor bad.
That depends from which point of view you're looking at it. Technically according to the law? All good. Ethically? Different people will have different opinions, but many would agree that it's bad behaviour. You're a law abiding leech on society, but you're still a leech.
> The criticism towards Google, Apple etc. for minimizing their tax burdens has always been misplaced.
It's a valid criticism if you don't think that "Corporations are supposed to maximize profits" should be true. When anything can be justified because it maximizes profits it becomes very, very easy to be a technically law abiding unethical company which is a net negative on society.
Python has some fundamental language semantics that make it really hard, if not impossible, to create an implementation that can match Java. Pypy is probably the best you can do to optimize python, and it shines in tight numerical loops, but it gets less effective as code gets more complex.
You still need to go call into Javascript to do any kind of DOM manipulation. The solution I used for wasm-forth (a forth implementation targeting wasm), is to have a js "interpreter", implemented as a single function, that executes a sequence of DOM manipulation instructions, represented as an array of integers. On the forth side, the instructions are generated by a virtual DOM library: as the virtual DOMs are diffed, instead of manipulating the DOM directly it generates a sequence of opcodes to send in one go to the Javascript interpreter.
The cost of the Javascript bridge is minimal: it's a single function call to render or update a whole page, and there is no serialization/deserialization involved since both languages can understand arrays of integers natively.
When I tried them a year ago, they used "Any" a lot, especially around the ORM code (Django) and the serializers (DRF). Since those are also the parts where type checking would be the most interesting, I didn't find a lot of value in using them.
I recently upgraded from 1.11 to 2.2 in one go. I didn't have any issue at all, besides a problem with mysql drivers. I had to switch from using PyMySQL, which is not the one recommended by Django anyway, to mysqlclient, and that caused one minor problem that was trivial to fix. Looking at the release notes for 3.0, I'd expect that if I migrated from 1.11 directly to 3.0 it would've been a smooth transition.
Of course it depends on your codebase. In the past I worked on a project which interacted a lot with Django internals, with a lot of code reflection involved. Upgrading that was a pain even between minor releases.
Django (and DRF if you use it), uses too much reflection, which doesn't play nice with type annotations. The strategy that works for me is to annotate my application code, and keep using dynamic typing when interacting with the framework.
A data corruption might be also impossible to recover from. You could even only notice it after months of it happening, e.g. if your users spend months collecting data which is only analysed at the end of the year.
Is that still true after tuning the JVM GC for a low memory footprint? I'm genuinely asking, I'd like to see an article on the subject. I've read in the past that the default settings are geared towards long-running processes and trade off memory usage for higher throughput, as in general there's no free lunch with GCs. Better memory usage always implies worse performance (and viceversa), just like a higher throughput increases pause times. If Go has lower memory usage and lower pause times, I'd expect it to have lower throughput than the JVM GC.
Good luck with that if you have a non-technical user base. Gaining trust when the first thing they see is a big warning telling them this software shouldn't be trusted will also be really tough.
The article mentions a "quality control process", so it's not only about the author being authorized. I view this as a first step to turn desktop computers into locked down iOS devices.
What I find funny in these discussions on HN is how most people seem to be completely oblivious to the obvious solution, proven to work in many developed countries around the world: have the state directly fund universities and don't charge tuition to students (or charge them a small amount). Why is the assumption "universities are private endeavours that should make a profit" something that goes unchallenged on HN?
Yes, it was introduced in late 2018 and came into effect this year. It's basically an extension of an equally bad tax cut that was previously reserved to people earning less than 30k. Given the higher limit, it makes the jump above that limit twice as steep.