I am often shocked how poor language support for paralelism is.
Sorbets asnc/await make writing that kind of code a breeze. Python and Java are much less ergonomic for this. Might have improved with the newest Java versions, but I did not try that yet.
I was part of preparing an offer a few weeks ago. The customer prepared a lot of documents for us - maybe 100 pages on total. Boss insisted on using chatgpt to summarize this stuff and read only the summary. I did a loner, slower, reading and cought on some topics chatgpt outright dropped. Our offer was based on the summary - and fell through because we missed these nuances.
But hey, boss did not read as much as previously...
Yep.
Also, js is easy to iterate on - it's more lenient than rust or say c#. Especially if you are exploring thinks, that's a huge boon.
Obviously, for the same algorithm, compiled languages will be slower. Does it matter? Maybe. But time to find this algorithm is also critical - and if js helps here, it's a good choice.
A friend of mine has near PTSD from watching some movie over and over and over at a optician where she worked. Was on rotation so that their customers could gauge their eyesight.
There is nothing.
Oh sure there is include, but that's like most gitlab features: it marks a nice shiny checkbox in some management presentation. But usefulness in the real world is limited.
But hey let's do secops oh no AI instead!
There are lots of problems.
Actions try to abstract the script away and give you a consistent experience and, must crucially, allow sharing. Because gitlab has no real way to share actions or workflows (I can do yaml include, but come on that sucks even harder than actions) you are constantly reinventing the wheel.
That's ok if all you do is " build folder" but if you need caching, reporting of issues, code coverage etc. Pp it gets real ugly really fast.
Example: yesterday I tried services, i.e. starting up some DB and backend containers to run integration tests against. Unfortunately, you cannot expand dynamic variables (set by previous containers) but are limited to already set bars. So back to docker compose...and the gitlab pipelines are chock full of such weird limitations
I always felt that Prolog is a super valuable dsl that I would wish to be embedded like a reflex for certain problems, but is I'll suited for most programming tasks.
I.e. have the GUI, Io etc. in language better suited to that.
Yes, that is missing. I thought about creating something like that, but it's a lot of work.
Also, the huge number of source generators have a problem: a SG cannot see code generated by a another sg. There is no ability to stack them. That will be a problem as more and more sg's generate source. E.g. I have a SG which creates interfaces. No other sg can use these interfaces.
Ha?
Can you give an example? I've seen lots of perfectly good stack traces in async code - no problems at all.
Pausing code also works, at least using vs or rider.
Here in Germany wolves return to many parts of the country. And there is lots of resistance. There are regular sob-stories how wolves hunted poor cuddly niece lambs and how their owners are now scarred for life and will quit their jobs.
There is financial compensation and also guidance on how to build secure fences, but the big bad wolv is scary...
It's not only about breakaway people. An appropriate political systems promotes centralism and punishes extremism - but FPTP combined with your loose candidate selection process does the opposite.
There is a large body of studies discussing optimal forms of democracy for newly established ones. The guidebook essentially recommends doing the exact opposite of what are you doing.
Your problem is a structural crisis. You would need a reform of your voting system to effect a stabilization of the political system, o.e. abolish fptp and gerrymandering. I don't see that happen.
So you are fucked.
It's okay. We are forced ( by our client, who has forgotten to update it's it since 2005 ) to start several clients in a pipeline. Startup is less than a minute, going from zero to a full resource group with two VMS and ancillary resources.
I have added a few. The last one starts with CTHUlHU FHTAGN for a godforsaken piece of shit software which I try to automate for e2e testing. Cannot use docker, because that thing has workflows where I need to click the UI. Also, the workflow is terribly unintuitive and convuluted. The packet script therefore has three breakpoints where I have to log in to the VM and click stuff
My problem is that I always use git as a central server. Except that one time when our internal git was down and we used it peer to peer for a day. Honestly, using USB sticks for that would also have been okay.
It basically allows to express queries independent of the target language. E.g. it's entirely possible that the same LINQ query can target PG, MSSQL Server, objects in local memory or RavenDB (NoSql). Quality of the generated query depends on the translating library ofc.
Syntax is very nice and much more aligned with programming than SQL.
E.g:
someData.Where(x => x.id =="someId").OrderBy(x => x.LastModified).Take(10).ToListAsync()
Note that the query is not executed until ToListAsync (or other materializing calls) is called. This allows for composabillity.
There is an alternative form of writing it more resembling SQL, but I've never seen it much used.
We maintain a few number of projects for clients - the apps are feature complete and will not change much in the next years. The goal here is to spend not much money on the apps but to keep them functional in the appstore.
RN is somewhat cheaper up fron than native development or say flutter. Unfortunately, maintenance cost is high and difficult to predict.
Why?
Appstores are adding new requirements and increase API-level all the time. Support for that is often baked into new RN versions. Unfortunately, new RN versions often break things, which break libraries in turn. So you need to upgrade this morass and if you are unlucky, you need to redevelop huge swaths of your app because the lib now is deprecated /works differently / will never be updated to the new RN version.
Yes, but what's about the components controlling speed, e.g. by detecting the speed limit from some map? Or the stuff implementing emergency calls?
Also there is a plethora of features I (charging station maps) which probably need all maintenance, too.
I am mostly concerned by the ongoing maintenance cost of software. Cars live 20,30 years - how to keep the software running and in good condition?
Foss is no solution, especially due to regulations (totally warranted, I want your car to have working braking systems...) and that this also involves systems at the producers.
C# has unsafe, which extremely powerful. See ravens repo for heavy usage of that.
Otherwise python is also a good example of that. First start out in python. Not fast enough? Bring in python, which compiles down to c. Id that's not enough, drop to raw c.
Yes, but currently that's always the most expensive option.
I am driving a lot from Cologne to Bremerhaven. Depending on the spot where I stop, I would need an EWE, EnBW, Aral, ionity, eon, shell or some smaller card to get somewhat reasonable prices. Annoying.
Where Europe dropped the ball is not forcing gas station like behaviour onto the chargers. Now we have a bazillion different charging cards and prices differ wildly depending on the Tarif.
I think the Windows event log works like this. Sadly it's very opaque and difficult to use for non admin apps (you need admin rights to install your logs for the first time. Afterwards you can run with less privileges.)
It's normal to Google "how to do x in gitlab" and then there is a ticker in their issue tracker to add x from 2018. GL employees all agrees that it would be great. Thrn there are 374747 label changes and no resolution until today.
Haha good catch.
I actually did some dsa campaigns inspired by these caves. They are super still, cold and eerie. Most of the shafts are filled today but you can see how dangerous they where. Small steps, without any guardrails, often slippery because water leaks in die to cracks in the rock. Also, many caverns are big, because they excavated the stone but the access tunnels are super small and steep.
It's even worse when you scan your build artifacts, in our case containers. Each build added to the list , with no way to delete all stuff. Filtering and grouping are also missing.
We gave up on that and decided to use another tool.
My gripe with GL is that all features are like this now. There is no invest into the basic building blocks, just yapping for the next trend. Most customers for GL use it on premise because they want to use it on prem. I would focus on Features that benefit that crowd, but hey I am just an developing not a gilded c suite.