Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Closing this as we are no longer pursuing Swift adoption

github.com

Post reply on HN
Print view View original

111–120 of 332 posts

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

#111

Post by josephg »

rvz wrote: post #83
bergheim wrote: post #54

Earlier quoted context omitted.

I so wholeheartedly agree. You are making a new web browser - akin to a new OS - and you want it open source for everybody but you choose swift not rust?

This experiment has shown that both are actually bad choices.

Oh? They tried rust?

Lots of people seem really committed to OOP. Rust is definitely a bad fit if you can't imagine writing code without classes and objects. I don't think this makes rust is a bad language for the problem. Its just, perhaps, makes rust a bad language for some programmers.

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

#112

Post by pbohun »

jervant wrote: post #90
pbohun wrote: post #77

Earlier quoted context omitted.

People are correct I didn't explain my position. LLVM: Pretty much everyone who has created a programming language with it has complained about its design. gingerbill, Jon Blow, and Andrew Kelley have all complained about it. LLVM is a good idea, but it that idea was executed better by Ken Thompson with his C compiler for Plan 9, and then again with his Go compiler design. Ken decided to create his own "architecture…

How many languages are using LLVM as its backend vs Go's?

As far as I know, only Go uses Go's back end because it was specifically designed for Go. But the architecture is such that it makes it trivial for Go to cross compile for any OS and architecture. This is something that LLVM cannot do. You have to compile a new compiler for every OS and arch combo you wish to compile to.

You could imagine creating a modified Go assembler that is more generic and not tied to Go's ABI that could accomplish the same effect as LLVM. However, it'd probably be better to create a project like that from scratch, because most of Go's optimizations happen before reaching the assembler stage.

It would probably be best to have the intermediate language that QBE has and transform that into "intermediate assembly" (IA) very similar to Go's assembly. That way the IL stage could contain nearly all the optimization passes, and the IA stage would focus on code generation that would translate to any OS/arch combo.

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

#113

Post by stephc_int13 »

TbobbyZ wrote: post #94
stephc_int13 wrote: post #79

Earlier quoted context omitted.

The best tool for the job is the one you know and love.

I have not developed a deep love for a language yet. Swift has been interesting me, but so has Zig.

Then you should consider Lindy effect. Newer languages have counter-intuitively a shorter life expectancy than older ones.

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

#114

Post by diath »

drnick1 wrote: post #106

Regardless of the language it is written in, one thing that I hope Ladybird will focus on when the time comes is a user-respecting Javascript implementation. Regardless of what the Web standards say, it is unacceptable that websites can (ab)use JS against the users for things such as monitoring presence/activity, disabling paste, and extracting device information beyond what is strictly necessary for an acceptably fo…

There's just too many defense mechanisms on popular websites that would simply make Ladybird flagged as a bot and render the website unusable. I wouldn't mind a toggle to switch between this and normal behavior but having that as a default would be bad for wider adoption.

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

#115

Post by carefree-bob »

refulgentis wrote: post #105
carefree-bob wrote: post #81

Earlier quoted context omitted.

Not just LLVM, but Google's TPU seems to be doing fine also. Honestly it's an impressive track record.

He had 0 to do with the TPU. I was hired around Google around the same time, but not nearly as famous :) AFAICouldT it was a "hire first, figure out what to do later", and it ended up being Swift for TensorFlow. That went ~nowhere, and he left within 2 years. That's fine and doesn't reflect on him, in general, that's Google for ya. At least that era of Google.

Ahh, thanks for the info. Yeah, I heard Google was a bit messy from colleagues who went there.

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

#116

Post by satvikpendem »

hippo22 wrote: post #86
bunderbunder wrote: post #52

Earlier quoted context omitted.

For what it’s worth, ObjC is not Apple’s brainchild. It just came along for the ride when they chose NEXTSTEP as the basis for Mac OS X. I haven’t used it in a couple decades, but I do remember it fondly. I also suspect I’d hate it nowadays. Its roots are in a language that seemed revolutionary in the 80s and 90s - Smalltalk - and the melding of it with C also seemed revolutionary at the time. But the very same featu…

Many of the built-in types in Objective C all have names beginning with “NS” like “NSString”. The NS stands for NeXTSTEP. I always found it insane that so many years later, every iPhone on Earth was running software written in a language released in the 80s. It’s definitely a weird language, but really quite pleasant once you get used to it, especially compared to other languages from the same time period. It’s truly…

Well, there are many more devices running on a language written in the 70s.

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

#117

Post by diath »

stingraycharles wrote: post #91
jll29 wrote: post #87

Earlier quoted context omitted.

Andreas Kling said Rust lacks OO, which he says is useful for GUI coding. He even made an attempt at creating his own language, Jakt, under SerenityOS, but perhaps felt that C++ (earlier with, now without Swift) were the pragmatic choice for Ladybird.

But wasn’t Rust designed specifically for being a language for developing a rendering engine / web browser?

Rust initially started as a hobby project of a person who happened to be a Mozilla employee and later got sponsored by the foundation however it was not a language that was specifically designed with browsers in mind.

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

#118

Post by WD-42 »

truncate wrote: post #109
iLemming wrote: post #50

Earlier quoted context omitted.

> Swift never felt truly open source either. Apple has been always 'transactional' when it comes to OSS - they open source things only when it serves a strategic purpose. They open-sourced Swift only because they needed the community to build an ecosystem around their platform. Yeah, well, sure they've done some work around LLVM/Clang, WebKit, CUPS, but it's really not proportional to the size and the influence they…

>> some teams are just not permitted to contribute to OSS in any way My understanding is that by default you are not allowed to contribute to open-source even if its your own project. Exceptions are made for teams whose function is to work on those open-source project e.g. Swift/LLVM/etc...

I talked to an apple engineer at a bar years ago and he said they aren’t allowed to work on _anything_ including side projects without getting approval first. Seemed like a total wtf moment to me.

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

#119

Post by valenterry »

stephc_int13 wrote: post #79
TbobbyZ wrote: post #65

Earlier quoted context omitted.

What language do you recommend?

The best tool for the job is the one you know and love.

By that definition you will be stuck on the first language you love.

And someone will be stuck not to do anything because they are unsatisfied with all languages. :-)

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

#120

Post by diath »

meisel wrote: 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.

> Why did Ladybird even attempt this with Swift, but (I presume) not with Rust? I

Probably the same reason why Rust is problematic in game development. The borrow checker and idiomatic Rust do not go well together with things that demand cyclic dependencies/references. Obviously there are ways around it but they're not very ergonomic/productive.

Post reply on HN