dilap

Taste & trade-offs aside, you've gotta make it compile reasonably fast! I do get that Objective-C is not the pinacle of language development, but you shouldn't give your main language the rough edges of a research project.

(And while the past shouldn't necessarily be a shackle on the future, it is striking that such a radically different set of trade-offs was picked for Swift vs Obj-C.)

I think both Go and C# are pretty nice languages, to give you an idea of where I'm coming from. And Rust is very interesting -- as a user you see software that gets written in it exceed the previous state-of-the-art (e.g., ripgrep).

I don't see that w/ Swift. It seems like the opposite. E.g., the terrible Settings rewrite that rolled out a couple releases ago...

Confession, though, while I did a lot of ojbc back in the day, I've never done more than kick the tires on Swift, so I'm not critiquing from a position of deep knowledge -- more like talking shit from the sidelines. But I do think I'm right. ;-)

Swift is an early example of Apple losing its way. Such a stark contrast to Objective-c -- which was a simple, fast compiling language that hit way above its weight for expressivity and runtime speed. A great language for its day. Swift is "a C++ hacker's first attempt at language design".

There is a website forvo.com which has a bunch of community-generated pronunciations of words in a ton of languages. I used to use it a lot when I was playing around w/ learning languages.

There's also a paid API. I made a very basic command-line client which might still work: https://github.com/erinok/forvosay

Forget privacy, imagine what someone like @elder_plinius could get up to if you invited them over to dinner. All of the "AI Safety" issues get a lot more real once the AI's have bodies.

Nah, I don't think so -- it really was a big deal to have a bug back then, and software quality used to be a lot higher. We could go back and run some VMs to try to objectively quantify this (and it would be interesting to do so), but I'm personally confident my memory isn't being tinted by nostalgia.

The main reason is the ability to do constant updates now -- it changes the competitive calculus. Ship fast and fix bugs constantly wins out vs. going slower and having fewer bugs (both in the market & w/in a company "who ships faster?").

When you were shipping software on physical media having a critical bug was a very big deal. Not so anymore.

Besides the bad design, the implementation is awful as well. Slow and flickery.

I think having a world (3d maybe, or maybe just 2d) you could talk about in a really simple way might be useful here. Imagine something like "el gato quiere la pelota roja" and you have to carry the red ball to the cat to pass to the next lesson, and there's a cat, and a dog, and capibara and various shapes; something like that...

There's probably the opportunity to have simple stories and personalities come into play too, early on, to add interest. Think about e.g. the Frog and Toad books for children learning to read.

Playing briefly, looks pretty good! -- though I wonder if there's a way to move away from using a source language (or maybe it does this in later lessons?). You really want to try to get your head 100% inside the target language as quickly as possible, and not be translating back and forth.

Duolingo is terrible†, but proper gamification combined w/ LLMs for real conversations could be an incredible learning tool. (I might build this if no one else does.)

†It can be useful for going from absolute 0 to epsilon, just to kind of get familiar with the language, but if you're using it more than like 2 weeks, you're seriously wasting your time (vs. reading material in the target language, watching TV in target language, trying to talk w/ people in target language). Anki, too, can be a trap that feels like learning but isn't, really, in my experience.

YouTube is incredible, YouTube is poorly run. If I were making the laws, I'd do something similar to mandatory licensing of songs for radio: mandate that YouTube, as a sort de-facto content monopilist, provide third-party access to its database (upload, discovery, view counts, recommendations, etc). Devil is in the details, but well-done it would strictly improve the world.

Independent competitive companies are great, but things tend to devolve into de-facto mini-governments once things stabilize, and from there I think the (real) government using its power to force a little more competition could really improve things.

I didn't know that, but please accept SF as a sloppy metonym for bay area. :-)

We're in agreement about the facts on the ground.

Setting aside safety for a moment, consider just hygiene: BART is shockingly dirty. Which suggests mismanagement, above and beyond just a lack of detterence of criminality.

As for safety -- firing squads are probably not in the cards, but would jailing the violent be too much to hope for?

You think that's setting the bar too high or too low?

It's a shame that SF politics are so dysfunctional it can't have a metro at the same level of quality as, say, North Korea.

All citizens, I meant, in case it was unclear from the context.

Are there any hospitals anywhere that deny emergency treatment? I would be surprised.

Yeah, it blew my mind when I first learned Go had this problem -- like, people have already tripped over this many times! I was pleasantly surprised to see them fix it though.

Yeah, I totally agree -- given Go's design, the behavior makes sense (and changing the behavior just to make it more familiar to users of languages that fundamentally work differently would be silly).

However, the non-intuitive punning of nil is unfortunate.

I'm not sure what the ideal design would be.

Perhaps just making an interface not comparable to nil, but instead something like `unset`.

  type Cat struct {}
  type Animal interface{} 
  
  func main() {
   var c *Cat = nil
   var a Animal = c 
   if a == nil { // compile error, can't compare interface to nil
    ;
   }
   if a == unset { // false, hopefully intuitively
   }
  }
    

Still, it's a sharp edge you hit once and then understand. I am surprised people get so bothered by it...it's not like something that impairs your use of the language once you're proficient.

(E.g. complaints about nil existing at all, or error handling, are much more relatable!)

US healthcare is such a pain -- very high premiums, high deductibles, tons of paperwork, no price transparency.

My wife is from mexico, so while her visiting familly there I've had some opportunity to interact with and observe their system.

It seems better!

There are public hospitals which are open to all. The quality and wait times are reasonble, not fantastic. There is very little paperwork. (You don't have to jump through hoops like signing up for Medicaid or something.)

Alongside that, you can buy private insurance and go to private hospitals, which, in my (admittedly limited) experience, are very good -- efficient and reasonably priced. I would _guess_ because of less regulation and because they have to provide value above and beyond the free healthcare that's available?

In the US we seem to have created sort of the opposite incentive structure -- public healthcare is only available to a limited set of people, and everyone else is more or less forced into the private healthcare system (or "private", since it seems heavily intertwined w/ govt -- e.g., standard govt websites to pick a povider, tax penalty (tho since lifted) if you aren't signed up).

Somehow there's always a mountain of paperwork and bills that dribble in over months, and you never know how much the final cost is going to be.

Another seemingly-insane feature of the US system is if I pay for a service w/o insurance, I'll be billed some crazy rate. With insurance, I'll copay some reasonable-ish rate, and the insurance company will also pay some reasonable rate, often at like a 90% discount to the "quoted" rate. It feels like I'm coerced into insurance because I can't out-of-pocket pay the actual real reasonable rates.

Another annoyance is it also doesn't seem possible to buy insurance that just covers accidents, which I would personally do if I could...

It's a sharp edge you trip over once, and makes sense once you think about it, it's not like you need a PhD to understand it!

I do think there probably would've been some more elegant syntax or naming convention to make it less confusing.

(Side note, Go did fix scoping of captured variables in for,range loops, which was a back-incompat change, but they justified it by emperically showing it fixed more bugs than it caused (very reasonable). C# made the same change w/ the same justification earlier, which was inspiration for Go.)

This has already been explained many times, but it's so much fun I'll do it again. :-)

So: The way Go presents it is confusing, but this behavior makes sense, is correct, will never be changed, and is undoubtedly depended on by correct programs.

The confusing thing for people use to C++ or C# or Java or Python or most other languages is that in Go nil is a perfectly valid pointer receiver for a method to have. The method resolution lookup happens statically at compile time, and as long as the method doesn't try to deref the pointer, all good.

It still works if you assign to an interface.

  package main
  
  import "fmt"
  
  type Dog struct {}
  type Cat struct {}
  
  type Animal interface {
   MakeNoise()
  }
  
  func (*Dog) MakeNoise() { fmt.Println("bark") }
  func (*Cat) MakeNoise() { fmt.Println("meow") }
  
  func main() {
   var d *Dog = nil
   var c *Cat = nil
   var i Animal = d
   var j Animal = c
   d.MakeNoise()
   c.MakeNoise()
   i.MakeNoise()
   j.MakeNoise()
  }

This will print

  bark
  meow
  bark
  meow

But the interface method lookup can't happen at compile time. So the interface value is actually a pair -- the pointer to the type, and the instance value. The type is not nil, hence the interface value is something like (&Cat,nil) and (&Dog,nil) in each case, which is not the interface zero value, which is (nil, nil).

But it's super confusing because Go type cooerces a nil struct value to a non-nil (&type, nil) interface value. There's probably some naming or syntax way to make this clearer.

But the behavior is completely reasonable.

This is cool! Immediately upon playing with it I find I want more features :-)

- Ability to toggle ocean traversal off/on

- Ability to see route on a map

- AI generated summary of the trip if I took it -- what things did I see along the way? (Should reference real map data, then make up a story; matching local culture etc.)

Lack of git-lfs support (hack tho it is) is the only thing currently keeping me from trying (and, assuming it's as nice as it seems, using!) jj. Built-in, better large-file support would be amazing, and I'd happily just ditch git completely to gain that. I think there's probably a lot of people in the same boat.

I disgree. Other people were saying it's broken too. Reasonable company behavior here would be 1 tweet "we'll look into it", and then either "we reproduced and are working on a fix" or "looks good to us please contact support so we can investigate your particular issue". But there's no reason to initially make users jump through hoops.

I would have to imagine this is an accident or rogue vandalism -- I don't think USGOV is trying to stealth-edit the constitution by truncating the last 18 paragraphs of Article I.

It's a lot more disruptive, and psychologically much more annoying, to lose something, than to never have it at all.

I do think it's a shame that Apple controls the App Store so tightly -- it's not just NSFW stuff that's banned, it's all kinds of stuff for all sorts of reasons, e.g.

https://www.theguardian.com/technology/2012/aug/30/apple-blo...

If the web were invented today, it'd be strangled in the crib, since Apple would never approve the browser app.

Personally I like it, and it catches bugs right away, especially when there are multiple possible ids, e.g.

    func AddMessage(u UserId, m MessageId)

If it's just

    func AddMessage(userId, messageId string)

it's very easy to accidentally call as

    AddMessage(messageId, userId)

and then best-case you are wasting time figuring out a test failure, and worst case trying to figure out the bug IRL.

V.S. an instant compile error.

I have seen errors like this many times, both written by myself and others. I think it's great to use the type system to eliminate this class of error!

(Especially in languages like Go that make it very low-friction to define the newtype.)

Another benefit if you're working with any sort of static data system is it makes it very easy to validate the data -- e.g. just recursively scan for instances of FooId and make sure they are actually foo, instead of having to write custom logic or schema for everywhere a FooId might occur.

It keeps getting side-tracked in get-rich-quick-schemes and sandbagged by UX horrors, but in theory this is a great use-case for crypto: the freedom to pay whoever you want for whatever you want, like cash, but online.

I'm not sure, if you scroll through the bug report there seem to be some people maybe kind of making it work, but I couldn't figure out exactly what they were doing, so decided I'll just keep waiting for the real implementation.

They are slowly working on it:

https://github.com/jj-vcs/jj/issues/53

(I am interested because I want to try, but need git-lfs, which needs gitattributes.)