chpmrc

I have a really hard time working for someone who isn't technical, regardless of their role. I also have a hard time buying into the narrative that someone can be just a good manager.

As an engineer and a manager I took my time to understand the basics of management, design, marketing, business development etc. to have educated conversations while building a product so I don't see why someone in those roles shouldn't do the same.

I would also feel the need to catch up with whoever the best engineer seems to be on my team because I'd just assume they wouldn't respect me if they perceived me to be vastly less competent (a degree of technical incompetence can be offset by good soft skills of course).

Either there's a misconception about how complex "technical" stuff is, that prevents those (smart) people from touching it with a 10 foot pole, or (conventionally) technical stuff is indeed more complex than (conventionally) non technical stuff.

I lean more towards the latter (after all market demand and compensation are a good indicator of that) but I'd be very happy to be shown that's not the case. I know plenty of engineers that are successful "solopreneurs", I don't know anyone who isn't technical and managed to do the same without a technical cofounder.

Not claiming "engineering is easier than marketing", just that, on average, technical people can do 80% of what's required to build and launch a product, non technical people can do around 20% (although the ratio might change once these no code tools become more popular / powerful).

Why? The language is great, it's the runtime that needs some work. We have bun because someone thought kind of the same thing about Javascript and decided to improve the runtime rather than to learn Rust.

The 1 man company doesn't have deep enough pockets to actually repay damages and can easily declare bankruptcy.

The premise is that you don't want to audit the source. It's extremely costly and you end up doing it for every update.

Let's say there's a higher chance that you'll be able to sign a contract with Google or Microsoft that allows you to sue the $$$ out of them if something happens, than hoping to get anything from ankitpokhrel on GitHub whose bio says "I have no idea what I do".

(Nothing against ankitpokhrel and this great tool, just making a point in a slightly sarcastic way)

> My problem with Kubernetes is my problem with with front-end web frameworks - they introduce too much complexity to the point of being esoteric for simple systems.

I used to think the exact same thing but came to the realization that the complexity doesn't come from the tools, it comes from the people who misuse them.

Having a set of basic config files for Kubernetes is very easy, there are a few concepts to understand but it's something anyone can learn in a matter of hours (images, containers/pods, deployments, services, volumes and ingress) and the power of abstracting your whole infrastructure in a bunch of reusable YAML lines is pretty damn cool.

The same goes for things like React, once you understand the basic semantic blocks (components, props, state and more recently effects) you're 80% of the way there.

Problems arise when the "I'm so smart and look what I can do!" kind of dev starts telling you that using basic boilerplate is not good enough and that you should specify all the optional values as well because "cOnTrOl", or that `create-react-app` is not good enough because "you don't really understand what happens behind the scene", but guess what? I don't care what happens behind the scenes, the same way I don't care what cc and ld do to compile and link my C code. `create-react-app` is more than enough for 99% of production grade apps.

Problems arise when frontend devs need (or feel the need) to become experts in the build systems (one of the reasons why bun has become popular so quickly, standardized, included build system) or to introduce unnecessarily verbose conventions.

There are two keywords in your comment that perfectly describe what I'm talking about: "Webpack" and "big pile of configuration files". Neither of those things are necessary when using K8s or React.

It's overzealous devs who think micro-optimizing 5 ms off of the build process is worth writing 15 more YAML files that contribute to this false sense of "complexity". But when you think about how much you need to write in K8s (for most SQL DB backed web APIs we're talking about 3/4 files of 10 lines each) vs what you get in return (you can spin up a 1:1 copy of your entire infrastructure in a few seconds on any K8s compatible cluster, without worrying about the underlying hardware, to an extent) the tradeoff is clearly in favor of using it.

As an example I'm working on a project where if I needed another worker I could just add a few lines to the K8s configuration, commit, push and magically have that worker up and running in the cluster in no time. Whereas traditionally you'd have to contact someone from the infra team, specify the characteristics of the machine, operating system, set it up, connect it to the network etc. with K8s everything is handled in those few files. IMO it's better than magic.

> I can think of several ways the language could've been designed to make it easier to write typed query builders.

Would you like to share them? Have you tried submitting your suggestions to the GraphQL core team?

This is just a wrapper for SQL, every language has one. The same is true for GraphQL, I've never written a GraphQL scema or query by hand, always used a good wrapper that handled all the type safety I needed. Constructing GQL queries manually is the equivalent of doing it with SQL.

At this point I'm pretty sure you're conflating the underlying technology with what a wrapper could do on top of it. And in that regard I absolutely agree with you: raw GraphQL doesn't make any sense, the same way raw SQL (in 2022) doesn't make sense either.

