What difference does the runtime make to the (average) end user? I love that I can create shortcuts of some web apps that have their own window, menu bar etc. (this is already possible in Chrome) and I don't really care they are "web" apps.
That has nothing to do with the runtime, rather with the implementation. Barrier to entry of web development is low so average quality is also low. On the opposite side of the spectrum you have products like Figma, Notion, Google apps etc.
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).
i worked for a non technical manager, and it was ok. because he trusted his employees. he said this is the deliverable, and these are the constraints, what do you need, who do you need, and how much do you need. we told him, and he went to fucking bat. obviously he picked up a little here and there, but by no means could do the job of a junior.
it worked well, he shielded us from the corporate politics, got us everything we needed, didn't over commit us, and we delivered on estimated dates and to scope almost every time. because we picked times and materials and he made sure it happened and that we could focus. was good times
Totally agree there's no hard and fast rules here. That said, this person probably lucked out with a dependable team, and no doubt relied on intra-leadership (from yourself or peers I would assume!) to manage - and deliver - effectively. This kind of dependability doesn't usually appear out of thin air. It's also a bit of a catch 22 to replicate.
I've worked with similar people and there is definitely a place for them (tho probably not at the peak of the structure). But it's also nice to have someone that can critically discuss a solution and sign off on decisions that they fully understand. IMO.
If you're someone who has pride in their work, you should want to learn. Technical curiosity is invaluable in this field and it seems odd that there are people who insist on sticking around despite lacking it.
I don't think a lack of technical curiosity/professional pride is exclusive to managerial types, but there is a surprising number of people who hate the technical side but still want to be bossman.
> I have a really hard time working for someone who isn't technical, regardless of their role.
In both cases — technical manager and non-technical manager — the engineering culture at the organisation ultimately determines whether the arrangement is successful.
In the past I’ve experienced friction working for a manager who had different ideas about how particular technical problems should be addressed.
> 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.
I agree, but in my case I think there's also a "narrow band" for what I'd consider a technical manager to be. I want them to be able to understand if, at times, I need to get into the weeds describing a technical problem. I wouldn't do this often; I don't think it's necessary or useful to burden a manager with deep technical details most of the time. But I want it to be possible to do that when necessary, without seeing the manager's eyes glaze over.
But at the same time, I also want a manager who is primarily focused on the "people" aspects of management. Engineering managers should not be coding, or even doing code reviews. Part of it is because I don't believe managers should be in so deep on the technical details, because to do so means taking too much valuable time from people management duties. But the other bit is that I don't like the power dynamic. I don't want a manager to force -- or even have the unconscious appearance of forcing -- a report to change some code in a code review because they have the added "I'm the guy who decides if you still have a job" power. And in the reverse interaction, if the manager is writing code, I don't want their reports to have to walk any kind of "don't piss off the boss" tightrope when providing code review feedback.
The power dynamic bit is a reason why I also think that a team's technical lead (for orgs that have tech leads) shouldn't report to the team's manager, but should report up a level. I think it's valuable if the technical lead feels like they can argue against the team's manager's opinions without being afraid of (even unconscious) retaliation.
So I think it's hard. Another top-poster here (the CTO of Surescripts) seems to have it right: when he's at work, he focuses on people and the business, with the technology an important part of the job that he doesn't dive too deeply into (but can still hold his own in technical discussions). And he keeps his technical/engineer side happy through deeply technical side projects on his own time. I think that can be really hard to do, especially for an former developer who is new at the manager job. (Not to mention having deeply technical hobbies and side projects takes up a lot of spare time, spare time that many people may not have.) But I think it's essential for having a healthy team with reports who respect their manager, and understand that the manager respects their technical expertise, and doesn't try to dictate technical decisions.
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.
I'd be interested in hearing from others, but I wonder what differences there are for optimizing JS vs Python. A few things come to mind:
1. Python has a ton of C code in its libraries/stdlib, JS did not have that for the vast majority of its usage (browser). Optimizing across the FFI boundary seems unlikely to be a reasonable goal and may complicate optimization opportunity. Let's say you want to do some sort of optimization pass to make sure that `str.append` is not getting overridden - how are you going to handle native code?
2. Python is obscenely dynamic. Runtime generation of classes is not uncommon at all - for example, `@dataclass(slots=True)` creates an entirely new class.
You can overwrite methods, functions, there's heavy use of globals in libraries, no such thing as private implementations, hooks into everything, even importing code has side effects so you can't reorder or lazily import automatically, even reordering imports is unsafe in Python.
It seems really hard to optimize Python at all, and I wonder if we could ever reasonably expect to see a "V8-like" runtime, even assuming that there's funding, which I also doubt. Unless you're willing to break the language I just don't see a Python runtime overcoming these issues. Or introduce something like 'strict' where these things aren't possible.
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)
It's open source. If you want to use the functionality but don't trust a random internet user named ankitpokhrel, you can literally gut the project, copy-paste the code you understand, get basic functionality to work, and you can be pretty much certain that there is nothing nefarious going on.
I have done that multiple times. It's not very time demanding, because the working code is there, and all you're doing is essentially deleting code you either don't understand, or don't need. At the same time, you're reading the code you do use.
And imagine yourself in the IT guys shoes. Some rando expects you to audit something that at most one or two people use and probably contains a hundred vulns which would very likely never be fixed anyways. Why would you bother with such a request
I would bet it's easier to do it with a 1 man company, the megacorps are famous for firewalling themselves from liability with very good contract lawyers.
You may also be able to get 3rd party insurance for this.
> 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.
> 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.
> 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?
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.
> 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).
> 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.
While this is true, I think the ultimate assesment of a technology is how easy is it for someone skilled at doing similar work to internalize the model and abstractions.
A tech stack can become really successful only if this is easy and relatively quick, otherwise, it will meet a lot of resistance. Partly because it's hard to master, but partly because so many people will be misusing it (which makes an even bigger annoyance for someone who's trying to get to a proper mental model).
As such, I've come to appreciate only models that majority of developers can easily get right on the first go: or rather, models which are hard to get wrong.
> 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>
The GP is right. GraphQL is especially annoying because it looks so close to JS/JSON, yet since no thought was put into how it might integrate into existing typed languages its actually surprisingly difficult to build a type-safe API around it.
And yes, SQL is "bad" because you write query strings. The funny bit is that GraphQL may be just as hard to model in a type-safe way as SQL is, if not a little harder. At least with SQL we have a reasonably good way to model it with methods (see LINQ). LINQ was built 15 years ago, so this problem was well understood back then.
> 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.
Says me, and also any other person that has tried to build a type-safe GraphQL query builder
> 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
Constructing "types" of what kind, and in what way? Types for queries? Do you need to rerun the tool every time you modify any of your queries? Does it need to watch your query strings to generate the right types for them?
> Ok then every single language is bad because every language's syntax is based on (conceptually) constructing strings. I don't get your point.
Instead of arguing, why not look at what LINQ does?
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.
LINQ lets you write SQL queries using the (.NET) language in which you write all your other code. This means you get to take full advantage of the language (and language service) features, including the typechecker, code completion etc.
The hard bit here is making sure the language type-checker is fully aware of the involved types, both while writing the query as well as while selecting the results to be returned
This approach has since been copied in more capable languages. One of my favorite examples lately is Rust's Diesel: https://diesel.rs/ (see the "complex queries") example.
A query language designer aware of the above lessons learned with SQL might take special care to ensure their new query language is easier to model in existing languages. For example, they might consider an alternative OOP or FP based syntax, or to generalize they might put some thought into what would make it easy to write a type-safe query builder. After all, while SQL was developed in 197x and we had a different model for data access early on (stored procedures instead of flexible language-integrated queries) so its easier to understand that we didn't consider integration with other languags. TypeScript already did exist when GraphQL first appeared in 2015, and it's been 7 years of LINQ at that point.
Yet, we still went the stored procedures route. Tools such as graphql-codegen [1] require you to regenerate your types every time you edit your query strings
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.
Its a reasonable looking wrapper. Could benefit from the ability to build queries with variables, although not sure if that would be useful in the Scala ecosystem.
To make it clear, I disagree I'm conflating things. I'm currently working on a TypeScript based graphql builder (https://typed-graphql-builder.spion.dev/) and I can think of several ways the language could've been designed to make it easier to write typed query builders.
This is not without consequences - since its quite hard to write the builder, most tools available for code generation (https://www.graphql-code-generator.com/) are built around editing GraphQL strings and will try to find them in your code and add type assertions. Additionally the rest of the ecosystem tools are built around supporting this workflow (graphql playgrund, etc)
Even if I did share them, its too late for GraphQL to make that change - they are design decisions and people probably already rely on them
Here is a few:
- Less fine-grained field selection - allow for fields selected by default. This would remove some of the need for optionals in languages that aren't able to dynamically create record types on the fly
- Implicit unions and union queries are really annoying to model in both OOP and FP languages. In FP disjoint tagged unions with no inheritance would work better; in OOP common interfaces but no ability to define unions would work better. As it stands, the mix makes it difficult on both language types to support a general schema. Unions based on optional fields (like in GRPC) are probably best-of-both-worlds here.
Yeah, if you use something like Postgres and Hasura for a new project it's pretty simple. I doubt you could make a REST API much easier. Django + Django Admin is close, but that's not really an equivalent per se.
> That's like saying SQL is crap because you need to build queries by hand
If we want to use these terms, then SQL is indeed crap, because you need put query parameters in-band instead of out-of-band. This led to numerous exploits over the years, as it's difficult to ensure the data is correctly escaped. GraphQL just repeated the same mistakes.
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.
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!
