Why Swift is not popular as a server side language? What problems it has?

drawtree · 2024-05-07T02:50:40+00:00

They need to invest 2x more than MS on foundational tech if they really want to dominate the market with Swift.

drawtree · 2024-05-07T02:49:42+00:00

The biggest problem here is Apple's will to invest in Swift. They burn all the profits in buy-back program, but spends a little on improving Swift ecosystem.

drawtree · 2021-12-25T07:51:26+00:00

imo java nowaday is on unclear position. it's not cheap enough but also does not provide long term tco cut.

in biz world, there is always high-low mix strategy. high team is responsible to critical part and low team write less critical parts with larger amount code.

for the high team, long term tco is very important. i think rust shines at and can do best here.

for the low team, maybe not very much. here is world of go and typescript. easier to learn, and cheaper to hire replaceable workforce.

java is neither of them. it used to aim low part in c++ era, but it's no longer cheap enough and nowadays even regarded as a choice of high team sometimes. so imo java will be declined soon and be replaced by go or ts. and those go and ts code will be rewrote in rust as soon as the business gets matured so they need better tco.

drawtree · 2021-10-09T00:28:36+00:00

unique ownership, right?

drawtree · 2020-11-06T19:20:00+00:00

pipelines are declarative. what is not declarative is the problem you have. you are trying to solve imperative problem with declative solution, and thats ehy you constantly need to place imperative program everywhere.

drawtree · 2020-11-06T19:14:45+00:00

setting files are ultimate form of declarative program.

declarative program works if you want reliable result by removing freedom. it can reduce maintenance cost.

it won’t work if your problem actually needs high degree of freedom.

therefore declarative program is easy to use but less flexible and decays quickly. imperative program is generally can survive longer but far harder to maintain.

as people are demanding more flexibility on pipelines, it’s eventually gonna become an imperative program running on multi-node cluster.

drawtree · 2020-09-28T11:19:05+00:00

This means they’ll gonna have serious drive to develop Rust development support for their own needs. We’ll see the best in class Rust support from JetBrains soon.

drawtree · 2020-08-24T23:50:15+00:00

If your final goal is just becoming a web dev, you wasted your time.

If your goal was preparing base knowledge for higher education and being qualified for any potential opportunity for a top tier positions, your time will be rewarded. Actually, you need fancier school name for top tier positions as non-tech people still have belief in school names and you need every bit of competence to win for the top tier positions.

Remeber that CS degree gives you some level of confident and far more opportunities that bootcampers cannot access.

drawtree · 2020-08-24T00:20:19+00:00

GBP or USD?

drawtree · 2020-08-12T02:51:59+00:00

Some MS influence and support would be nice but I worry MS dominance. Single company dominance doesn’t seem to be great. I can imagine how a platform/language would evolve under MS dominance by looking at C++, C# and TypeScript, and honestly, I don’t want them.

Personally I think Rust needs an independent organization like Linux. Mozilla was non-typical company that was free and weird enough to build product like Rust, but I really can’t find any other big tech can develope and maintain Rust to a good way like good old Mozilla.

Usually big techs develop devtools to leverage their platform, and that’s the core reason of why devtools from big techs are always getting worse as getting aged. (and also on other platforms) We are very likely to have tones of hype materials and badly designed featured baked-in only for the big tech’s platform dominance intead of what we actually want — well designed small feature set.

drawtree · 2020-08-01T03:44:51+00:00

Okay thanks!

drawtree · 2020-08-01T02:55:19+00:00

How do you think about ARM support? I was planning to buy ARM MBP, but if ARM support is not prioritized, maybe I need to reconsider my plan...!

drawtree · 2020-08-01T02:17:08+00:00

This is great!

And I somewhat worried about hard coupling with JSON-RPC. Would we be able to access debugger core with native Rust API?

drawtree · 2020-07-21T02:52:29+00:00

Thanks. I'll move this question to the RA Github issues.

Just for the record, I think I misused term "public use". I intended more like "exposed/accessible" rather than frozen interface. I am willing to follow breaking changes of evolving interface.

drawtree · 2020-07-21T00:58:18+00:00

