Live data from Hacker News

Closing this as we are no longer pursuing Swift adoption

github.com

321–330 of 332 posts

Re: Closing this as we are no longer pursuing Swift adoption

#321

Earlier quoted context omitted.

I never heard of hardware without one

Avoiding interacting with LLVM as a user doesn't mean you've created something equivalent to LLVM. And if the C compiler you use is clang then you're still literally making use of LLVM.

So what you're saying is that C source code is the (only) stable LLVM ABI ;)

Re: Closing this as we are no longer pursuing Swift adoption

#322
post #69

Earlier quoted context omitted.

Rust has straightforward support for every part of OOP other than implementation inheritance, and even implementation inheritance can be rephrased elegantly as the generic typestate pattern. (The two are effectively one and the same; if anything, generic typestate is likely more general.)

I think we have seen enough since the best example of a Rust browser that is Servo, has taken them 14 years to reach v0.0.1. So the approach of having a new language that requires a full rewrite (even with an LLM) is still a bad approach. Fil-C likely can do the job without a massive rewrite and achieving safety for C and C++. Job done. EDIT: The authors of Ladybird have already dismissed using Rust, and with Servo p…

This comment needs another 'EDIT'.

Re: Closing this as we are no longer pursuing Swift adoption

#323
post #46

Why did Ladybird even attempt this with Swift, but (I presume) not with Rust? If they're going to go to the trouble of adding another language, does Rust not have a better history of C++ interop? Not to mention, Swift's GC doesn't seem great for the browser's performance.

Swift doesn't use a garbage collector.

ARC is GC, Swift definitely uses GC.

It isn't a _tracing_ GC

Re: Closing this as we are no longer pursuing Swift adoption

#324
post #262

Earlier quoted context omitted.

I fully accept that formalism is an important factor in programming language design. But all HLLs (well, even ASM) are a compromise between machine speak ( https://youtu.be/CTjolEUj00g?si=79zMVRl0oMQo4Tby ) and human speak. My case is that the current fashion is to draw the line at an overly simple level, and that there are ways to wrap the formalism in more natural constructs that trigger the parts of the brain that…

How is that snippet any better than: x := 42 Or let x = 42 Or x = 42 It seems like a regression from modern languages.

"my" is 33% shorter than "let"

Example 1 and 3 are not declarations, so apples ↔ oranges

Re: Closing this as we are no longer pursuing Swift adoption

#325
post #324
post #262

Earlier quoted context omitted.

How is that snippet any better than: x := 42 Or let x = 42 Or x = 42 It seems like a regression from modern languages.

"my" is 33% shorter than "let" Example 1 and 3 are not declarations, so apples ↔ oranges

Example 1 is a declaration in Go. Example 3 is a declaration in Python.

Re: Closing this as we are no longer pursuing Swift adoption

#326
post #324
post #262

Earlier quoted context omitted.

How is that snippet any better than: x := 42 Or let x = 42 Or x = 42 It seems like a regression from modern languages.

"my" is 33% shorter than "let" Example 1 and 3 are not declarations, so apples ↔ oranges

my $x = 42;

let x = 42

Well, when you add in the '$' and ';' tokens the "let" example is still shorter. Also as another person replied to you, those other two examples are declarations in other languages. So 0 for 3 there.

Re: Closing this as we are no longer pursuing Swift adoption

#327
post #148

Earlier quoted context omitted.

> Objective-C was created because using standards is contrary to the company culture. What language would you have suggested for that mission and that era? Self or Smalltalk and give up on performance on 25-MHz-class processors? C or Pascal and give up an excellent object system with dynamic dispatch?

C.

And Objective-C is C. A strict superset, in fact.

If

   [aView display];
really, really, really isn't to your liking, you can write

   objc_msgSend( aView, @selector(display)); 
or even:

   objc_msgSend( aView, sel_registerName("display"));
That's pretty much all there is to it. But I have to admit I like the syntax better:

   [aView display];

Re: Closing this as we are no longer pursuing Swift adoption

#328

Earlier quoted context omitted.

C.

And Objective-C is C. A strict superset, in fact. If [aView display]; really, really, really isn't to your liking, you can write objc_msgSend( aView, @selector(display)); or even: objc_msgSend( aView, sel_registerName("display")); That's pretty much all there is to it. But I have to admit I like the syntax better: [aView display];

(Hi mpw)

Re: Closing this as we are no longer pursuing Swift adoption

#329
post #328

Earlier quoted context omitted.

And Objective-C is C. A strict superset, in fact. If [aView display]; really, really, really isn't to your liking, you can write objc_msgSend( aView, @selector(display)); or even: objc_msgSend( aView, sel_registerName("display")); That's pretty much all there is to it. But I have to admit I like the syntax better: [aView display];

(Hi mpw)

(Hi Adam, how's the flying?)
Post reply on HN