Nycto

Users on mobile can’t make their screens that big, and the average users on desktops don’t expect a webpage to work when they resize their browsers that small. Trying to make both work with the same design can have a negative impact on your customers, from both a usability perspective and by increasing page weight.

Instead, my advice is to create individual designs for each, share when it makes sense, but actively diverge when it’s good for your customers. There doesn’t need to be a single version of a page.

Your mileage may vary.

Obligatory links for anyone that is interested in learning more about Bézier curves:

https://pomax.github.io/bezierinfo/

https://pomax.github.io/bezierjs/

https://github.com/Pomax/bezierjs

I’m guessing the venue you’re talking about is tiny. There are only 1 or 2 major venues in the US that aren’t owned by live nation.

Anecdote != data

Cyber did an episode that covered this in more detail, btw: https://www.vice.com/en/article/z348k3/cyber-why-concert-tic...

More readable link: https://threadreaderapp.com/thread/1558081281396727808.html

Someone on Reddit added Nim to the table, which I found interesting:

https://uploads.peterme.net/nimsafe.html

(Source: https://www.reddit.com/r/nim/comments/maj1lz/nim_safety_in_c...)

I agree. From my perspective, microservices shouldn’t be a starting point. They should be something you carve out of a larger application as the need arises.

The first thing that comes to my mind is that there are different axes that you may need to scale against. Microservices are a common way to scale when you’re trying to increase the number of teams working on a project. Dividing across a service api allows different teams to use different technology and with different release schedules.

My go to article for Pratt parsing:

http://journal.stuffwithstuff.com/2011/03/19/pratt-parsers-e...

Adding to this, I see two other elements that make this tough to replicate in Kotlin:

1. Type erasure

2. Using sealed classes requires instantiation, while the Rust version is zero overhead.

Is there anything you would recommend instead? Or any resources you have on hand to get more information?

This is called a VLQ, btw. Variable Length Qunatity: https://en.m.wikipedia.org/wiki/Variable-length_quantity

The dynamo white paper, for one.

Also: https://github.com/amzn

Fails for Amazon URLs, too (And no, I didn't include a referral link in there.)

If your entire code base is in Kotlin, then nullability works exactly like Options. The difference is sugar. And the Kotlin compiler can handle null checks as well as the Scala compiler handles Options.

The problems arise when you interop with Java. At that point, shit can be null and you just don't know. My point is that it's the same problem in Scala as it is in Kotlin: Java interop adds a measure of unpredictability that needs to be handled at the touch points.

That's not the point. The point is that any safety you think you have by using an Option is a little bit hand-wavy.

That's not _bad_, but the argument being made by the OP was that nullability in Kotlin was unsafe and inconsistent.

I don't see a huge difference between Scala's Options and Kotlin's null safety. In Scala, you can still do this:

    val x: Option[Int] = null

I like Scala. I've written a lot of Scala. But choosing a language is a team decision. And Scala draws the same kind of ire as C++. It's to the point that I have seen seasoned engineers laugh any time Scala is suggested.

To provide a bit more depth, a large number of the developers I work with (folks I respect) don't _want_ the kitchen sink. They see it as dangerous. Even if _they_ can handle it, they know that there are a lot of people who can't. Sure, you can limit the features you use via convention, but that is shifting a tech problem to being a people problem -- you usually want to go the other direction.

You can "yeah, but..." all you want, but it's a valid, reasonable opinion. It's subjective, but that's just the way of it.

I'm a huge fan of Kotlin. I think the author just doesn't understand the niche it hits.

My team has a significant investment in the JVM. I despise working in Java because of how heavy it is to write. I like Scala, but the team I'm on finds it too complicated. Clojure is out because nobody on the team wants to write lisp. And Groovy doesn't have types. We looked at Ceylon, too, but at the time we hit a lot of compiler issues (if I remember correctly).

So where does that leave us? There are likely other languages we could choose that target the JVM, but the pragmatist in me says I don't want to stray too far off the beaten path for this.

Is Kotlin perfect? No. But is it a better developer experience than Java? Oh hell yes.

This isn't a full solution, but perhaps inter-tab communication would work? Use whichever tab is focused as the master, then other tabs send messages to the primary as they need work done. It wouldn't work when none of your tabs are focused, but perhaps that's an acceptable constraint.

That's not at all the case. Templates can return values. So really, you could think of the templates as syntactic sugar around the existing functions you've got right now.

For example, the 'firstOf' template above would be responsible for scanning the AST it's given, taking each node and putting it in to a sequence. Then it instantiates a Handler with that sequence and returns it.

I came here to say the same thing as the GP. So while I am not the poster you responded to, I'll pitch in my opinion.

I've written a number of Nim libs at this point. Rosencrantz is missing the idiomatic 'feel' of Nim -- blocks and trees. I would rather see a syntax like this:

    let handler = firstOf:
      get:
        firstOf:
          path("/api/status"):
            ok(getStatus())
          pathChunk("/api/message"):
            accept("application/json"):
              intSegment(id):
                  let message = getMessageById(id)
                  ok(message)
      post:
        path("/api/new-message"):
          jsonBody(msg):
            let
              id = generateId()
              saved = saveMessage(id, msg)
            if saved: ok(id)
            else: complete(Http500, "save failed")

I spent a moment seriously considering whether I had time to submit a pull request adding a Nim layer:

http://nim-lang.org/manual.html#foreign-function-interface

Hmm. This feels a bit pedantic to me. The `is_null` check looks relegated to the FFI:

https://github.com/CausalityLtd/ponyc/blob/975d9f6c60553030e...

Obviously, I have never written anything in Pony, but this absolutely seems like an advanced use case. It exists because 'C' has a concept of null, so it needs to be handled. The manual even admits that all bets are off when dealing with the FFI.

Quick link for anyone that is curious, as I was: https://github.com/CausalityLtd/ponyc/blob/master/packages/n...

I have found the article I linked to be incredibly digestible for people learning REST, which is why I recommend it; regardless of the point-of-view. It's what I think is missing from your slides. You might be able to solve this in the context of an actual presentation, but taken as just the slides, it's very dense.

Also, this isn't self-promotion at all. I'm not in any way associated with that blog. I just like the content.

Different perspectives and learning styles, I suppose. I'm not trying to be argumentative, just briefly laying out my thoughts. Cheers

A slog indeed.

For anyone interested, this is the article I hand out when someone asks me about designing a REST API: http://www.vinaysahni.com/best-practices-for-a-pragmatic-res...

And here is the HN discussion from when it was originally posted: https://news.ycombinator.com/item?id=5819231

I would love to see an article like this for error handling in Rust. I was really interested in using conditions, but those were apparently backed out. Which leaves error handling through return values and macros. This seems like a step back from Exceptions to me. I want to be convinced otherwise, but I'm struggling to see how this is better than other mechanisms.

Quick tip: Merge your CSS and JS. It's killing your page load time: http://www.webpagetest.org/result/131223_MJ_Q59/

Your first paint is coming it at around 1.8s. You could probably get that under the 1s mark just by consolidating your resources. This is even more important when dealing with a library like Angular.

Something similar could probably be done with code (if it hasn't been done already). I suppose auto-formatting and checkstyles might mute some things, but I imagine you could still get a read from things like variable names, class names, function length, etc.

Does this interact with door locks and car alarms at all? Is that even possible? At least once a week I find myself walking back to my car to make sure I hit the car alarm. I would definitely pay to solve that problem. Getting an iPhone app for my home security system has already saved me a lot of grief.