xtrapolate

Audio latency issues on PCs are largely alleviated thanks to better softwate (device drivers that shorten the path to/from the hardware - such as ASIO4ALL) combined with better hardware (soundcards interfacing over PCI-E/Firewire/Thunderbolt/USB) at affordable prices. Plenty of audio cards today will offload computation off the CPU via discrete DSPs.

On Android devices (and smartphones in general) - hardware would be the limiting factor.

I don't quite resonate with the analogy here. It's about using the right tool for the job. Most small-scale personal projects, by their very definition, don't require an orchestration framework.

Which companies performed the security audits?

> "Product: Everhour. HQ: Minsk, Belarus"

So Go is somehow immune from a similar fate? What's the reasoning behind this?

> "Memory management in Kit is manual (no automatic garbage collection), with some convenience features to make this easier."

I was curious, but there aren't any examples of this on https://www.kitlang.org/examples.html

I see there's no privacy policy, and no clear guidelines on opting out. Why? Privacy was the focal point of 2018, but you're somehow ignoring that altogether?

> "Because after a day of work, most people just want to see funny pictures and check their email and login to a bank account to pay some bills. They're consumers, not producers."

You're simply saying people want affordable technology. In that case, what is Chromebook's advantage over the competition? The market is flooded with cheap hardware, targeting those exact types of consumers.

Numpy is fast thanks to having much of its code compiled as a native library.

They were purposefully working to reduce abstraction, since performance mattered from day one.

WASM is a huge step backwards in that regard. If you care about performance, just install Python on your box and "pip install numpy". Do you absolutely have to have it come in a browser now?

> "Part of an effort to make a Jupytr notebook-like environment without relying on server side code."

So there won't be any server side code, you'd just be downloading the entire Python stack and dependencies every time you want to use this through your browser. This time it will be WASM though, instead of x86/x64/pyc.

That we can, doesn't mean that we should.

> "Finally they let you hire some help and instead of getting busy helping writing tests and refactoring he starts thinking about the best way to throw you under the bus to your superiors."

Here's what actually happens.

By that point in a project's lifecycle, that's not what they usually ask of the new hires. People are usually tasked with fixing bugs/maintenance, and implementing new business logic. Both of which are extremely challenging and stressful when working on a project that comes with no tests, or documentation.

Your actual task as the new hire is to start generating more value for the company, but that's so much more challenging when you have no way of validating your solutions, no infrastructure to rely on, and no metrics or documentation to consult. At that point, being the new hire, you're taking a lot of heat for not getting things done on time - mostly through no fault of your own. At that point, "wanting to throw you under the bus to your superiors" is a very natural response - it's a defense mechanism, you're (rightfully) frustrated. You're between a rock and a hard place. At that point you're no longer doing software engineering, it turns to politics/coverups/fire-extinguishing on a daily basis. Can you not relate to that?

Do you seriously think they care about re-using a name for a throw-away non-classified project? People have better things to do with their time.

A different approach to decoding vibrations into speech, involving a laser microphone: https://en.wikipedia.org/wiki/Laser_microphone

Now let's get this down to earth. You're walking outside, it's dark, you get catcalled by a passerby. What's next? Do you pull out your phone and call the police? Try and take a picture of the person catcalling you? Where's your evidence? By the time you're done reaching for your pocket, that other person is long gone. That is to say, we now have a new law which is incredibly difficult to enforce, so what's the point exactly?

Why don't we tackle problematic social phenomena through education instead?

Simple stress tests should've revealed this. Basic profiling should've revealed this. This article makes it appear that they've went live without ever really testing the infrastructure under any kind of load whatsoever.

The article refers to some mysterious "engineering team". It would appear very little actual engineering took place at that company.

> "Because of quotas, there is more diversity in tech. That's a fact."

Fair enough. Besides the obvious "diversification" of the company's populace, what other success factors can be directly attributed to quotas?

> "This is an obvious false correlation. You have no evidence that Apple would not be even more successful were the engineering team more diverse."

This argument goes both ways. We also don't have concrete evidence proving that "diversifying the engineering team" will necessarily result in success.

> "Do you like discrimination?"

I'd argue "diversity quotas" are the very archetype of discrimination.

"We moved to GraphQL because things were bad, and now things are good. GraphQL is amazing".

I don't want this to come off as a personal attack (and I apologize if it does), but your comment contains absolutely no information whatsoever regarding a specific situation/use-case, nothing from which the rest of us can formulate our own opinions on the REST/GraphQL discussion.

Is entanglement an actual physical phenomenon? What exactly needs to happen in-order for a photon to "become" entangled?

> "Is there a geographical bias in your skepticism? Would you be as skeptical if this kid was from Norway or Sweden or Austria?"

Nothing in the parent comment implies a so-called "geographical bias", yet there you are accusing them of being racist.

> "Davidson sued, arguing that he was owed royalties for unauthorized use of an image of his statue"