EDIT (mandatory before I get lynched lol): except in cases where the wrapper builds a query that is inefficient or should be tweaked manually.

I'm not familiar with LINQ and even though it might be a good solution we're not debating GraphQL vs LINQ (which, as far as I can tell, is specific to C#, at least its reference implementation), I'm questioning your "string is bad" statement which, IMHO, doesn't make any sense.

Well, GraphQL aside I've been using the same stack for almost ten years and it's only becoming more and more popular so I'd say I'm doing pretty well in terms of choosing the tech, thanks for your concern though!

Calling SQL crap just because there's a way to abuse it is like saying C is crap because I could do `int * userGuess = get_number_from_user(); * userGuess;` with nothing more than a compiler warning (if I'm lucky).

Would be nice if we all stopped with these blanket statements and just focused on evaluating individual pros/cons of things.

EDIT: formatting of pointer

> It is actually a pain to use, depending on the backend you are using you'll have to manage two or more type systems if there are no code first generates in your language

This is a shortcoming of the language, not of GraphQL.

> It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be

If you ever tried to cram a JSON like payload in a GraphQL field you'll know why this limitation is in place. It quickly starts getting abused by clients and you end up adding validation, which you might as well have codified in a properly structured type. For blobs you can just send encoded strings (JSON, base64, binary, you choose).

> No clear path for Api versioning you'll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03

The whole point of using something like GraphQL is that you don't need or even want versioning. You can still deprecate fields (and remove them according to your deprecation policy) but in general you can just keep adding fields/types without removing the old ones until you are sure consumers don't need them any more. So there's no breaking change and consumers can transition to the new fields whenever they want. Something else you start appreciating when you have multiple, heterogeneous consumers of your API.

Or you can just add the version to your schema URL, e.g. `/graphql/v1/` and then route your queries based on that, which kind of defeats the purpose.

> Invest your time in a simpler solution then running to GraphQL first

GraphQL is as simple to set up as anything else, assuming the language has good support for it. If it doesn't that's, again, a limitation of the language, not of GraphQL.

