rokob

He told me don’t fall into the trap of hiring frontend skills only. Hire software engineers who happen to really know JavaScript.

This has served me really well. Every aspect of applications that we build has needs to structure code, to collaborate in teams, to build abstraction, to ship with an acceptable level of brokenness, and to have mechanisms for continuous improvement.

I’ve worked in several frontend and backend codebases and they all had aspects of difficulty and toil. However talking to lots of people about this I find that certain parts of the stack work better for your personality and talents.

I used to think of frontend as lessor because the hard things seemed to be on the backend. But then I met high caliber JavaScript engineers.

It is sort of like abstract art. Great artists have a solid foundation and then choose their own path.

It is good to get a feel for both and see what resonates with you. Also spending time on the backend can give you empathy to make you better at the frontend; and vice versa.

It only technically is built for Rails and Laravel but reading the “spec” and the code I got it to work pretty quickly with a Rust backend.

It would be nice for more of these frontend niceties to be built around an API contract rather than a particular JS on the server implementation.

So you can define a struct with one status field and the right annotations and you will get exactly what you describe without having to write the code and it will still be almost as fast as doing that parsing yourself.

I have a lot opinions on this and continue to say them internally. I encourage you to say this internally as well.

Dart is considering adding pattern matching (and real tuples!) and I think they will eventually get there. I just think that would have had to come first to make the case of optionals over nullable types more compelling.

I would call that example destructing in the normal sense and it is basically a form of pattern matching. To do that in an imperative language without pattern matching (i.e. what I am calling imperative destructuring), you end up with code like

  if (maybeFoo.isSome) {
    final foo = maybeFoo.asValue;
    ...
  }

  if let Some(foo) = maybeFoo {...}

It is very simple to add a Maybe and Either type to Dart (my code base has variants of these to deal with null issues) but imperative destructing is a pain. You can get most of the benefits of those techniques in user land without the language knowing about it, but I agree it still misses out on some stuff.

If Dart already had pattern matching or was willing to add it first then the ADT version could have been chosen, but without that prerequisite nullable types was the only ergonomic choice.

Why don't you just read the code?

> as of Ruby 2.2, there are zero-performance gains using symbols over strings

This is verifiably false. Run this on a newer Ruby and you will see symbols are faster:

``` require 'benchmark'

hashes = [] 1_000_000.times { hashes << { some_key_name: 1, 'some_key_name' => 2 }} Benchmark.bmbm do |x| x.report { hashes.map{|h| h[:some_key_name]} } x.report { hashes.map{|h| h['some_key_name']} } end ```

But that isn't the reason symbols are useful. They signify intent as a constrained set of alternatives. Strings can take on any value, symbols should be limited to a set of things you know. Strings can be modified in-place, symbols are immutable.

`opts = { :adapter => :mysql }` is perfectly valid for scenarios where you are using symbol values. But the shorthand syntax for symbol keys was added later, and I agree is a bit ugly.

If you are generating symbols from input or from strings then they lose some value.

It is easy to explain the existence of symbols in Ruby especially if you are giving proper merit to the Smalltalk lineage. Erlang also has symbols for a lot of the same reasons and most would agree they are very useful there.

with some explanation for where the seed comes from here:

https://github.com/apple/swift/blob/master/stdlib/public/cor...

Within that code you will see references to Core which by default is this:

https://github.com/apple/swift/blob/82226642c2459c0f5d2054fe...

So you can see the hash function itself is deterministic given the seed it is initialized with. And the seed is generated at process start time during static initialization in C++ so it is effectively a constant for the lifetime of the process.

You can see in the code that there is a way to make hashing fully deterministic by making the seed generation not use random numbers, but it is ill-advised for a variety of security reasons.

I think what you are bringing up though is the quagmire that could result from trying to build a network that has to abide by 50 different regulatory systems. I would like to see an independent third party draft regulation on net neutrality that each participating state could then adopt through their own procedures. I know that probably won't happen, but it would be nice to see a form of "collective bargaining" among the states.

Personally, it is good policy for states to support net neutrality if that is what their constituents want. But the implementation might be a shit show.

Swift was designed for writing apps on the mac platforms, primarily on iOS, and although somewhat debatable as a replacement for Objective-C due to it's quirks. If you want proof of that, just read between the lines in the original documentation.

Not to mention, many of the features that were called out originally are direct responses to issues with Objective-C: Optionals, Typed containers, Generics, modules, real first class functions instead of just blocks, final classes, let, etc.