Orthogonal, though can't help but wonder whether Davidson got Frédéric Auguste Bartholdi's approval before re-creating an almost identical statue.

Not refuting your theory, but in all probability, you (like most others in the industry) have friends ("friends"?) that simply relay info to recruiters from these two companies. Poaching is often done that way.

Also, at least in my case, both Google and Facebook periodically reach out, years after our last formal interaction.

Had a recruiter working for one of my clients for a few years. They later left the company and joined the competition. Recruiter's past "success stories" all got contacted, not a week after.

So, which came first to the bay area? the engineers, or the companies? Are we at a point where most people move in to the bay area for work? Or is it the other way around (ie. companies wanting to establish a foothold in an area known for its prestigious/unique population of software-engineers)?

My point is, not only are the employees losing here, but also the employers. I no longer understand the motivation of companies to continue expanding at problematic locations (such as the bay area and new-york).

If Google left the bay area completely tomorrow, would that somehow restore the equilibrium?

Are you seriously suggesting this is an issue? That's entirely up to you to solve in your custom allocator.

Use whatever mechanism is available to you. Use a global condition variable, check it atomically every time you're entering your custom allocator, increment after a successful allocation. I don't know your system's constraints, nor should I...

  void * your_custom_allocator(size_t size)
  {
      // Handle your locks.
      // Sanity checks, assertions, bounds checks, etc...

      void * result = g_your_buffer + g_position;

      // "Commit Memory" from your buffer.
      g_position += size;

      // Some more code...

      return result;
  }

Now, you can happily use:

  BASE64DECODE_DecodeEx(..., your_custom_allocator, your_custom_deallocator);

What else do you need? You seem very disturbed by the use of the word "allocator" here, feel free to rename to whatever works for you.

> "You're imagining a world where everything is Node or Python or Java, or at the worst C on top of the well-defined standard library. And I'm telling you that the world is bigger than that."

Why do you keep putting words in my mouth?

> "But what if I don't have a heap? Not even a wrappable heap."

I'm forced to repeat myself over again. At no point does my proposed API force you to rely on a heap. On the contrary, it lets you rely on whatever solution works best for you, in your specific case.

In your custom kernel project, your custom allocator() can return a buffer from a memory pool you handle yourself. Your custom deallocator() will reclaim that memory back into your custom memory pool.

In a different project, say a desktop app for Windows 10, the allocator() will simply call malloc(), and the deallocator() will call free().

This way, your allocator() can do whatever. Your deallocator() can do whatever. How is this restrictive in any way shape or form?

> "Pollution is in the eye of the beholder. There are many circumstances where a project or subset of a project needs to work without a heap, they just don't necessarily overlap with the "application layer code in a virtual memory process" world your intuition is calibrated against."

That's an argument in favor of offloading allocation/deallocation to the library's users, which is exactly the core of my, and OP's, proposals. We're saying the same thing here - developers should be able to determine/control how memory is allocated and deallocated.

> "And sometimes this stuff needs to read a JSON object or decode base64 or utf8 too, and can't because the library is too thick."

I'm losing you here. I honestly feel that my proposal is all about keeping the API as simple as humanely possible, without compromising the library's flexibility when it comes to the scenarios your mentioned earlier.

In your case:

  BASE64DECODER_Decode(...)
  BASE64DECODER_DecodeEx(..., allocator, deallocator)
  BYTE * BASE64DECODER_GetDecodedBuffer(handle)
  BASE64DECODER_Free(handle)

> "The library mustn’t call malloc() internally. It’s up to the caller to allocate memory for the library. What’s nice about this is that it’s completely up to the application exactly how memory is allocated. Maybe it’s using a custom allocator, or it’s not linked against the standard library."

OP's approach will indeed work for most "minimalist"/single-header libraries, but, I personally feel it pollutes the API you're exposing to your users.

Depending on the specific situation, I may sometimes choose to expose a MODULE_CreateObject() and a MODULE_CreateObjectEx(custom_allocator, custom_deallocator).

Internally, MODULE_CreateObject() calls MODULE_CreateObjectEx(), passing the module's default allocators and deallocators (ie. HeapAlloc and HeapFree). This strikes me as a more balanced approach.

One caveat here, is that you must enforce consistency across usage - you don't want some API calls to use malloc() for allocation, whilst others use HeapFree() for deallocation, that would be a recipe for disaster.

To ensure that, I would often set the allocators and deallocators once, when the object is first created. They may be set through the object's initialization function, and they persist as part of the object itself.

> "Yes, PHP and Node.JS and Ruby all are just as bad or worse than Python. That's the whole point!"

The original comment I was replying to was taking a stab at Python in particular. All I'm saying, is that in the open-source community, in that specific regard, Python doesn't stand out. Many developers care about backwards compatibility, many (dare I say, most) others simply don't.

I've had a large Java repo that broke recently, after we've updated some of our Maven deps to slightly newer versions (that was a very large, well known and used package). So those things happen in the "Java world" too.