GraphQL solves a ton of problems related to typical JSON APIs' conventions, since JSON isn't inherently "schemable" unless you generate something like an OpenAPI spec which is, arguably, more complicated. There might be superior alternatives (I've never tried JSON schema) but I think all the pain points you described can be easily solved one way or another.

Your argument stops being valid the second you realize that a lot of devs who use GraphQL started out as skeptics (e.g. me), then spent time actually understanding its nuances before coming to a conclusion for a specific project/team.

And, in general, there's no such thing as a "good" or a "bad" technology, there are dimensions and each dimension is a spectrum: utility, adoption, availability, cost, complexity (although hard to determine), etc. to compress all that down to "hype" or "it sucks" just show how little time has been spent on understanding the nuances I mentioned above.

I don't claim GraphQL is amazing or even good, it just proved to be a great way to build APIs for the projects I worked on. I'm sure someone who builds firmwares for embedded automated plumbing systems would disagree (within that context). If you decide not to adopt it I just hope you do it after a rational, unbiased review of what the tech is capable of and what the shortcomings are, rather than "oh it's over hyped".

> Did you try reading the thread? What do you mean by data?

Please don't question whether someone read the thread or not (which is irrelevant within the scope of this discussion anyway) just because they disagree with you.

> yet since no thought was put into how it might integrate into existing typed languages [...]

Says who?

> [...] its actually surprisingly difficult to build a type-safe API around it.

Again, says who? The consumers of the APIs I work on are mostly written in Typescript and constructing types based on the GraphQL schema is a completely automated process. Are you telling me that it's easier to build type safe APIs based on examples of what JSON each endpoint might output?

> And yes, SQL is "bad" because you write query strings

Ok then every single language is bad because every language's syntax is based on (conceptually) constructing strings. I don't get your point.

> Graphql is a terrible piece of software/paradigm.

Says who, exactly? What data are you basing this on? Or is it a completely subjective opinion dictated by frustration likely caused by the lack of understanding of it?

> Be careful with anyone with a take that says some technology is 100% bad always.

THIS 100%.

> It takes very high skill to use GraphQL well. But if you pull it off it can be an incredibly productive system that is friendly to integration and refactoring.

I could not agree more. It's like any other piece of tech: once you internalize the mental model and are able to translate those abstractions in your language of choice everything clicks. And then it's hard to imagine going back to something more "primitive" (i.e. what's conventionally called "REST").

After building "RESTful" APIs for years I can confidently say GraphQL (with a decent implementation) is a step up across almost every possible dimension (performance aside because of the additional parsing).

> I was appalled that in this day and age, this hyped silver bullet basically requires me to build queries using strings.

That's like saying SQL is crap because you need to build queries by hand. Conflating a protocol/spec with its implementation and/or the way it's used is not something a "very senior dev" should do (not questioning you personally, just the validity of what you wrote in this specific comment).

There are plenty of good GraphQL libraries that make writing queries/mutations and the whole schema a breeze. I've been using graphene for Python for a couple of years and, although it has some rough edges, it's actually pretty decent. And GraphQL is quite a good mental model to work with that both backend and frontend can share.

<rant>Honestly I'm getting tired of seeing these comments on HN, it's the same for Kubernetes or other technologies. Often written by someone who didn't take the time to actually study and understand the tech and use it for actual projects. Often with no data to back it up whatsoever. The quality of posts and comments here used to be a lot higher but it's slowly turning into a plaintext version of dev.to </rant>

I've recently switched to iPhone and this thread is so comforting. My friends thought I was insane when I told them that typing on Android (Samsung or Google keyboard) is much more accurate, fast and way less prone to errors (using autocorrect) than on an iPhone. And that's not even counting swipe mode! The difference is huge.

I don't understand, are you saying async is hard or that a poor implementation is a source of issues (e.g. async function that calls sync primitives)? Because I totally agree with the latter but I have no idea what "hard" means. Very little changes in terms of syntax (assuming support for async/await ops) or reasoning.

This 1000x. It's such a slippery slope that you'd think by now most people would be aware but no, there's always the "who needs an ORM" guy :)

Why would you block a process that could use CPU cycles to do something useful just to wait on I/O? With the right primitives async is not "hard" nor inconvenient. Maybe you're referring to concurrency?

If I had a dollar for every time I heard this I would be having lunch with Jeff Bezos right now.

If anyone is looking for a great VR multiplayer game with original mechanics, I highly recommend Hyper Dash: https://www.oculus.com/experiences/quest/3070239359662935/

Sounds like someone is making assumptions on the way I work :) As a matter of fact I have and the solution is pyenv. Node has a similar utility called n.

- Poetry is a 3rd party package manager, I'm sure it's great but it's not widely used (yet)

- Pip freeze just pins all dependencies at once to requirements.txt

- I don't know what "vendoring in dependency code" means

- I've never used pipreqs in my life (and 80% of my work has been in Python)

- Virtualenvs are just a convenient way to keep project runtimes separated

And for 90% of Python projects in existence the following is sufficient (assuming Python3 is installed):

- python -m venv .venv

- source .venv/bin/activate

- pip install -r requirements.txt

That's it. And all of that requires a single dependency: Python. Could it be better? Sure. But to call that a "mess" is an exaggeration.

"As someone who codes", as if 80%+ of HN user base wasn't coders. Also you can make a screen matte with a screen filter (they are not just good for privacy).

I feel like most of these articles would lose their click bait appeal if the title always included "when done wrong" at the end.

It doesn't matter where the employer/client is located. Income is taxed _where the work is performed_. If you work in Indonesia that's where your income will be taxed.

"Business profits" are different, since they are generally regarded as dividends distributed to shareholders who (in theory) don't "do work" for the company.

“Tax free” is deceptive, if it’s only referred to foreign sourced income. Income from any work is considered sourced where the work is performed, so this would only apply to foreign passive income (e.g. dividends or capital gains). And I’m not familiar with CFC-like rules in Indonesia but I guess they also apply some kind of economic substance requirement for a tax resident to own a company incorporated somewhere else and whose only purpose isn’t tax optimization.

> I own the copyright to it

Copyright is only valid in specific (sometimes geographically limited) legal frameworks and even then there are many nuances to take into account.

NFTs are just an easier way to establish ownership within the digital world, regardless of the chain (because of the timestamp I mentioned, since it can obviously be compared across chains).

> nobody's claiming that a RedBubble shop is a definite proof of provenance

RedBubble, being centralized, cannot be trusted to be a viable proof of provenance due to the possibility of corruption.

NFTs don't give anyone any right, they just make it easier to establish (and automate the process of verifying) ownership of a digital piece of content. They are not a replacement for copyright. Practically speaking you have two choices: you only claim copyright on some content, get mad when someone mints an NFT of it, try to identify and sue them (good luck with that) and waste time and money OR you mint an NFT as soon as you decide to publish your work.

There is absolutely no incentive in choosing the first option and if you do, well, that's on you.