Nycto's comments

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.