HN user

Nimelrian

139 karma
Posts1
Comments39
View on HN

The jobs at risk are not only those in the coal industry but also the jobs powered by the coal. You can't run a business without electricity. So if coal makes up about a third of the power then about a third of the jobs in Germany could be lost.

That is one of the most ridiculous statements I have ever heard.

UX clichés 7 years ago

Not the person you're responding to, but I was on a team which probably did the same thing.

Instead of listening directly to the event store for events you have another non-abstracting layer on top and listen to that.

A sensible architecture would have that layer be an abstraction layer for business use cases, so instead of listening to "user-created", "user-edited" and "user-deleted" events and rebuilding the user state in the consumer every time an event is fired, you'd have that layer expose a single user state stream. The rebuilding is handled entirely within the layer.

Many people skip that and just re-expose the "primitive" streams of the event store, because they read "don't expose your persistence layer" and skipped the important ", expose the business state layer instead" which usually comes right after that.

It's much easier to implement in Javascript, too, even though JS has a much smaller standard library. The main problem is Go's lack of generics.

Yup, you can implement the whole ordeal in C++ like this:

  int main(int argc, char** argv) {
    std::vector<std::string> strings{
      "apple", "cAt", "cat", "Dog", "apple", "dog", "Cat",
      "Apple", "dOg", "banana", "cat", "dog", "apple",
    };
  
    strings.erase(
      std::remove_if(
        std::begin(strings),
        std::end(strings),
        [seen = std::unordered_set<std::string>{}](std::string_view str) mutable {
          std::string lower = "";
          std::transform(std::begin(str), std::end(str), std::back_inserter(lower), ::tolower);
          if (seen.find(lower) == std::end(seen)) {
            seen.insert(lower);
            return false;
          }
          return true;
        }
      ),
      std::end(strings)
    );
  
    for (auto& str : strings) {
      std::cout << str << "\n";
    };
  }

The npm docs also state that the "files" property of the package.json limits what gets installed if you install that package in another project.

Ever tried installing a local package via a file path? NPM just symlinks it into node_modules, causing issues because you suddenly have duplicated dependencies. Yarn does the same, btw.

I have given up any hope regarding npm/yarn acting sensible long ago.

Nowadays you'd use fetch anyway which would reduce that code to not much more than the jQuery samples.

That is, if you don't need to support IE (And I feel like we're finally in the phase where it slowly, but steadily dies off). Otherwise you can ponyfill it.

Good rust code doesn't have to be free of unsafe blocks. In some cases you can't avoid them, e.g. when doing memory mapping. Instead, the unsafe blocks semantically designate areas you should keep an eye on. I rather have 20 unsafe one-liners surrounded by safe wrappers in a project with several thousand LOC, than a 1k LOC C project where I have to take extra care with every step.

The proposal explicitly states that everything in the standard library would not be tied to specific target environments:

Such a library would only cover features which would be useful in JavaScript in general, not things which are tied to the web platform. (A good heuristic: if something would make sense on a web browser but not in node or on embedded devices or robots, it probably isn't in scope.)

Not entirely.

For example, a function which takes a property path (in the form of an array of strings) and an object as parameters and returns the value at that path inside the object still needs overloads for every single tuple length.

  type Key = string | number | symbol;
  
  function get<T, K extends keyof T>(path: [K], obj: T): T[K];
  function get<T, K1 extends keyof T, K2 extends keyof T[K1]>(path: [K1, K2], obj: T): T[K1][K2];
  function get<T, K1 extends keyof T, K2 extends keyof T[K1], K3 extends keyof T[K1][K2]>(path: [K1, K2, K3], obj: T): T[K1][K2][K3];
  function get<T, K1 extends keyof T, K2 extends keyof T[K1], K3 extends keyof T[K1][K2], K4 extends keyof T[K1][K2][K3]>(path: [K1, K2, K3, K4], obj: T): T[K1][K2][K3][K4];
  function get(path: Key[], obj: any) {
      if (path.length === 0) {
          return obj;
      }
      const key = path[0] as Key;
      const rest = path.slice(1) as [Key];
      return get(rest, obj[key]);
  }
  
  
  interface Foo {
      foo: {
          bar: {
              baz: {
                  val: number;
              }
          }
      }
  }
  
  declare const foo: Foo;
  const num = get(["foo", "bar", "baz", "val"], foo);
In this case, num is implicitly typed as number, but if the path would be longer, you'd need to add more overloads.

Last time I checked, the extraction process for lithium, which is needed for the batteries, still has a heavy impact on the environment. This article mentions a cost of 500,000 gallons (almost 2 million litres) of water for a tonne of lithium. [1] Considering that as of now the most lithium is produced in desert regions of Bolivia and Chile, using what little water exists there in the first place may be detrimental to the population of these regions.

Are there any news regarding new, more environment friendly mining processes?

[1] https://www.wired.co.uk/article/lithium-batteries-environmen...

Especially since the GoF Design Patterns, which are often cited as the main reason for Java being verbose, were described in the original book using C++ (and smalltalk) examples.

Just because they may be overused in Java doesn't mean people shouldn't use them at all in other languages.

Even a single hydrogen atom is bigger than a single Helium atom. The charge of the helium nucleus is higher and thus "pulls" the two electrons further inward than Hydrogen's single proton pulls its single electron.