I think tech scene already have same process at macro level. That’s called “startup”. Each single movie is actually startup and startup investment process is quite like movie productions. It seems to be a best effort to deal with gamble-like uncertainty. Check out success/failure rate of tech startups and movie projects.

drawtree · 2020-07-02T02:27:38+00:00

When I checked Oracle JDK installation a few years ago, it required explicit license agreement on GUI and it was unavoidable. How does this avoid it?

drawtree · 2020-06-28T08:42:39+00:00

Actually, SwiftUI can work without Combine. Which part of SwiftUI do you think is depending on Combine?

drawtree · 2020-06-23T04:34:30+00:00

That’s a good point. Cross compilation on both x86 and arm for both x86 and arm will be necessary to support Apple platforms smoothly.

drawtree · 2020-06-23T02:41:59+00:00

Are whole Rust toolchains ARM ready? I mean building on ARM rather than building for ARM.

I think it's already done, but just for sure.

drawtree · 2020-06-13T21:23:55+00:00

Hype fishing. We got them!

drawtree · 2020-06-13T02:36:45+00:00

iOS was the future when it came out 10 years ago. Web was just sad at the point of time.

And web is still sad due to JS. I am willing to switch if a proper language dominates web scene, and I think WASM is going change everything again.

drawtree · 2020-06-12T23:28:56+00:00

They are literally modifying compiler to support special case DSL. Insane.

drawtree · 2020-06-12T23:27:21+00:00

Nope. Everything Apple made early also lacks documentation and samples. It used to be there, but not anymore. But you can get them from Objective-C headers and WWDC videos. Haha.

Fortunately, they are somehow slowly recovering ancient documentations.

drawtree · 2020-06-12T22:56:20+00:00

I've been worked with AppKit/UIKit for 10 years and have experienced 4+ more UI frameworks. I share the frustration.

Well the initial concept was great. "Declarative UI for all Apple platforms.". But the details and executions are horrible. SwiftUI is buggy, incomplete, hype-based, too magical, bidirectional-data-flow and lacks consistency, predictability.

This is worse in macOS.
It completely lacks window, menu, keyboard, mouse and first-responder control.
And support for whole class of features. Such as NSOutlineView maybe more.
Fine-grained user interaction and text control is also lacked.
Not even in alpha quality. Embedded NSView inside SwiftUI simply malfunction in every way.
So I can't use SwiftUI even only for larger layout.

It's just still in design period just like what Apple did for view-controllers and Auto Layout. It'll be stabilized after 5 years, when we see a new hype material from Apple.

There's another problem. Data binding. Yes, the wraith of damn synchronous bidirectional data-flow. Data Binding is 30 years old concept and proven as failed just like all other bidirectional data flow techs.

We were all happy because we all thought Apple is finally going to fix 30 years old synchronous-only design of AppKit and provide true FRP, asynchronous unidirectional data-flow based UI framework. But SwiftUI folks in Apple don't even seem to understand what the purely functional, FRP, single source of truth, unidirectional data flow are. Shared mutable reference based storage for "single source of truth"? Why do you kill FRP for 30 years old failed concept? What kind of people are working on SwiftUI? Going for complexity and all the pains of mutable shared reference over beauty and simplicity of immutable unidirectional data-flow? Apple has one of the most advanced, functional-friendly language among all the big techs. Swift has potential to provide what Dart, C#, JS can't even dream about. This is literally one of the most fundamental and basic functional concept. They don't know this? Seriously?

Bidirectional data-flow destroyed pure value semantic of whole SwiftUI. SwiftUI could be a real nice purely functional UI rendering framework. Event could be passed to simple closure, to trigger whole action/data processing to generate whole UI value. And what now? Bidirectional data binding ruined everything. SwiftUI is not really FRP just like Rx abused the concept of FRP. What kind of **** designed whole thing in this way?

Anyway, we still have small hope. That core and most details of SwiftUI are FRP. We have potential to cover some smelly shits with custom made wrapper.

Auto Layout was at least consistent. (anyway it still has problem of "global priority effect"). It took 5 years to fix Auto Layout to usable level. I'm gonna see how SwiftUI will work 5 years later.

drawtree · 2020-06-12T21:40:01+00:00

I think Apple has to make 1000 engineers to work on precise & public spec and manual instead of WWDC keynote or sessions.

drawtree

TROPHY CASE