elevader

I'm not sure if this is what you are looking for but I found https://github.com/wolfpld/tracy to work rather well. There is an integration for the tracing crate that can get you very far: https://lib.rs/crates/tracing-tracy. If you're just looking for a very high level report then this might be a bit too much detail.

I can only really talk about Germany here, the perspective might be different in other countries. The big challenge is the large number of people coming in, both from legal and illegal immigration. Our system simply can't deal with it. Ideally you would get these people out of the asylum centers (might be the wrong term, no idea) and into jobs so they can actually start living and integrating here. But the harsh reality is that people are stuck for years, waiting for the approval process to happen at some point, and they aren't even allowed to do something useful in the meantime. This, unsurprisingly, creates a lot of tension on all sides and doesn't help anybody. Lowering the numbers might not be the best solution but at least that seems doable.

I have the "honor" of getting to use IBM $PRODUCT at $COMPANY.

- it uses some form of consensus algorithm between all nodes that somehow manages to randomly get the whole cluster into a non working state by simply existing, requiring manual reboots

- Patches randomly introduce new features, often times with breaking changes to current behaviour

- Patches tend to break random different things and even the patches for those patches often don't work

- For some reason the process how to apply updates randomly changes between every couple of patches, making automation all but impossible

- the support doesn't know how $PRODUCT works, which leads to us explaining to them how it actually does things

- It is ridiculously expensive, both in hardware and licensing costs

All of this has been going on for years without any signs of improvement for now, to the point that $COMPANY now avoids IBM if at all possible

Your starter kit inspired me to finally bite the bullet and write my own emacs config from scratch instead of using doom. I'm not sure yet if I'm thankful for that, time will tell ;)

I'd guess it's similar to a job in the entertainment industry, like being a host of a TV show. You won't get very far by just sitting there playing some games, you have to be entertaining, engage with the audience, provide commentary etc. And do all of this with a happy face/mood for 6-12 hours, preferably every single day. And when you're not streaming you most likely do social media stuff.

I know of a streamer who got "big" (enough to earn a living) by playing factorio. At some point he burnt out on the game and tried different things but his audience didn't really care for that and income broke down substantially, so it wasn't sustainable anymore. So he continued playing factorio without actually enjoying that so that he could make a living for his family. Just like a "real" job.

This might be a "person in a country with pretty fast internet connection" opinion but I don't think I ever had that issue. Might also depend on the container size, pushing > 1GB containers might be more error prone than pushing small(ish) containers.

While this is definitely a valid option I'm not sure that introducing Nix/Guix simplifies the stack compared to using Docker. Depends on the setup and experience, I guess.

Why would you assume that these are fakes? There are fan translations for the game (a quick google search would bring this up) and you can download savefiles for Magnasanti. Maybe the person simply recreated the Screenshots with their russian client? Seems a lot easier to me.

I don’t wanna be callous but on a scale of 0=I stubbed my toe and 10=children are starving in [insert location] this seems to be a -3.

Not sure what we are measuring here but the issue of this particular article annoying you seems like a -25 by comparison, so maybe just ignore it?

That's not really great advice either, temporary solutions/workarounds have a tendency of sticking around permanently.

The net benefit of using the "separate processes using IPC" model lies in the fact that the language used is an implementation detail that editors/IDEs don't have to care about. Want to write your Rust Language Server in Rust? Fine. Want to write it in Kotlin? Also fine. Your editor is written in JS? Cool. Elisp also works. This wouldn't really work so well if LSPs were some sort of library. IntelliJ plugins are great (if they exist) but they are inherently limited to their own ecosystem, nobody outside of that benefits from that. LSP sure isn't perfect but it is a hell of a lot better than the situation we had before it. If IntelliJ works well for you then that option is always there and hopefully here to stay, all power to you. But not everybody wants that.

AFAIK it can. They actually spent quite a considerable amount of effort implementing all of the gcc extensions to do so. There is even documentation for that: https://www.kernel.org/doc/html/latest/kbuild/llvm.html

Should have specified that more, sorry for that. Webpack, for better or worse, has most of the current dev mindshare and tons of plugins, stackoverflow questions & random blog posts. If you need some integration for <fancy thing>, your chance of finding something working for webpack is far higher. You can build/support everything with gulp just fine if you don't want to use webpack, the question is: Why exactly would you specifically choose gulp and not, for example, esbuild?

I might be getting that question totally wrong, but faced with the question of "would you use gulp for a new project" my answer would also be "no", altough I think that gulp is a nice and totally workable tool.

The thing is that gulp doesn't really have all that much to offer these days. If you need lots of complex build logic webpack is the way to go. If simple & fast is the desired goal then something like esbuild or swc do a much better job, especially in the "fast" section.

And if none of these tools are what you want you could always use make (and bazel would also be possible I think, not sure though). Or maybe just plain tsc is enough.

And the GDPR forbids them from writing that information (e.g. "the privacy nut bought apple juice") down or passing it to a third party without your explicit consent.

GDPR also applies to the real world. That store is definitely not allowed to share data about your shopping habits with some third party without your explicit consent. For example government departments in Germany have to aks for your explicit permission beforehand if they need to request/share data with a different department.

