uhura

This kind of stance cannot be made without properly setting the context for the software. It is very clear that different software backgrounds have different needs a different development strategies that are more efficient.

LLMs are a tool that added a new dimension to explore. While I haven't like many felt actual gains, others are finding, and time will allow us to better judge if those can lead to long term impacts in the economy.

Just based on what I've been reading and experiencing: - Short term POCs can reach validation stage faster. - Mature cloud software needs a lot of extra tooling (LLMs don't understand the codebase, lack of places to derive good context from, and so on). - Anything in between for cloud seems to be a hit or miss, where people are mostly trading first iteration time for more refactoring later down the line.

From another perspective, areas of software where things are a lot more about numbers (cpu time, memory consumption, and so on), may benefit a lot from faster development/coding as the validation phase is either shorter or can be executed in parallel.

The key reality here is that I've been observing higher expectations for deliveries without a proof that we actually got better at coding in general. Which means that sacrifices are being made somewhere.

I’ve been having those discussions with friends for the last 3 or 4 years. The downside of having local infra is pretty much having someone that has the experience to do it right. While this article covered the higher end, the math on the lower end tends to work out at 1 year of ownership depending on what you already have because you will probably already have a small rack and some networking gear.

My main concern is that at the current cloud premiums rates, I will be better off even if I need to hire someone specifically for managing the local infra.

I believe that this long game of Swift being "good for everything" but "better for Apple platforms" will be detrimental to the language. This does not help the language nor seems to bring more people to the ecosystem.

Competitors seems to have a combination of: - Being more open-source - Have more contributors - Have a narrower scope

Maybe they should consider open sourcing all the tooling (like Xcode) otherwise the gap will only grow over time when compared to other languages.

The article reflects well many aspects of western life experience and might be poorly applicable in other contexts. The text shows signals of it when associating certain kinds of relationships to be more prevalent in certain social-economics classes.

Having no friends usually is associated with sadness but some people actually associate it with determination and ambition as “friends” are distractions. If you only have acquaintances, an alternative grouping might provide a better framework to explain and reason about it.

The overall model provided is a good starting point but seems to assume some general human kindness that might be far from real. Interactions might be faked on one or both sides, relationships usually are not symmetric, people have a difficult time adjusting their interpretation of the real world accordingly to the inputs they receive, and so on.

I usually do not use the word friend for people that I mostly interact because of a shared hobby nor for social acquaintances, but I understand that they fit the authors definition.

In practice the text has more value if you replace “friends” with “people you interact with” and if you add a “none of the above” category. Which does not diminish the value of the article in any way.

I believe the general strategy for this kind of product is to drive CX conversion. Amazon usually offers auto repurchase too, so if you are going to buy once and Amazon is cheaper, the second time too..., by the third you might actually decide to setup a auto purchase from time to time. if they discount 5 cents from the best competitor initially and in the long run they start to price 10 above, they use this to finance similar strategy to convert more CX and then they keep a more strong market position. In the end you don't push your competitors out of the market, but consolidate a very strong consumer base.

I don't get the "Maybe Rust isn’t a good tool for massively concurrent, userspace software" conclusion.

