Kinda sorta. Yes, you a free to run off to anywhere in the world. Your passport protects you even in hostile countries. However, you are expected to return home and pay taxes. To leave the United States is an expensive affair if you want to truly leave by giving up your citizenship. To work abroad is expensive too if the foreign country has a lower tax rate. As a US citizen you are free to roam, but never to change your home.
This. And I suspect the United States are amongst the easier places to leave, along with the European Union.
In both cases, the populace are free to roam and settle within the borders, but moving outside the borders is a whole different matter (with a few exceptions, but there are always exceptions).
Firstly it might be easier. One site, one grid connection, one access road for heavy loads, one civil engineering operation, one security fence. One construction compound, fewer land owners and nimby neighbors. All the same reasons you might build larger factories or distribution centers. But more so. Pursuading local residents in suburbia is not a fight worth having.
Also, a project designed to export 1GW can connect to a regional or national grid. Then it can sell power far more widely. Connected to a local grid you have the same capacity issues as solar. Why bother?
That's kinda the design behind russian SVBR-150 (from mid 1990s, still waiting on money for finishing). Self-contained "cells" that can be delivered by railcar ready to use as power/heating/cogeneration plant. You literally need to attach normal COTS steam turbine or heat exchanger for municipal heating, and that's it as far as pure generation is involved.
For refueling you disconnect the pipes and cables, place it on the railcar, and send it to manufacturer.
Initial design for such cell was 150MW(e) each, thus the name.
I’m worried about that. I might be starting a medical application. I want a single language to teach to on-devs for front end and backend work. Dart looks good however, I don’t trust Google.
I think you don’t need to worry about that. They’ve probably invested around fifteen years of time into the language.
They want it because it gives them control over their future in a way that Kotlin or Java and the JVM do not.
The “bundle the whole world in your app” isn’t space efficient, but it’s efficient enough and sidesteps a large part of the outdated Android issue. Meanwhile the react-style components are very popular among devs with UI know-how. The rapid uptake of Flutter also speaks to the hole it is filling.
Then there’s FuschiaOS where they’re seemingly intent on making it the primary dev language.
Lots of good reasons to continue support and not many reasons not to. Sounds like a decent bet to me
Have you considered Jetpack Compose ? (https://developer.android.com/jetpack/compose) Despite it being a Google project, it also has backing from Jetbrains (https://www.jetbrains.com/lp/compose/). Having access to the full JVM environment of libraries is an infinitely better state than Dart, and Kotlin is also a much more pleasant language. Testing cycle is sliiightly slower, but Compose previews make it easy.
I've been playing with compose and it looks really good. Note that it's still on beta(api should be considered stable) with a release this year. Previews are kinda wonky for now. Sometimes it wouldn't refresh. How hard is it to implement hot reload?
And like I mentioned before, with my low-end laptop its hard to run full Android Studio. Tho Dart's not that pleasant compared to Kotlin, the tooling outside a single IDE was enticing for me.
> I want a single language to teach to on-devs for front end and backend work
if that's what you want then you should support things like kotlin multiplatform, react-native or SwiftUI, dart is a very meh language comparing to those above with established back-end ecosystems.
The problem I have with Lombok is that suddenly it’s hard to trace getters and setter from the Pojo. By this I mean asking the question, “where is getId() used” is hard if I want to use the find references feature of the IDE.
For example, if you want to automatically create getters and setters to all private variables, why not make them public in the first place?
I hate when tools mess with IDE. What about guys using Emacs (or any other editor that does not understand Lombok)? I think generating code from IDE is fine as well as having code generated from build system distributed along with code, but having that code generated through magic of annotation processor is not as nice. I also suspect that Lombok messes my IDE on a deeper level but I have not yet a good concrete proof. Recently I am more and more frequently finding situations where Idea messes up understanding correct types of things and it takes for it some time to catch up (and sometimes reloading the file).
On the other hand I love small things like creating builder or logger. Which is to say these can be just as easily generated from a template, no annotation processor needs to be involved.
I think main feature of Java for many years were its IDEs which would allow to run accurate refactorings or always understand who is using particular piece of code, what is exact call hierarchy, etc. I feel loosing that is going to make Java much less useful for me when I try to analyze large project or run huge refactorings.
If you're in an old school "OOP" style java codebase, where each class is its own little island of encapsulated state and behavior, the coupling of the two means that strictly controlling access via getters is usually required.
Even in more "modern" java, where you do most of your programing against plain data, having Lombok attach getters still gives you some quality of Life benefits because you can use method reference rather than anonymous functions for high-order access (e.g. `things.map(MyClass::getName)` rather than `things.map(myclass -> myclass.name)`)
I'm with you on mixed Lombok feelings, though. It's great right up until its not. It fails or doesn't work in really unexpected or weird ways, and is the source endless pain when you've got other annotation based things (like dagger) which then imposes annotation processing order failures.
> If you're in an old school "OOP" style java codebase, where each class is its own little island of encapsulated state and behavior, the coupling of the two means that strictly controlling access via getters is usually required.
That I agree. My comment was meant to be cheeky a little bit as it is actually pretty difficult to find trully OOP application, at least in area of backend apps I am working in.
Obviously, in OOP you are not supposed to expose your internal state but rather accept messages to run behaviour.
If you are working on a truly OOP application then Lombok is useless. Your public class interface is all that matters then and you would spend more time fighting Lombok than just writing it manually.
Lombok is only good at automating boilerplate which, if you have a lot of, is a sign of some other problem.
> It's great right up until its not. It fails or doesn't work in really unexpected or weird ways
That is exactly the point. Magic is fun until you find out that it leaks horribly and causes unintended side effects with all sorts of stuff.
What's the point of replacing simple problem (just really use templating mechanism you have in your IDE) with complex problem (dealing with magic failing on you).
Unless we are talking about API, then you add getter and setter. You might even be able to refactor all callers automatically via IDE. I mean, I dont mind getters and setters in java, it is standard at this point.
But origin of it is in EJB specification, it is not something that would be interently needed elsewhere. It just "feels wrong" to programmers (including me) at this point.
I'm working in a product that is about 10 years old and 4 months ago it went through a quite a big project which purpose was to add extended auditing to be more enterprise friendly. The system was flooded with auditing events on various changes into internal data. The system provides a public API and allows to install plugins. If we had to change our entities that would be a compatibility nightmare for thousands of plugin vendors.
I'm not sure how this works in other IDEs, but lombock Eclipse plugin kinda solves this problem. You can run CTRL+Shift+G (Find references) on getter/setter that is shown in class outline and it will immediately give You getter/setter uses.
From hangin out on Reddit for dlang, the http server is pretty slow. This has caused people to look elsewhere. Some people are trying to improve the performance, but it’s not a high priority.
Also they are tuff. They have about 1” of skull. They also have platted shoulders. This means that many handgun calibers do little to them. Well placed shots in the eye or ear will take them about. Otherwise you need a high powered round like a .454 or .3030.
This means most creatures can’t take them on. We’ve also removed some that could like wolves.
They reproduce rapidly. Even with wolves, their numbers grow because most alpha predators don’t want to fuck around with them for fun, only for food. Once the pack is satiated, the piggies move on.
Boar are from Spain. They would let the pigs go while exploring. Come back a year later and you have a stocked larder. Hunt pig to get meat back on the menu.
That would be absolutely terrifying. The economy we have now is due to experts tinkering. Allowing the masses, who can't organize their own lives, to attempt to organize the economy will lead to more deaths and misery than the current system.
Would you want a democratically elected airplane pilot with no training?
Not even sure where to start with this level of elitism, but Elon Musk is certainly an expert in batteries, automotive production, rocketry and telemetry, and financial services all at once and not just a brand.
The kind of sentiment you are expressing is directly antithetical to having any kind of real democracy.
If you've ever met the people in power, many of them are quite dumb. It's easy to listen to experts (or not) and give commands. How often do you hear that executives don't know what's happening in their companies but the people on the line know exactly what to do but were not consulted seriously?
To answer your question about airline pilots, I would probably accept (and in fact do, the FAA) a system designed by what is allegedly a democracy. Usually people don't have direct popular elections for technical positions, but design rules in consultation with people familiar with the field. If the voters were in fact other airline personnel, a direct election could be viable though I would require some qualifying criteria (e.g. people with XXXX hours of flight time).