I think this is akin to the general problem people face when trying to convey why Haskell (or a Haskell-like library) is useful/awesome to them to a target audience that isn't already familiar with the subject. Simple and straightforward examples struggle to show any benefits that generalizations could/would provide. Complex examples are hard to explain without loosing most of the audience in terminology they don't understand. Or they just go on for way too long because they constantly drift off into explanations that don't really move the overarching subject forward.

That's classical victim blaming. We are all humans and make mistakes.Some mistakes only result in some property damage or money lost and some, like running over a person (doesn't even have to be a child, don't forget that there are handicapped people who might not be able to react fast enough to get out of that situation), can't be corrected afterwards. Handwaving that away because some people like to save a few dollars is not a great idea.

By your logic we could also hand everybody heroin and an assault rifle and abolish most laws, people watch TV after all and therefore can be taught not to do bad things.

I'm not sure about this. Maybe the example is way too simple but, as the author stated, this can be easily done with already established patterns in Elixir so I don't really see the point/benefit of this. If you want to learn more about working in a Haskell-style there is always Haskell (as is said at the end of the article).

But it is a well written article and easy to follow, so I guess it achieves its goals.

Hardware failure is extremely relevant if that hardware is the drive you store your private key on,at which point the wallet is gone forever. One could say "don't do that, have elaborate backup strategies" but that brings us back to UX. Even professionals who should know better tend to be awful at this.

Not a lawyer as well but I'm not sure about this. Let's use the "jQuery served by a CDN" example here: You can easily argue that using jQuery is necessary for your site to function but there is no real benefit to the user by doing this with a CDN when you could just ship jQuery from your own server. AFAIK the benefit of CDNs is largely nullified nowadays by browsers using a different cache for each primary domain anyways, so you can't even really point out a potential benefit for the user (faster load times) here.

There is an important point to this ruling that shouldn't be omitted:

Der Einsatz von Schriftartendiensten wie Google Fonts kann nicht auf Art. 6 Abs. 1 S.1 lit. f DSGVO gestützt werden, da der Einsatz der Schriftarten auch möglich ist, ohne dass eine Verbindung von Besuchern zu Google Servern hergestellt werden muss.

To roughly translate: One can use Google Fonts without forcing users to make a request to google servers (by downloading the fonts and serving them locally) so this doesn't fall under GDPR (which allows sharing/using user data if it is necessary for functionality).

Which would most likely include CDNs but a point could be made for things like youtube and twitch where that isn't really possible/feasible.

Edit: One addition to the "necessary" part: Necessary for what the USER wants to do when visiting your site. Might be arguing semantics but this is law after all, which is all about semantics

except it is, WASM is designed to be AOT compiled to native code.

Interesting, I didn't know that. How does WASM handle different architectures? Do you build different binaries for x86/arm? Or does it do it the Apple way with the giant bundle that contains all binaries?

Now Unity is so much more then just a tool to make cross platform easier. So comparing it to WASM is kinda pointless IMHO. Though it probably is a grate choice for any extension mechanism, like mods or even in game scripting.

Agreed, that was badly worded. Like you said, one could compare a module written in Unity and compiled to whatever Unity compiles to/is implemented in these days with a module in WASM.

Edit: Or does the AOT mean that the format that is shipped is some non-native format but the client compiles everything before the first run?

AFAIK you don't really get native performance, although it's hard to find good data on this (https://nickb.dev/blog/wasm-and-native-node-module-performan... was one I could find on the fly). WASM is still virtual machine based and not compiled to a native executable so this is to be expected I guess, it's supposed to be faster than JS and it achieves that goal. Maybe it can be an alternative to Unity, which would be good enough for a lot of games, but I don't know how that compares.

Yeah, agreed. Ideally this wouldn't happen like that. Temporary solutions like a half-migration have a tendency to stick around for a lot longer than anybody anticipates. But I think it is still better than not having any types at all, if only for having type information in development.

I don't think that example would compile in TS either (not 100% confident though). The "issue" with TS is that everything type related completely disappears after the build step and that needs to be kept in mind in development. Some developers struggle with that, especially at the boundaries to external APIs/libs/whatever.

You actually don't, that's the nice part. NPM Typescript modules are shipped as transpiled js modules with d.ts files. Those d.ts files contain the type informations for consuming TS projects but they are completely optional and you can simply ignore them if you write a plain js project.

You can see this in the babel project, for example. It is written in typescript but used by a lot of js projects that don't care (and don't have to care) about this.

And it works in both directions. You can "easily" (I mean, this is JS afterall so this heavily depends on the degree of toolchain hell chosen) move to the TS toolchain and rename your files to have the .ts extension and you have a valid TS project and benefit from the inferred types for your code. Type annotations can then be added later on as you go. And the syntax everybody already knows stays valid. This is a huge benefit compared to something like ReScript because it makes adoption really easy. With the obvious downside of not having nice features like pattern matching.

Despite requiring very verbose type annotations, TypeScript does not have a sound type system, meaning it does not guarantee the absence of type-related errors in runtime even if everything compiles fine.

Does ReScript solve that? If so, how? In my experience this is mostly an issue with data/functions coming from outside sources (Return values from HTTP calls to endpoints you don't control being a big culprit). Sure, you can write type definitions for that but that doesn't mean anything unless everything is manually validated/checked at runtime as nothing really guarantees that the type definitions are actually correct. Does ReScript handle that automatically?

The reference implementation is written in Javascript and I don't think that provides a reliable way to get timestamps this fine grained.