Rust is all about lifetimes and the borrow checker. Async code (a la C#) will introduce overhead to reason about lifetime and it might not be as "fun" as it is with other languages that makes use of GCs and bigger runtimes.

The CSP vs Async/Await discussion is valid, but like in the majority of the cases, the drawbacks and benefits are not language relevant.

In CSP, the concurrent snippets behave just like linear/sequencial code as channels abstracts await a lot of the ugly bits. Sequential code tends to be easier to reason and this might be very important for Rust considering it design.

A good tool for massively concurrent software will as expected depend on the aspects you're evaluating: - Performance: the text does not show benchmarks evaluating Rust as a slow language. - Code/Feature throughput: the overall conclusion from the text if that Async Rust is a complex tool and expose the programmers in many ways to shoot themselves in the foot.

Assuming the "Maybe Rust..." is only talking about Async Rust, the existence of big Async Rust projects is a good counter argument. We also have the whole rest of the Rust language to code massively concurrent, userspace software.

Massively concurrent, userspace software tends to be complex and big to the point that design decisions generally impact way more the language decision.

Rust is a modern language with interesting features to prevent programmers from writing unsafe programs and this is a good head start to many when making those kind of programs, more than whether you want to use Async code or not.

But then, how could you guarantee type safety?

This yield is not an object, it is handling the execution context to another stack.

I would prefer to add a `yield` param to functions so it can better interact with the current type system.

This means that for a function to yield, it needs to have the so called `yield` param and you can only yield inside a yield function functions with the same yield signature or does not contain a signature at all.

So the example would be rewritten into something like:

  x := func(:z int) {
    for {
      z++
      :- z
    }
  }

  for y := range x() {
    ...
  }

Functions that only yield a value `X` would just have the `: X` or `: name X`. To accept a value of type `Y` in the resume the signature would change to `:[Y] X` or `:[Y] name X`.

Accepting is weak, so if something expects a yielding function that resumes with Y and yield X, yielding functions that only yield X without a resume should also be accepted.

Consider the following code example:

  func filter[T comparable](it func(:T), f func(T) bool, :T) {
    for v := range it {
      if f(v) { :- v }
    }
  }

  func map[T](arr []T, :T) {
    for _, v := range arr {
      :- v
    }
  }

  for v := range filter(map({1, 2, 3}), func(x) { return x < 3 }) {
    print(v)
  }

A basic counter could be written like this:

  func counter(:[bool]c int) {
    for {
      if ! :- c { break }
      c += 1
    }
  }

  func countTwice(:[bool]c int) {
    count()
    count()
  }

  for c := range count() {
    if c > 10 { -: false }
    -: true
    print(c)
  }

Check the “introduction” paper about the family of OS [1], it provides a good introduction to get the how and why.

My two cents is that composing applications at the FS level is more expressive than Files/Sockets/HTTP requests.

Gluing up different of pieces of software becomes easier as most of the time it becomes just a matter of mounting a filesystem and you don’t need to worry about it being provided by a local or remote process.

[1] http://doc.cat-v.org/plan_9/4th_edition/papers/9

This might not be a popular opinion but it was what worked for me: - Research a little about PostScript and the display version. - NextStep Developer Documentation [1] - Apple older documentation (it is archived, but covered a lot of stuff)

Why this instead of a book? MacOS X UI is the result of many years of experiment and technologies. Going over the historical view gave me time to build a mental framework to work on instead of pushing things as they are today. MacOS is also changing so much that the documentation gap only gets worse with time.

Storyboards, SwiftUI, iOS, UIKit are noisy in that sense because they solve problems that you might not understand from the get go.

Understanding Objective-C is also crucial because besides SwiftUI, the backbone was made with Objective-C characteristics in mind. But this one I don’t have good references for besides Smalltalk books and Clang documentation.

[1] http://www.nextcomputers.org/NeXTfiles/Docs/NeXTStep/3.3/nd/

The comment mentions original iPhone screens. They were 3.5" and we hold phones differently because of the sub 4" displays.

The idea back then was maybe to separate the confirm action from other actions located at the bottom bar.

Human Interface Guidelines changed a lot as Apple changed the iPhone form factor. But with a 3.5", most of the screen is "uniformly" reachable and the bottom is slight less reachable as you usually need to flex the thumb.

This kind of article develops a dangerous line of reasoning.

The failure of Plan9 is not about what went wrong or right. It is about how the market evolved and made decisions, which goes beyond the scope of this comment.

The first conclusion "...is not to try to fix things that are not broken..." is dangerous because what someone identifies as broken is not the same as someone else. As a Plan9 user you may identify Unix deficiencies as problems and a Unix user might disagree.

The second conclusion "...is to try to identify if there is a market..." and there are many things in life that contradicts this (maths, basic science, maybe the beginning of Unix itself...).

And the final conclusion is about backwards compatibility. This is sound in the authors perspective because of the first conclusion but does not hold against good reasoning. Plan9 broke some compatibility because it needed and kept others because they were already good in the POV of the developers/researchers.

The Plan9 effects to me is far different. It is about the fact that Plan9 is unable to die against all expectations. 9P is there to stay, 9front gets releases every year, /proc is everywhere, same for UTF-8, and so on.

Good ideas stick, they are hard to let go and even harder to ignore. Plan9 failed in the commercial OS sense, just as many others failed. "You may never know it's broken until you fix it" (I'm sure heard it somewhere).

Old WWDC content has a lot of value. They cover a lot of core technologies that Apple has no interest in covering and documenting again (because they deprecated and are removing old documentation instead of improving them...). The channel in question helped me a lot while trying to understand aspects of early-Cocoa.

The argument you've presented is more related to the way Apple handles the evolution of its software than about having old content laying around. Their current approach is far from good unfortunately. During OS X Lion days, Xcode documentation was so rich that even core concepts of the OS were covered.

Having a structured way to keep those informations readily available is very important to help us preserve software history. And Apple is not helping...