never_inline

It is optimized for marketing speak. It's very appealing to people who 1. don't know this is slop 2. don't read for in-depth knowledge but for entertainment.

Similarly coding is optimized for tutorial-sized code - ignoring exceptions, leaving "IN PRODUCTION DO XYZ" comments, etc...

If anything, vulnerability research should be good target for AI because failure to find an exploit isn't costly (and easily verified) but 1 in N success is very useful.

> People experience ADHD-like symptoms later in life for any number of reasons, like anxiety and stress at work, home, or school.

Can you provide some research on this?

Does this "non destructive subset of python SDK" exist today, without needing to bring, say, a whole webassembly runtime?

I am hoping something like CEL (with verifiable runtime guarantees) but the syntax being a subset of Python.

The shaman job is coming back?

I think most systems should not on https://github.com at run time (rather than build time - build failures should not bring your system down)?

I think they're becoming more common because AI -> FOMO -> tighter deadlines on projects "since you can use AI to accelerate your work", which is often not how it works, and last 10% of reliability work is forgotten.

The dislike is probably because of 2 reasons.

1. in most cases they don't want to handle `InterruptedException` or `IOException` and yet need to bubble them up. In that case the code is very verbose.

2. it makes lambdas and functions incompatible. So eg: if you're passing a function to forEach, you're forced to wrap it in runtime exception.

3. Due to (1) and (2), most people become lazy and do `throws Exception` which negates most advantages of having exceptions in the first place.

In line-of-business apps (where Java is used the most), an uncaught exception is not a big deal. It will bubble up and gets handled somewhere far up the stack (eg: the server logger) without disrupting other parts of the application. This reduces the utility of having every function throw InterruptedException / IOException when those hardly ever happen.

Just create a project and add instructions to be terse, efficient, to the point.

Thou shalt never mock the database, for thou shalt anger the database when thou moketh it.

In all seriousness, I have found this to be a useful suggestion, because the purpose of a test is to make sure invariants don't break in real code. When you mock the database, you're excluding large amounts of real code from test.

Thanks, that's a useful trick.

Now lets say its an async cache instead of singleton.

Here's a use case - singleton instantiation on first request, where instantiation itself requires an async call (eg: to DB or external service).

    _lock = asyncio.Lock()
    _instance = None

    def get_singleton():
      if _instance:
        return _instance
      async with _lock:
        if not _instance:
          _instance = await costly_function()
      return _instance

How do you suggest to replace this?

It's fine man. If rich folks can build $1B business, I can surely build something worth $10M.

--

That was a bit of tongue in cheek reaction but I think we all know this already.

What helps is to know that initial advantages compound A LOT : http://web.archive.org/web/20181224131908/https://ofdollarsa...

What does "linguistically oriented" even mean?

Can you give an example of how you "linguistically" approach a problem?

I mean, even in math, description of the problems are written in natural language, but they have to be precise.

how many letter "a" are there in "hundreads"?

Do they have test suite comparable to that of original sudo, or can they reuse the test suite of original sudo?

To be honest, I dont think recruiters read the CV anyway.

I tend to evaluate how well engineered a system is based on these pillars.

* Reliability - Includes HA, fault-tolerance on single node, reconciliation or reliable rollback of failed transactions, ability to manually intervene if something is wrong, and observability

* Security - privilege separation and defense in depth

* Performance - Are basic operations fast? Are there worst case performance pathologies? Are batch interfaces available for efficient processing? How many concurrent users can you handle (if server based).

If we consider all these and perfectly implement, it's already pretty rigorous as an engineering discipline. I think companies at Google scale can do that, on projects with budget. But everywhere else, we make lots and lots of compromises. So there's it.

For example, building high performance network systems or DB engines is more "engineering" than building line-of-business application. Because more of these "engineering" concerns are the part of specification.

I am intentionally leaving out UX, because its a product design problem.

Idk if it's about my demographic, but everyone in development positions who I know has to work till 7pm. There are people at less serious positions who leave at 5.

It probably doesn't work. It seems to work because you will never know the opportunity cost of not hiring a better person, after you already hired a worse person.

> But my background kept leading hiring managers to suggest putting me on cloud teams doing orchestration in Go around a database rather than working on the database itself.

This is extremely annoying. This also means if your first job is doing X, it is very difficult to break into Y even if you know quite well about Y, and even have side projects. I have tried attaching cover letters indicating even if my current experience is in X, I am quite familiar with Y, to no luck. (No one reads those stuff).

Pros:

Pydantic is good. Mypy and pyright are good enough for type checking real projects. I run mypy as pre commit. It takes time but it has saved me from real bugs.

The type system coupled with pydantic for validation is more expressive and ergonomic than java / go. But it's also lousy when working with people who don't have the type oriented thinking (especially juniors). You need to enforce people to type public signatures and enable strict linter settings.

Mixed:

Library wise, FastAPI ecosystem is type-first and works well. But old world ecosystems like django - I don't have first hand experience.

SQL alchemy seems to be getting better. But I wish something type-first similar to sqlc or room or Micronaut Data JDBC existed for python, where I could just use pydantic validated DTOs and use query builder, rather than dealing with SQLAlchemy's proxy objects. It's workable though. I would suggest keeping SQLA objects in only the layer that touches the DB and convert them to pydantic models at the boundary.

Library support is hit or miss. In common web dev, I get good typings as long as I stick to popular and "boring" libraries. Sometimes I have to look at docstring and use typing.cast to return types.

Cons:

new type checking solutions like pyrefly aren't there yet for my use cases. Ruff is good as linter and VSCode extension.

IDE extensions and mypy still miss some bugs which should never happen in typed languages. ESP with coroutines. (I wish there was a way to make it an error, to call coroutines without await, unless submitting them to a asyncio.run or gather etc.., dart has very good async linting in comparison).

Writing a: dict[tuple[str, str, str], int] = {} is no fun. But it guarantees if I use a wrong type of key down in the function, I will get a red squiggle.

Such an AI will invent plumber robot and welder robot as well.

Can someone explain a plebian C/python/java/go programmer with good idea about languages & runtimes:

==> what makes erlang runtimes so special which you don't get by common solutions for retries etc?

FastAPI+Unicorn is good but it is barebones compared to what django already has. I can see why someone with experience in latter would not choose a new stack.

Also performance wise FastAPI + uvicorn have many pitfalls as well, most of them being of asyncio.

Types in python are really good now.

It's the asyncio and all performance footguns which need to be fixed.

close button.

Yep. The only valid usecase I think of is using the secret for something else, eg connecting to an internal package registry, in which case the secret mounts may help.

I would like to know where I can read more in depth about profiling and performance analysis techniques.