Yeah it's really jarring to be reading a text in not-english that seems somewhat normal and then to trip over some extremely American reference that makes it obvious it was auto translated. I just want things to have explicit language toggles or maybe allow me to hover over some text to see the translation. Google even allows you to set multiple languages and they still insist on auto translation between 2 languages I have told them I know.
I don't share your doubts. Even people not directly exposed to the bubble may be indirectly exposed by way of funds they've invested in or retirement accounts, or even just by having invested in something that invested in something that may evaporate with the bubble. Not to mention jobs that may disappear, which will result in the people who held those jobs being less able to spend their money, which has knock-on effects in the rest of the economy if it happens at large enough scale.
I think a feature like this sees best use in short lived programs (where startup time is a disproportionate percentage of total run time) and programs where really fast startup is essential. There are plenty of places where I could imagine taking advantage of this in my code at work immediately, but I share your concern about unpredictability when libraries we use are also making use of it. It wouldn't be fun to have to dive into dependencies to see what needs to be touched to trigger lazy imports at the most convenient time. Unless I am misunderstanding and a normal import of a module means that all of its lazy imports also become non-lazy?
Getting any kind of information from a chess engine would be sufficient to gain an edge for a good player. Even something as simple as a nudge that there is a high value move in a position with no information about what the actual move is could be enough. Big chess tournaments tightly control phones and other devices for this reason. That's on a single-match level. On a tournament level there have been allegations of collusion where players will intentionally arrange their own matches to either be quick draws (to get a break to focus on other matches) or to give points to a designated player to help them win the tourney, Fischer famously accused Soviet chess players of doing this.
They are right now sure, but the scenario as quoted in the previous post could just as easily have risen from China's side as a response to some geopolitical drama and the US would have been just as unprepared for it as it was for the current self foot shooting. A strong manufacturing base is a national security asset and the US has mostly allowed it to rot out. Some niches have been propped up by defense spending like weapons design and manufacturing or military shipbuilding, but even those are downstream industries that need a general base to stand on that they no longer have and it shows.
it is opt in until they manage to convince some government to allow them to be the contracted provider of "humanness verification" that is then made a prerequisite to access services.
NIFs have the downside of potentially bringing down the VM don't they? It's definitely true that the glue code can be a pain and may involve warping the foreign code into having a piece that plays along nicely with what erlang expects. I messed around with making erlang code and python code communicate using erl_interface and the code to handle messages pretty much devolved into "have a running middleman process that invokes erl_interface utilities in python via a cffi wrapper, then finally call your actual python code." Some library may exist or could be written to help with that, but it's a lot when you just wanna invoke some function elsewhere. I also have not tried using port drivers, the experience may be a bit different there.
Yeah, NIFs are dynamically linked into the running VM, and generally speaking, if you load a binary library, you can do whatever, including crashing the VM.
BEAM has 4 ways to closely integrate with native code: NIFs, linked in ports, OS process ports (fork/ecommunicate over a pipe), and foreign nodes (C Nodes). You can also integrate through normal networking or pipes too. Everything has plusses and minusses.
Yeah, a NIF can bring down the entire OS process but I've used quite a bit of Rust NIFs with Elixir and never once had a crash. With Rust you can make sure nothing ever goes down, minus stuff that's completely out of your control of course (like a driver crash).
Think of it more like "why is it important to have Spanish as an option for captions in an area that knows it has a large audience of L1 Spanish speakers?". English/<insert dominant local language> is pretty much a foreign language to many signers. Their native language is ASL or whatever other sign language they know, and these languages aren't just 1:1 mappings of words in the local dominant language to hand signals. They have many dimensions of expression for encoding meaning like facial expression/body motions, speed of the sign, amount of times they repeat the sign that have grammatical meaning that spoken languages express with inflection (noun cases, different verb forms) or additional words. For example, where an English speaker would use words like "very" or "extremely" or choose adjectives with more intense connotations an ASL signer would repeat or exaggerate the sign they want to emphasize (often by signing it more quickly, but it frequently involves intensifying multiple parts of the sign like the entire motion or the facial expression as well).
> For example, where an English speaker would use words like "very" or "extremely" or choose adjectives with more intense connotations an ASL signer would repeat or exaggerate the sign they want to emphasize
小小比小更小
大大比大更大
If you search for "a big big guy", you'll find no end of English examples, either. I would be surprised if any language didn't use repetition for emphasis.
Strong preference for backend work, but I am open to full stack work that leans backend. I have a particular interest in working with BEAM languages (erlang, elixir) if anyone using those in their stack is looking for devs.
I can confirm I've encountered this as well. In our case it was with shopify. There are some product_* tables that cannot be turned off without turning off product entirely and they can be incredibly expensive to sync. It's a very poor experience compared to something like airbyte where you pretty much get full control and can even edit the connectors if you have the dev manpower. The fact that adding new tables to your schema is on by default also really rubs me the wrong way. If you don't disable this or very closely monitor what new tables get added a reasonable connector can suddenly balloon in costs.
