Hacker News Reader

ash_gtion The Swift compiler is slow due to how types are inferred

The haskell source has `let channel = "11"` vs `let channel = 11`. The example from the post is an example that looks like it should be pretty straight forward but the swift compiler falls over when you try it.

Trying it locally for example:

  # Original example
  $ time swiftc -typecheck - <<-HERE
  let address = "127.0.0.1"
  let username = "steve"
  let password = "1234"
  let channel = 11
  
  let url = "http://" + username
              + ":" + password
              + "@" + address
              + "/api/" + channel        
              + "/picture"
  
  print(url)
  
  HERE
  <stdin>:6:5: error: the compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions
   4 | let channel = 11
   5 | 
   6 | let url = "http://" + username 
     |     `- error: the compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions
   7 |             + ":" + password 
   8 |             + "@" + address 
  swiftc -typecheck - <<<''  36.38s user 1.40s system 96% cpu 39.154 total
  
  # Adding a type to one of the expression values
  $ time swiftc -typecheck - <<-HERE
  let address = "127.0.0.1"
  let username = "steve"
  let password = "1234"
  let channel = 11
  
  let url = "http://" + username
              + ":" + password
              + "@" + address
              + "/api/" + String(channel)
              + "/picture"

  print(url)
  
  HERE
  swiftc -typecheck - <<<''  0.11s user 0.03s system 74% cpu 0.192 total

Which is roughly the in line with the numbers in the original post.

ash_gtion The Swift compiler is slow due to how types are inferred

The type is an inferred integer literal in swift (in the swift standard this is the `ExpressibleByIntegerLiteral`, the string literals are `ExpressibleByStringLiteral` types).

The reason this causes issues with the type checker is it has to consider all the possible combinations of the `+` operator against all the possible types that can be represented by an inferred integer literal.

This is whats causing the type checker to try every possible combination of types implementing the `+` operator, types implementing `ExpressibleByIntegerLiteral` and `ExpressibleByStringLiteral` in the standard library. That combination produces 59k+ permutations without even looking at non-standard library types.

If any of the types in the expression had an explicit type then it would be type checked basically instantly. Its the fact that none of the values in the expression have explicit types that is causing the type checker to consider so many different combinations.

ash_gtion The Swift compiler is slow due to how types are inferred

Your example is different than the example in the post.

Specifically, `channel = 11`, an integer.

If it was a string then it parses very quickly.

ash_gtion Goodbye, Node.js Buffer

You can use ‘atob’ and ‘btoa’ functions for some of that.

ash_gtion Backward Compatibility, Go 1.21, and Go 2

If you have a short lived CLI tool, disabling the GC might be useful but that’s likely an exceptional case.

ash_gtion Checked integer arithmetic in the prospect of C23

I know most of these are compiler intrinsically but it’s good to have them standardized.

ash_gtion WebKit Features in Safari 16.1

There is a setting in Preferences > Websites > Notifications to disable notifications entirely.

ash_gtion Official IE11 end-of-life in 2 days

I dunno, then there would only be 2 actively maintained browser engines, Chrome and Firefox.

Webkit is doing pretty good on https://wpt.fyi/interop-2022 so I'm not sure why Safari should be retired.

ash_gtion TC39 Proposal: Type Annotations

https://devblogs.microsoft.com/typescript/a-proposal-for-typ...

Has additional context on this proposal and has previously been linked here.

ash_gtion Safari Technology Preview Release Notes

There is queueMicrotask (https://developer.mozilla.org/en-US/docs/Web/API/queueMicrot...) to queue onto the end of the current iteration and you can use an `await 0;` to cycle the event loop as well.

ash_gtion Fetch API has landed into Node.js

Node does support ESM now by default (and has supported it for a while behind a flag), https://nodejs.org/api/esm.html

ash_gtion Low overhead C++ interface for Apple's Metal API

> It doesn't break ARC right, it just won't do the automatic reference counting in C++ source. You can send it back and forth over the wall with CFBridgingRetain and CFBridgingRelease no?

I guess I should say that clang's ARC doesn't apply to these c++ wrappers.

The c++ code is loading symbols using the objc runtime API's to load symbols and call objc runtime APIs to dispatch the metal calls. So, you could pass these references to other objc code and it should have the correct refcounts afterwards.

Having to manually retain/release objects is a bit of a pain, but its workable.

Using a c++ RAII type to retain/release is also somewhat do-able, but I worked in a codebase that had that kind of code and it can be frustrating to get the refcounts to be correct synchronized. Although that was back with c++11, so I'm sure things have changed that would make this easier today.

ash_gtion Low overhead C++ interface for Apple's Metal API

If the object is not autoreleased then doing a release call will deallocate the object, otherwise it will be added to the nearest autorelease pool from the current stack and be deallocated when the pool is drained.

Swift and obj-c have the same ARC semantics, so I'm not sure what you mean by swift-style refcounting. It should be identical to the obj-c ARC semantics.

https://clang.llvm.org/docs/AutomaticReferenceCounting.html outlines the ARC semantics, including the autorelease behavior.

ash_gtion Low overhead C++ interface for Apple's Metal API

The c++ wrappings break ARC, so if you use this library you'll have to manually retain/release any object. The autorelease pool is helpful if you autorelease an object but you'll need to manually manage the memory when using this set of helpers.

In obj-c or swift, ARC would handle that for you, so this makes the memory management aspect of using Metal a bit more of a headache.

ash_gtion How JavaScript Works: deep dive into call, apply, and bind

If you enable strict (https://www.typescriptlang.org/tsconfig#strict) or use the `strictBindCallApply` flag (https://www.typescriptlang.org/tsconfig#strictBindCallApply) it should check the types on call, bind and apply.

ash_gtion Implementing a LLVM Micro C compiler in Haskell

They went with a subset of C, its enough to write a working executable. Generally for a introduction tutorial to something as complex as writing a compiler a subset like what they presented in the article is enough to show how all the pieces work together to produce a working compiler.

ash_gtion Faster JavaScript Calls

TF can inline, but if it runs that optimization then the benchmark would be turned into a constant, so it wouldn't be measuring the call overhead of the way arguments are passed.

ash_gtion Faster JavaScript Calls

I think this is what WASM is meant to achieve. It allows for much more precise semantics without needing to parse an AST.

ash_gtion Swift on Windows

They didn't release the frameworks for those OSs.

That's like how Catalysts runtime wasn't backported to older versions of macOS.

They could decouple those frameworks from the OS, but that adds other headaches and you eventually gotta draw the line somewhere so they tend to only add new frameworks with major OS updates.

ash_gtion Swift on Windows

SwiftUI isn't tied to the OS version.

It has a runtime API that should work with different versions of the OS. There were changes to the compiler that they didn't talk about until after the fact though. After SwiftUI was announced they did run those through swift-evolution.

SwiftUI for the most part is just a runtime library, the compiler changes made things a bit nicer, but most of it could be achieved without compiler changes.

ash_gtion Apple blocked Facebook's attempt to tell users about 30% App Store 'tax'

> * Apple does not allow other App Stores on their platform

As a consumer, I see that as a feature not a bug. On the Switch, Play Station and Xbox I don't have other stores I can use as well. I don't see how this is a problem as much as it is a feature. The fact that Android allows more than one store is much closer to how a Windows PC allows the user to install apps from anywhere. iOS isn't trying to replicate the PC experience, its not nearly as general purpose as Windows or even macOS.

ash_gtion macOS deprecating scripting language runtimes, including Python, Ruby, and Perl

How about using a web browser with JavaScript?

Maybe not the best language for someone new but its widely available.

ash_gtion BigInt Shipping in Firefox

'i' suffix are often used in languages for complex numbers. For example, in ruby '1i' evaluates to 0+1i as a complex number.

I suspect they didn't want to conflate the two types.

ash_gtion Microsoft Edge and open source collaboration

Don't forget Opera is a re-skinned Chrome.

ash_gtion U.S. Supreme Court to hear Apple App Store antitrust dispute

WebKit does support service workers now and they're working on support for Web App Manifests. Some web apps, like Kindle Web Reader work fine in offline mode on my iPhone, granted that site is using the older (deprecated) App Cache manifest.

ash_gtion Apple Launches Portal for U.S. Users to Download Their Data

Apple had this in the EU since May~ish. It's now available in the US though.

ash_gtion Apple Launches Portal for U.S. Users to Download Their Data

Then they would have access to my iTunes account anyway...

ash_gtion Prepare for changes to macOS Server 5.7.1

An alternative could be something like "Apple deprecates additional services in macOS Server 5.7.1".

That's different than the linked page but I think it gets across the changes that are coming.

ash_gtion iOS 12 Safari Array reverse bug

It appears to be fixed at HEAD and in Safari Technology Preview per https://bugs.webkit.org/show_bug.cgi?id=188794

ash_gtion Pointers Are More Abstract Than You Might Expect in C

Did you use gcc or clang or...?

When I ran this locally I get:

    0x7ffeee2a4808 0x7ffeee2a4810 0
    0x7ffeee2a4808 0x7ffeee2a4810 0

With -O0 I get 1/1 instead of 0/0 so this appears to be a compiler optimization.