I started using Elixir last year after being a long-time Python dev.
Apart from the pros of using a niche language as espoused in the OP write up, the downside I see can be the lack of community, 3rd party libraries and tools and lived experiences which could be discouraging.
I think Elixir falls into the same category of Clojure when it comes to "niche". However, my experience with Clojure is that the community is small but tight-knit: you can usually easily reach library authors in case there are issues and discuss things on Clojurians Slack. The libraries usually adhere to "don't break" like Clojure itself and when there isn't a library for a specific problem, you can drop down one layer to the host system where there is usually a library for everything (Java, browser, Node.js, ...). So although Clojure is fairly niche, you can use a wide array of mainstream libraries to solve problems.
My experience with Elixir has largely been the same, to be honest. I’ve managed to speak with lots of well known library authors just by messaging them on the elixir slack. The creators of the language and the dominant web framework, Jose Valim and Chris McCord respectively, are well known for popping in on threads, conversations, and GitHub issues all over the place.
Elixir libraries are also pleasantly backwards compatible in my experience (with the occasional exception to be sure). At my company the effort required to maintain currency has been 1/10 that of Ruby in my experience.
I frequently hear that elixir lacks the 3rd party library support of Ruby. If you use sheer quantity as the criteria, then definitely, but in the 6 years I’ve been using Elixir, this has interestingly never gotten in my way. I’ve always either been able to find a library or the problem simply isn’t gnarly enough to deserve a library. Maybe I just haven’t picked the right problems with which to experience this lack though :).
All that to say I think Elixir and Clojure are very similar in these regards!
I chose Elixir over Clojure simply because the web development story is better (in my opinion) due to the community rallying around Phoenix. I preferred the Lispiness of Clojure but all you have over there is Fulcro and Luminus, the former is far, far too complicated and niche, while the latter is just curated libraries.
Erlang is definitely more niche than elixir at this point. Too many well-known companies use elixir: discord, pagerduty, Weedmaps, Boston MBTA, apple, etc.
Program PowerPascal;
{$X+}
{
Who: Michael Warot
When: November 12,1989 (my 26'th Birthday!)
What: The beginnings of a language compiler,
takes source from STDIN, and generates
Assembler Source for STDOUT
}
pp002.zip Power Pascal v0.002 (c) 1993 by Mike Warot
Its a very old OS2-oriented Pascal compiler.
Source: .pas (Borland Pascal)
Output: .asm (32-bit => Masm 6.0 + Link386 = > lx .exe)
Documentation: comments in English
Another benefit of legacy niche languages, such as Perl, is less ageism. Clojure is a real joy to work with. Ruby is in an interesting phase approaching niche status with correspondingly high rates.
> Ruby is in an interesting phase approaching niche status with correspondingly high rates.
native iOS in objective-c is getting there too, I think. I see a lot of job listings for it with surprisingly high rates considering everybody is supposed to be shifting to Swift.
You haven't been looking at all! Most large companies that pay pretty well still use Objective-C. Meta, Google, Snap, Netflix... etc... and of course Apple.
The others do still have lots of Objective-C, mixed with Swift (eg. Linkedin, Reddit, etc, slowly transitioning to Swfit).
Airbnb and Uber are the only one that use mostly/exclusively Swift from the Faangmula companies. Most small Startups, that were started after 2016 use mostly/only Swift, but most large companies still do have a lot of Objective-C code.
Yeah, Perl - thats my niche language.
Most interviews are like, 'You know Perl right ?' followed by 'When can you start ?'.
And even though the number of openings is small, the pay is good enough to overcome few weeks/months of unpaid vacation if needed ;)
My first internship was trying to figure out all the Perl scripts left behind by a sysadmin who got fired. I learned a lot that summer. I really learned to like Perl after writing my own programs in in, and making sure to document them well!
I was flabbergasted once to see Perl rates right up at the top with Clojure and Scala but I suppose Perl's a bit like COBOL these days in that only greybeards still work with it.
I wonder if Python has yet reached legacy status when it comes to web development. A quick skim of the schedule for this year's PyCon US suggests that maybe it has.
Perl aficionado here! Thanks to Amazon, the cool new replacement for Perl seems to be Python, even though it’s only about 4 years younger, so most younger devs I know aren’t even aware of Perl’s existence. While Perl may not be used in too many legacy Enterprise applications, it certainly is the “glue” of many legacy systems. Plus, every once in a while I get to dust off my Perl skills and wow my colleagues with how easy it is to do file I/O and regex in just a few lines with no libraries. It certainly gives me a skills advantage.
>"Thanks to Amazon, the cool new replacement for Perl seems to be Python,..."
Interesting, is it Amazon as in AWS that make heavy use on Python then? If so I'm curious is this for specific areas within AWS? I always imagined AWS to be lots of systems programming languages.
Yeah, there all sorts of niche languages out there. Back in the 1980s there were lots so-called "fourth-generation languages" - 4GLs out there. Two that I used were SeaChange, which was for Unix & MSDOS - see https://techmonitor.ai/technology/seachange_launches_seachan... and Nomad/2 on IBM mainframes - see https://en.wikipedia.org/wiki/Nomad_software. Both were quite capable (particularily Nomad) and you could earn quite a bit of change if you knew how to use them.
Oh, and while I'm thinking about it, knowledge of how to program a Transaction Processing Monitor) will rarely go amiss.
The essential idea is apparently to have a central server which does not know your application code directly, spawning workers—application code processes with some communication protocol. The supervisor can then have better uptime guarantees because it doesn't crash when application code crashes. With some more tweaking (what tweaking exactly?) the supervisor is able to enforce transactional consistency: if a worker crashes, we can roll back any partial updates it was doing. Is that about right?
Would be interesting to know about your “how to program” comment in greater detail. Do you mean just the idea of buffering client connections and maintaining a worker pool? Or is there some hard problem around transactionality that needs to be solved and a particular perspective for it? Both? Neither?
The last TP monitor I used definitely had a programming API, but I'm afraid that I've been retired from programming for so long now that I can't remember how I used it :-( You definitely had write code (or at least config files) to tell the thing what sort of transactions to monitor.
Tuxedo is a good example of this type of system. Code interacting with Tuxedo generally written in Cobol but libraries would be available in other languages like C.
To start to understand this, think of a world where
* http and webservers do not exist
* sql and databases do not exist
* ram is measured in kilobytes
* storage measured in megabytes
* there is network connectivity but tcp/ip is not pervasive and there is no dns
* files exist and there are myriad wonderful binary data storage formats
There are so many other weird things but best just to dig into the docs:
Haha, memories. In my first internship I left a great impression by picking up a 4GL that was used for some backend stuff and nobody in the team knew (other than how to trigger pre-defined jobs through a UI). Built a few nice things with it, but boy, it was limited.
>Anyway, this is all to say that being a niche programmer is not bad at all. Pay is great, competition is low and the interview processes for the most part very humane
This is NOT true of all niches. The pay will only be great if the demand for programmers in that niche is high.
That's true, perhaps I should've clarified that in the article. There's a lot of languages out there that are very niche and have virtually no jobs for them (especially very new languages), so some market research is of course required before deciding on one.
It would be great to have a website where you can see, more or less accurately, the ratio between niche jobs and niche programmers for a specific language.
Indeed. Niche is a fairly large umbrella. If no other shop is using the technology you work with, nor wants to, then what would they want from you? At best you could argue "transferable skills" - but since they can otherwise get someone with all the experience on their checklist, your competitive value is nil. Should you be an exceedingly niche programmer, you're valuable because you're more difficult to replace. Leaving is also difficult, so there is the balance.
Unfortunately it's not always the case - at least not with Ruby (which I consider somewhat nichy). My experience is the Ruby job interview is just like any other algo/Leetcode type interview - in 90% of interviews they don't bother testing my Ruby knowledge (very likely the interviewer doesn't really know Ruby that well). Maybe 2 companies out of 15 had actual Ruby questions.
So maybe Ruby is not niche enough or the hiring company thinks it's no problem teaching someone Ruby, idk. But I'm surprised again and again how little companies care about my actual experience. It's all algo questions or something about deployments/Kubernetes.
I'm a developer who mostly works with Python and I recently interviewed for a position that seemed to mostly involve Ruby on Rails. I was genuinely excited about working with Ruby, but the interviewer said they are struggling to hire Ruby developers and they are now hiring Python developers instead. It seems to be niche enough that small companies can't afford it.
Ruby is very much main stream. Any non-programmer business type who wants to start a startup immediately think it should be in Ruby or Python because that's what he think is the most popular thing.
It's not niche like Clojure but nowhere near as mainstream as Java/Python. It's somewhere in the middle - maybe about the same adoption as Kotlin/Swift or something like that. I guess you can define it as semi-popular?
Not denying that just venting my frustration with the current tech interview ... but the Stoic in me thinks maybe its time I stopped complaining and just accepted it.
100%
My company is in the process of switching from niche language to Python.
The problem is that niche language was a good proxy for "people who have been in the industry / have a lot of domain knowledge / etc".
So our hit rate with the Python dev interviews is like 1/10th of what we had with "niche language" so yes mainstream devs are easier to find, but they are 10x as hard to filter. Further the original excuse was that niche language devs were expensive, but by the time we find a python dev who actually has any domain knowledge & experience, we are paying the same.
Would it be feasible to lower the hiring bar and set things up so that your company can use some of those plentiful, less experienced, less expensive developers to do some of the straightforward gruntwork that comes with any project? I suppose that's harder to do with Python than it would be with a statically typed mainstream language like Go or Java, since a static type system provides another way of guarding against mistakes. But maybe Python with enforced type annotations as part of the CI process would be good enough.
My hypothesis is that not all tasks in a software project require the same level of skill or domain expertise. Context: I'm the technical cofounder and (currently) sole developer of a tiny company developing SaaS applications. The core of these applications definitely does require my domain expertise. But other things, like the purchase UI and account administration, just require one or more programmers with adequate skill and a strong, reliable work ethic to deliver (and maintain!) good enough implementations. Perhaps this suggests a two-language approach for such applications, with the domain-specific core being written in a more niche language. But polyglot projects bring their own complexity that makes it harder to eventually hand off maintenance.
A lot of the "lets just hire lots of grunts" mentality implies someone is going to do a lot of the other work - talking to users, documenting requirements, creating well specified dev tickets, implement SDLC tooling, integrate with SRE, create guard rails, do documentation, testing, code reviews, style guides, etc.
Which is to say - most of the stuff you expect a senior to just be able to do as part of their job while also writing better code.
A large enough org may be able to offload much of those tasks to dedicated people and/or teams. Similarly a mature enough platform could have lots of BAU dev that can go to grunts because the basic infrastructure already exists and the workflows are well known with good tooling.
So it really depends on organizational size & maturity if its a good trade.
Sure and in a way we ended up doing some of that bar-lowering.
However we could have done the same on the old niche stack which is what I used to do elsewhere. Instead of generic python devs 2-3 years out of school with 0 domain knowledge getting 50% more than starting grad salary.. you just hire new grads, teach them the niche tech & domain knowledge at once. Plus side is they are trained in "your way" and there's less retraining.
But either way, grunts depend on the lifecycle of the product.
You bring in grunts to run the plant once you've built it.
When you are in the process of building the plant you have a lot of dev work you want experienced (domain & tech) seniors doing. Foundational decisions and implementations that come from having some scar tissue in the tech & domain. Throwing grunts at the problem early will just allow you to re-implement your previous mistakes in similar ways.
And yes Python doesn't feel like a great system building language, it will probably be tucked away into the same corner as Perl in a decade or so.
I think it's also good to mention that actual production code is _rarely_ ever about being optimal. Making something that actually works, can be easily understood, and rarely ever breaks is much more important in almost all cases.
There are of course performance requirements for almost any project, but whether your service requires 1 ms or 3 ms in production matters a lot less than whether or not your colleagues can actually understand your code.
I think it's miss leading to think optimization is about cut a Ms or two. The only realistically important optimization is bring you big O down. That and understanding when big O doesn't matter for your problem size.
As a c dev one of the biggest mistakes I see is some optimizing to get better instruction generation but using shifts instead of divides or things of that sort. If you optimizing like that you probably spent more compute time optimizing than your optimization will ever safe. Plus like the complier in C at least handles that for you.
> The only realistically important optimization is bring you big O down. That and understanding when big O doesn't matter for your problem size.
Of course, understanding big O is still very important and being able to apply it to real-world problems instead of just online code puzzles is even more important.
But I think it's importance is a bit exaggerated in the coding community, when there are arguably much more important skills for engineers such as building good relationships with your colleagues, knowing when to cut corners to get work done on a deadline, and knowing how to negotiate salary and promotions.
There's a lot more than big O, like data layout, simd, parallelism, cache efficiency, caching, allocation, data architecture, IO efficiency etc etc. And these are just the ones I know about, I bet there's many more.
For improving performance of larger pieces of code often times it's not really important to talk about big O, but much more about how the data is transformed through the system, how lookups are done in memory, how operations are composed together. Then look at what would be possible in an ideal version of the code, and work towards that in steps. This approach can have orders of magnitude improvements, without changing big O.
If you're starting from scratch, this is much easier. Simply never make your code slow :-)
In fairness, the optimal way (in the limited sense of speed) to solve a lot of stuff in Clojure involves lots of type hints, primitive math and mutable arrays, so you're in a tough situation of trading performance for idiomaticity and looking dumb either way you go.
I was actually expecting to see more Erlang work available. I knew it wasn’t a big language, but nowadays I feel like I’d have a better chance landing a job working on Haskell than Erlang.
I think the problem with less Erlang adoption is that Elixir has a connection with more modern languages and a more forward-looking community (at least in my experience). I wrote Elixir for 4 years until I got my current job, and I never really felt the need to write pure Erlang, so I never learned more than I needed to simply read Erlang code.
Haskell offers something unique in that is a much more academically-modeled functional language. Personally, I like the OTP model better, which then lets you take your pick of a BEAM-compatible language.
I’d say so. My gut says it’s running in 4th place for data analysis behind Python, R and MATLAB. I think it’s strong enough to grow beyond that on the merits, but Mathworks won’t go quietly and both R and Python have strong ecosystems.
What if you really like that niche? That said, with Clojure I can do React.js, Node.js, JVM and, as of recently, even Dart/Flutter development. Within each of those there's a vast array of things that can be done as well, so it really should not get boring anytime soon.
Yeah, cljfx is nice for desktop stuff. The data science ecosystem is actually coming together slowly with the tech.ml ecosystem. Deep Diamond is super clean and fast for low level deep learning stuff. And then you have Babashka which can give you a ton of value around scripting and automation. Really hard to build and scale a team around all this though.
Nice, I remember the initial blogpost but haven't followed progress. There's definitely friction working with JavaFX but you get so much for free. I don't have the aversion many Clojurists seem to have to accepting the bounties of the Java ecosystem, and I've been around long enough to be slightly leery of pure Clojure libraries that fail to reach critical mass (which, if we're totally honest, is almost all of them given enough time).
There are a couple of startups that does use "niche" languages/tech-stack. (the examples I am going to list might be arguable on the description of "niche")
Besides niche languages, there are also niche roles.
For example, Data Engineers and DevOps Engineers are both in low supply and high demand.
I've worked at two companies (Apple and Spotify) that I'm pretty sure I would never have been able to get into as a "common" engineer or data scientist with thousands of other applicants for the same role.
Previously known or associated with terms such as ETL or ELT or data warehousing or ... In my experience tends to be involved heavily with databases, data movement, data modelling. You might think of it in terms of the work that needs to be done before data analysis is possible. Though as with many things in data, labels are imprecise and considerable overlap.
Joke aside, data engineers do a wide variety of engineering work related to data. Often that's around data warehousing and business intelligence, sometimes it's work on big data streaming or storage systems, or building yet another integration for marketing.
The breadth is a challenge, which makes it fun and also hard.
No, you had it right the first time. It's fairly dull, monotonous drudgery. It's not fun , at least for any unconstrained definition of fun, for the majority of work that needs to be done. I speak as someone who does this for a living for over 10 years. I'm in such high demand as an independent contractor I think about starting a consultancy but one of my big concerns is how to recruit people with a high tolerance for blandness, ambiguity, as well as high conscientiousness. I think the subject matter is not difficult but the personal attributes required to persevere and succeed are rare. For me it's been the "muck is brass" career approach.
It's plumbing, but you're also expected to know where the water came from, the exact specifications of the treatment plant that cleaned it, exactly what is in the water down to the parts per billion, and have ideas for what kind of faucet will make everyone trust the water the most.
Also bonus if you know how to run a business and give guidance on what type of house to buy before putting in pipes.
Disclaimer: I'm in the process of making the switch to software development, and I'm from a 3rd world country.
Is there any chance for someone with my profile to get a job in this? Remotely of course, as any remote job would pay times better than anything I could get in my home country. If yes, where does one learn about it more? I see Coursera has some course, but better asking from someone with your experience I guess. My approach to a job is that you do it in order to get money to fulfill whatever you enjoy in life, as long as I'm paid I'll be the best I can. Thanks
Core is SQL + Python (or Java/Scala for the actual Engineering part).
Most of the data warehouse work is data transformation and scheduling, so Apache Airflow and writing DAGs in python is a large part. For some of the larger streaming things you've got Kafka and others.
Also every cloud has it's own stack that is sometimes worth using.
A lot of the time they do ETL/ELT mostly with airflow nowadays.
Some use little more than SQL and if they're lucky something like DBT to template and schedule the queries.
A lot of SQL now runs on data warehouses of which snowflake and Google bigquery stand out, but it's SQL nevertheless.
A few lucky ones get to use Spark which is more interesting as it's written in scala or python, but from my experience 99% of the time businesses are better off training business analysts to use SQL and writing the queries in snowflake.
Another interesting area is real time data, for existing e with Kafka. This can be challenging and fulfilling except a lot of the time businesses people will tell you it's cool but they don't want the data to keep changing so could you please aggregate it every day... So you end up with an overly complicated batch system anyways.
For me the sweet spot of practicality right now is Airflow/DBT/python/snowflake.
> A few lucky ones get to use Spark which is more interesting as it's written in scala or python
If you want a fun language, it's really the wrong place to be.
The work can be very fun, but you must take the fun from data analysis. The best software engineering can do for you is to not get on your way (and SQL excels on this).
I'd say the people working with Spike are the unlucky ones. Because they have to focus more on their tools, and not on the analysis.
Probably pretty easily if you're a good software engineer. I think they don't require as much technical knowledge, though I can only speak on data engineering from first hand experience. A lot of data engineers aren't very good programmers (some use little more than SQL) though there's always outliers.
Yes. These roles are more accepting for self-taught people than most software roles (not saying it's wide open). Anyone can email me (last name at gmail) if they want to chat.
I never thought of myself as a "niche programmer," but, as it turns out, I sort of, am.
I write native UIKit applications, using Swift. No PWAs, no hybrid systems (like React, Electron, or Ionic). I'm pretty good at it. I've been writing Swift, every day, since it was announced in 2014. It's no longer an "edge" language; it is now the baseline, mainstream, native development language for Apple systems, and I'm a fluent speaker.
It means that the apps I write are really small, really secure, really fast, accessible, highly usable, use very few system resources, leverage the latest Apple tech, have almost no external dependencies, work extremely well, and I write them very, very quickly. Also, because they are UIKit, I can get pretty ambitious, as UIKit is a very mature, ship-oriented system. I am looking forward to using SwiftUI, but am yet to be convinced that it is suitable for really ambitious projects.
It's really difficult to find other native Swift developers that work the way that I do. Part of that, I hate to admit, is probably because I'm 60, and I got really sick of sitting in meetups, with a circle of avoidance around me. I have come to understand that I have "cooties." I won't go where I'm not welcome.
But I have also come to realize that an awful lot of apps for Apple systems are written using hybrid systems, and that many folks are unaware that there are Apple app development languages, other than JavaScript.
> the apps I write are really small, really secure, really fast, accessible, highly usable, use very few system resources, leverage the latest Apple tech, have almost no external dependencies, work extremely well, and I write them very, very quickly.
And they're only available for one proprietary platform [1], no? Excluding half of the user base for phones (in the US), and probably much more for personal computers, seems like a really bad business move in many cases. And depending on the type of application, it could be considered a different type of accessibility problem. It's depressing, but so often we have to compromise technical excellence and even user experience for economic reasons; in this case, using a cross-platform technology to develop a suckier app that can reach all host platforms is often the smart business move.
See, here's the deal: I really don't care. I love writing the apps I write, using the tools I use, for the target devices that I target.
I do this for the love of the Craft.
But I completely get you, about the business reasons. I can't, in good conscience, argue against most deployments of hybrid systems.
What is sad, is companies that release shoddy hybrid apps, developed by lowest-bid offshore shops (who often do a better job than onshore ones), then refuse to continue supporting their crapplets.
> What is sad, is companies that release shoddy hybrid apps, developed by lowest-bid offshore shops (who often do a better job than onshore ones), then refuse to continue supporting their crapplets.
The other thing that bums me out about cross platform “solutions” as a fellow UIKit/AppKit dev is their lowest-common-denominator design, making them incapable of the features that make each OS unique and interesting. I’d like to see the opposite approach, where if platform A was missing something that platform B had, the framework would instead fill the gaps and provide that capability on platform A too. At least for me that’d make cross platform development a good deal more pleasant.
As you noted, a robust set of widgets and capabilities out of the box is important too. The miles-long dependency list that comes with the typical JS app stack is unappealing at best, and nothing is worse than having to hunt down an implementation of a widget you need only to find that the 4 options available all have huge holes in functionality in different places, with 2 in some state of disrepair and 1 not being suitable for your project for some miscellaneous reason.
I doubt that this would pose an issue for most bits of desktop software UI. Most UI patents tend to be focused on specific parts of apps (e.g. the Instagram profile page layout), rather than on more broad UI features like toolbars. They also tend to be more focused on mobile UI, desktop UI hasn’t really moved much in the past 20 years aside from cosmetic tweaks.
And, if I cleave to the Apple toolset (as opposed to rewriting it, like I used to), that stuff is sorted. Apple has much better lawyers than I'll ever be able to afford.
Also, I use lots of dependencies. It's just that they are generally ones that I wrote.
What is sad, is companies that release shoddy hybrid apps, developed by lowest-bid offshore shops (who often do a better job than onshore ones), then refuse to continue supporting their crapplets.
Actually, that's not the sad part. The sad part is that Apple, despite being one of the richest companies in the world, basically doesn't care about any attempt to make this situation better, and actually actively works against it.
I work on a cross platform desktop application win/mac, and the process of dealing with OSX development is so frustrating it essentially does not make sense for the size of the user-base. You need Apple hardware to develop. You need an Apple developer account to develop. Xcode is incredibly unstable. C++ support of Clang is out of date. IT management of a fleet of OSX devices is a pain. Notarization and code signing fails regularly due to Apple server downtime. Documentation is horrible, many issues you face must be solved through forum posts where other people shotgun debugged their way out and shared the results. OSX systems are not dependable as long running build servers, frequently causing issues with keychain locks, expiring credentials, volume dismounts, blocking remote access, etc.
On top of that Apple happily blocks any attempt you make at doing cross platform work properly by avoiding support for cross platform APIs: OpenGL is stuck 10 years in the past, and now officially deprecated. Vulkan is not supported. Only supported graphics API is Metal, which is proprietary. WebGL2 support took 5 years to arrive in safari after chrome/ff. WebGPU is likely to follow the same pattern. IOS is locked to a single browser engine. Any attempt to make a webpage behave like an app, works on android but not ios. (example: https://caniuse.com/gyroscope).
Apple doesn't want hybrid apps to work at all, and is busy strangling any initiatives for cross platform APIs. If the browser were invented today Apple would be the first to proclaim a proprietary alternative that would be incompatible and split the world in half. It has created an ecosystem isolated from the world, just the way it likes. As a developer you can learn their ecosystem, and place yourself inside it. However, don't fool yourself into thinking that you are allowing Apple users to use your application, no sir, instead Apple is kind enough to allow you to develop your app for Apple users, and that kindness may expire at any time.
I really cannot understand why a developer would choose to live in such an uncontrollable, closed down, anti-developer system, and even evangelize it.
Apple hates you, why do you love it back? Is this stockholm syndrome?
That wasn’t a bad rant, until the last two sentences.
I do what I do, get the results that I get, and I don’t need to justify it to those that view me with contempt.
A number of years ago, I did take a few months, and learned native Android development (Java, at the time). It was a serious effort, and I spent months, learning the IDE, build system, Play Store, etc. I did publish an app on the Play Store (long since deceased, but I still get Google spam, from it).
I found it to be unpleasant, and returned to the Apple fold. This was nothing against the system. I just didn’t like it.
Aha, I did not intend to be contemptuous to you personally, sorry about that. And you do not need to justify anything to me, my rant is more of the untargeted frustration kind. I understand the desire to work in a straightforward manner that suits you personally, I am just sad the same thing cannot be achieved across all the platforms.
I’m with you. I’m also an iOS (as well as macOS) developer. I started doing Cocoa development a few years before the iPhone came out, when it was much more of a niche than it is now. I’ve never had trouble making a very good living doing it, but I really started and continue to enjoy it because it enables me to create the things I want to create, right through to a polished UI that fits in with my favorite platforms to use.
You could make another app for Android. I think it's an unsettled question that one cross-platform app is a better business move than two independent apps.
There are use cases, where a hybrid system is the most useful path. These are usually cases, where the main product is a server-based service, and the apps are really fairly basic "skins" of the service.
But usability is always reduced, in cross-platform systems. I have been writing cross-platform stuff for decades. Usually, I wrote the Apple part, and another developer wrote the [usually] Windows part. We have tried things like Qt, which is acceptable, but not especially nice.
No matter how much people crow about how hybrid systems are "every bit as good" as native systems; they are wrong.
If you (and/or your users) care a lot about the Quality of the user experience, then native is the way to go. This is especially true, if there are unusual user interface concepts and widgets involved.
No matter how you write it, though, a released software product is a Responsibility. I liken it to having children. Making them is fun. Having them, is less fun. Once they are in your life, you are Responsible for them.
I’m not sure vscode (or JS for that matter) is necessarily slow anymore. I find the potential for speed in the JavaScript world often comes down to good design decisions. vscode performance issues have often been resolved with better design. These days it’s impressively snappy. Of course there are limitations and JS isn’t a top shelf performance language, but for most things with a UI it is pretty good now.
Electron seems to eat a lot of resources, but it can still be fast. I think it tends not to be because the people building stuff with it aren’t necessarily well-versed in writing software. Or perhaps they don’t have the time and resources to make it happen due to constantly shifting business goals, for example.
By all means vscode rarely presents performance issues for me anymore, even on my 2017 MacBook Air. Some things can be slow, but they tend to be specific to extensions and not vscode itself.
This is my experience with using React Native. I commented on it recently in another context, which was that my team of relatively competent people had a surprisingly hard time keeping the build and deployment pipeline happy. It was a lot of overhead. We essentially had to live with knowing we had low confidence in it, and there wasn’t much to do about it.
Anyway, the actual end result was impressive for how much code we were able to reuse, we were able to build it pretty quickly, etc.
But it wasn’t that great in a number of more subtle ways, like in terms of usability as you mention. Accessibility features were missing in some cases. Various behaviours didn’t match the OS quite right, and we couldn’t easily find ways to make it happen. Text handling of all things was extremely convoluted and hard to get right.
You’re right that it suits cases where you want a skin over a more complex back end service. But even then, I’m not convinced it isn’t worth learning to build with native tools.
We’re obsessed with saving time. Every team I’ve worked on that tried to save time was just saving time to build more stuff with corners being cut. It’s rarely actually worth it. Make a few things, do it well, and I bet you’ll see better results than if you build 100 shitty things.
I’m not particularly successful in software so who knows, I’m certainly not an authority.
>I write native UIKit applications, using Swift. No PWAs, no hybrid systems (like React, Electron, or Ionic).
Sounds like a dream scenario. Pure native Apple development is without a doubt the most seamless, intuitive, and enjoyable dev environment I've ever worked with. And libraries like UIKit put anything the JS ecosystem has on offer to shame.
What type of applications do you? Are you contracted or a solo dev?
I tend to do relatively humble apps, most of the time (but I have been working on a pretty damn ambitious social media-style app for over a year and a half. It's still a ways from completion).
Pretty much a solo dev. I'm semi-retired (but work harder than I ever did, when earning a paycheck).
Since 2012, I've had over 20 apps on the App Store, but most have been retired. I think I'm down to three or four. I list them here[0].
I'm in the process of rewriting AmbiaMara[1] (I'll clean up the docs, as it gets closer to release). It's a ways off, but it's coming along nicely.
I've been enjoying Elm for a few years, because it keeps me away from most of the bloat and churn in web UI tech / frameworks, and it's enjoyable (for me) to work in. It really helps to keep my sanity and avoid burnout. Your choice of Swift is really appealing to me... I'm not a huge fan of "apps" in general though. Still, I would guess that Swift will be around for a long time.
I'll add that it helps to be financially sorted (and no longer motivated by trying to become uber rich).
> I'll add that it helps to be financially sorted (and no longer motivated by trying to become uber rich).
Yup. I'll have to admit that I was quite nervous, when I was first being shown the door, repeatedly, upon looking for work at 55, but I've managed to "lean in" to living humbly, and being happy with my work.
It's not an "either/or" choice. We don't need to be a captain of industry, or raking in big bucks, in order to be a highly-relevant, productive engineer. I think that some of these companies were insanely self-destructive, to have ignored me; but, as things have turned out, I'm glad they did. I needed to be pushed out of the nest.
I have been writing systems for all my life. These usually have some kind of a "backend," which could be a device and/or network-connected server, and a "frontend," which is what a user of the system sees and interacts with. In some cases, I designed the backend, and in others, I adapted, or wrote, a frontend to an existing backend. I've written a number of realtime APIs; some of which have lasted for decades. I do good, robust, work.
I've really enjoyed writing software that presents a user interface. Over the years, I have come to enjoy the process of developing a "mental model" of a software system, and presenting it to a user. I come from an artistic background, so making it aesthetically-pleasant is also something that I like.
Here's an example: I'm in the process of rewriting one of my apps; a "speaker timer."[0] Simple enough, and the iOS system already has one, so there's no "burning need" for the app; but it's something that I use frequently, and I'm not so happy with the "stock" one.
But the one that I wrote a few years ago (Actually, it started with an ObjC one, in 2012) is too complex and awkward. It needs a rewrite anyway, because it's "dated," so this gives me an opportunity to "get it right."
I'm just finishing the initial setup screen. This screen is actually a greatly simplified amalgam of three other screens in the previous version. I think it works great. I'm not moving on to the other screens, until I consider this one "done," meaning that it has all the autolayout complete, works on an old iPhone SE, running iOS 14, has all the voiceover strings done in English, and has zero (as in "zed") bugs; even small ones. I use a personal process that I call "constant beta," where the app is always at "beta" quality; although it may be incomplete. This results in astonishingly high Quality, and a fairly predictable ship schedule. It also means that integration testing starts from Day One.
Just this morning, I spent a couple of hours, chasing down a weird bug, that turned out to be an iOS14 issue, on iPhone SEs (the 1st gen). I couldn't get it to happen on any other devices, running iOS14. Even though it was a UIKit bug (that seems to have been fixed, since), and it was on a deprecated OS, on a deprecated hardware platform, I still figured out how to work around it, and fixed the issue in my app (for the curious, it was because a toolbar that is directly attached to the safe area insets of the main view would cause a weird hang, upon rotate).
There's three more screens to go, and each one will receive the exact same level of attention. Once that's done, I'll do the localizations for the three other supported languages, and give it accessibility testing.
All along, it will be tested on devices, ranging from iPhone SE (1st gen), running iOS14, to iPad Pro 12.9 (running the latest iPadOS), and even Macs.
All that, for a $0.99 app. It sells like crap, and no one really cares, but I won't do any work, unless it has this kind of polish.
I'll probably write a Watch app, after I get the main iOS/iPadOS/Catalyst one done. I'd started one, previously.
> upon looking for work at 55, but I've managed to "lean in" to living humbly, and being happy with my work.
Yes, I think this is a really important point. I've discovered over the course of my career that I'm unintentionally very picky with my work. Being in a position (financially) where I'm not forced into work that makes the days feel really really long is amazing.
I love your passion about Swift and UIKit, more power to you! I'm a generalist who spent lots of years trying various cross-platform solutions (Xamarin, C++, RN, KMM etc) and they all fail short when compared to the native apps. XCode sometimes sucks as an IDE but the vertical integration that Apple has is unbeatable.
I love swift but don't do any OS X development and don't want to use XCode. Not sure how the LSP plugin is doing these days but last time I tried it it was pretty unstable (also why can't they have it in the store so you won't need to install manually?). I wish swift for tensorflow had really taken off and put it in a position to compete with python as it's a very enjoyable language.
Sounds like he's still in the apple ecosystem. What i wanted to do was use it for scripting and server stuff (swift for server and Linux) and I think AppCode was not compatible with that at the time.
I got to learn and program Swift at my last job. We needed to integrate a C computer vision library into React Native, so Swift was the answer. I really enjoyed the language. I felt like it gave me a surprising amount of low-level control while still providing high-level abstractions and automated memory management.
There is a new crop of startups that are going full native, and not using things like React Native, and Flutter and other 'xchross platform' frameworks. They are falling out of the trend as they have the same problem that we have had since the Java Midlet times in the 90s, they tend to be: write once, debug everywhere.
So, keep using the native tools as close to the platform is smart strategy on the long term (as fads come and go).
This is awesome. I too work on mobile app development. I started on Java way back where I use Eclipse IDE for Android development. Then the transition to Android Studio, I remember I was an early AS adopter around version 0.8. Then I started Swift also the same as you, around 2014. Then another transition to Kotlin. I am not sure if I'm a niche programmer but I want to stay in this lane until I get old and for me as someone who's approaching 40 this is a little bit worrying. But reading your story is awesome and gave me hope.
I wish I had stuck on with UIKit. SwiftUI has been amazing to build on, and easier than UIKit. The declarative syntax, not worrying about tracking state in the VC, has made readability of views easy.
SwiftUI however has made UI Testing at any level unviable.
> Part of that, I hate to admit, is probably because I'm 60, and I got really sick of sitting in meetups, with a circle of avoidance around me.
Man, this makes me sad. I come from a traditional engineering field; in meetup situations, the old guys were ALWAYS the most popular people around due to the sheer volume of problems they've solved and situations they'd seen. I got to talk to so many people whose names are synonymous with their (admittedly niche) fields (except for Ted Anderson[0], who's pretty well-known in the relevant industries) and learned a ton from all of them.
I guess I'm also sort of a niche developer specialising in web scraping/data extraction. I've been getting some gigs on upwork but been meaning to get off that platform. Does anyone in a similar position have advice on finding clients?
You need to build a service. Like extract data from e-commerce sites, and then provide a search engine with pricing information. Or track new products.
Generally speaking extracting data isn’t the hard part. The hard part is organizing it and presenting it in a meaningful manner.
Definitely! I stumbled upon a happy accident, really. That said, if you'd like to try Clojure for example, quite a few companies are hiring without any prior Clojure knowledge. Though, functional programming experience will definitely help.
Those numbers seem... Odd? Or at least skewed by geography. The typescript number is less than what glassdoor says for junior level JavaScript in my area.
They are median numbers of everyone who took part of the survey, IE worldwide audience. You can check the data yourself to filter for your country here: https://insights.stackoverflow.com/survey
How good is the pay? Fang levels? between 300k and 400k or is it "good" relative to author. Just curious, because if what he says is true I could switch.
Also my job involves writing cuda code... does anyone know if cuda is niche? Def not as niche as clojure but I'm thinking cuda stuff is niche enough to have the properties purported by the author.
I live in Europe and work for a European company and it is near 100k (EUR), which in Europe is (afaik) really-really good. I've also seen Clojure job offers for 150-200k (EUR) here in Europe.
I'm a Machine Learning Engineer, and that seems to check all those boxes. It is niche, it has low offer, and crazy high demand. Sure, salaries are high, but the interview process isn't easier, in fact is way harder. As an MLE I need to excel both as a software engineer (yes, that includes leetcode), and in MLE/science/data science.
For example, the last position I entertained included a phone screen and then 4 rounds: behavioral, coding, machine learning expertise, and a science round, where I was given a problem, had to find 2 papers and make a presentation explaining my approach to solve the problem using the ideas from the papers.
At this rate I'm considering leaving Machine Learning altogether, since the barrier to entry is too high for the people already in.
What exactly do you mean by low offer? I mean, my idea of a niche isn't something that is among the top most popular courses on every MOOC platform. What's a barrier to entry for people already in? You mean for switching employers? What do recommend to get in?
I mean offer as in offer and demand. There isn't many people with the engineering skills, ML expertise and on-the-job experience.
The barrier for entry means that interviewing for the job, even with experience, is very difficult. As others said maybe the different is there is huge demand. Still I find it paradoxical. You'd think having experience in a field with high demand and low offer would be a pretty good deal. And yet it would be easier for me to find a job as a generalist than as an specialist.
My advice to get in is based on my experience so YMMV.
I'd say the easiest way is to transfer internally to an ML position. That's how I got here. If you are a solid engineer, teams are happy to fill in your ML knowledge gaps. Anecdotically most people I interview got to ML the same way. If your company doesn't have official ML Engineer roles or ML projects, you can position yourself to jump in when the opportunity arises, or even pitch a project yourself (leadership seems to be suckers for ML-for-anything).
The second easiest way is as a student/new grad/junior. Expectations for juniors are lower so it's always easier to get in. The ML round of the interview is mostly theoretical so students aren't at a disadvantage.
201 comments
[ 2.0 ms ] story [ 254 ms ] threadI started using Elixir last year after being a long-time Python dev.
Apart from the pros of using a niche language as espoused in the OP write up, the downside I see can be the lack of community, 3rd party libraries and tools and lived experiences which could be discouraging.
Elixir libraries are also pleasantly backwards compatible in my experience (with the occasional exception to be sure). At my company the effort required to maintain currency has been 1/10 that of Ruby in my experience.
I frequently hear that elixir lacks the 3rd party library support of Ruby. If you use sheer quantity as the criteria, then definitely, but in the 6 years I’ve been using Elixir, this has interestingly never gotten in my way. I’ve always either been able to find a library or the problem simply isn’t gnarly enough to deserve a library. Maybe I just haven’t picked the right problems with which to experience this lack though :).
All that to say I think Elixir and Clojure are very similar in these regards!
Not nearly as much as Erlang apparently. I can’t ever bring it up without someone trying to drive the convo towards Elixir
native iOS in objective-c is getting there too, I think. I see a lot of job listings for it with surprisingly high rates considering everybody is supposed to be shifting to Swift.
The others do still have lots of Objective-C, mixed with Swift (eg. Linkedin, Reddit, etc, slowly transitioning to Swfit).
Airbnb and Uber are the only one that use mostly/exclusively Swift from the Faangmula companies. Most small Startups, that were started after 2016 use mostly/only Swift, but most large companies still do have a lot of Objective-C code.
Oh, and while I'm thinking about it, knowledge of how to program a Transaction Processing Monitor) will rarely go amiss.
https://wiki.c2.com/?TransactionProcessingMonitor
The essential idea is apparently to have a central server which does not know your application code directly, spawning workers—application code processes with some communication protocol. The supervisor can then have better uptime guarantees because it doesn't crash when application code crashes. With some more tweaking (what tweaking exactly?) the supervisor is able to enforce transactional consistency: if a worker crashes, we can roll back any partial updates it was doing. Is that about right?
Would be interesting to know about your “how to program” comment in greater detail. Do you mean just the idea of buffering client connections and maintaining a worker pool? Or is there some hard problem around transactionality that needs to be solved and a particular perspective for it? Both? Neither?
To start to understand this, think of a world where
* http and webservers do not exist
* sql and databases do not exist
* ram is measured in kilobytes
* storage measured in megabytes
* there is network connectivity but tcp/ip is not pervasive and there is no dns
* files exist and there are myriad wonderful binary data storage formats
There are so many other weird things but best just to dig into the docs:
https://docs.oracle.com/cd/E72452_01/tuxedo/docs1222/pcb/pbi...
This is NOT true of all niches. The pay will only be great if the demand for programmers in that niche is high.
I have a track record of picking good pls:. I picked ruby (2003), Julia (2009), elixir (2015), and most recently zig (2019) and no others.
So maybe Ruby is not niche enough or the hiring company thinks it's no problem teaching someone Ruby, idk. But I'm surprised again and again how little companies care about my actual experience. It's all algo questions or something about deployments/Kubernetes.
That's going overboard - tons of small companies use Ruby, but yes its way easier to find someone who already knows Python than it is Ruby.
So our hit rate with the Python dev interviews is like 1/10th of what we had with "niche language" so yes mainstream devs are easier to find, but they are 10x as hard to filter. Further the original excuse was that niche language devs were expensive, but by the time we find a python dev who actually has any domain knowledge & experience, we are paying the same.
Throwing more lower-skilled people at a project just makes it move slower and reduces quality.
The median level of skill and conscientiousness (particularly) is just so low.
Which is to say - most of the stuff you expect a senior to just be able to do as part of their job while also writing better code.
A large enough org may be able to offload much of those tasks to dedicated people and/or teams. Similarly a mature enough platform could have lots of BAU dev that can go to grunts because the basic infrastructure already exists and the workflows are well known with good tooling.
So it really depends on organizational size & maturity if its a good trade.
But either way, grunts depend on the lifecycle of the product. You bring in grunts to run the plant once you've built it. When you are in the process of building the plant you have a lot of dev work you want experienced (domain & tech) seniors doing. Foundational decisions and implementations that come from having some scar tissue in the tech & domain. Throwing grunts at the problem early will just allow you to re-implement your previous mistakes in similar ways.
And yes Python doesn't feel like a great system building language, it will probably be tucked away into the same corner as Perl in a decade or so.
Most of the interviewers don't even know to solve those leetcode problems in an optimal way with Clojure.
It might vary if the programming language is not functional.
There are of course performance requirements for almost any project, but whether your service requires 1 ms or 3 ms in production matters a lot less than whether or not your colleagues can actually understand your code.
As a c dev one of the biggest mistakes I see is some optimizing to get better instruction generation but using shifts instead of divides or things of that sort. If you optimizing like that you probably spent more compute time optimizing than your optimization will ever safe. Plus like the complier in C at least handles that for you.
For example, an extra factor of log(n) is hardly ever relevant, constant factors are almost guaranteed to dominate there.
On the flip side, people are also sometimes surprised to see how quickly an n^3 algorithm becomes infeasible even for very modest data sizes.
Of course, understanding big O is still very important and being able to apply it to real-world problems instead of just online code puzzles is even more important.
But I think it's importance is a bit exaggerated in the coding community, when there are arguably much more important skills for engineers such as building good relationships with your colleagues, knowing when to cut corners to get work done on a deadline, and knowing how to negotiate salary and promotions.
For improving performance of larger pieces of code often times it's not really important to talk about big O, but much more about how the data is transformed through the system, how lookups are done in memory, how operations are composed together. Then look at what would be possible in an ideal version of the code, and work towards that in steps. This approach can have orders of magnitude improvements, without changing big O.
If you're starting from scratch, this is much easier. Simply never make your code slow :-)
What about Erlang?
Haskell offers something unique in that is a much more academically-modeled functional language. Personally, I like the OTP model better, which then lets you take your pick of a BEAM-compatible language.
- Amperity uses Clojure ($1bil+ val) - Mercury uses Haskell ($1.6bil val)
I've worked at two companies (Apple and Spotify) that I'm pretty sure I would never have been able to get into as a "common" engineer or data scientist with thousands of other applicants for the same role.
Joke aside, data engineers do a wide variety of engineering work related to data. Often that's around data warehousing and business intelligence, sometimes it's work on big data streaming or storage systems, or building yet another integration for marketing.
The breadth is a challenge, which makes it fun and also hard.
Thankless work so that the analysts can turn on the faucet and get nice clean data for their fancy algorithms and models
Also bonus if you know how to run a business and give guidance on what type of house to buy before putting in pipes.
Is there any chance for someone with my profile to get a job in this? Remotely of course, as any remote job would pay times better than anything I could get in my home country. If yes, where does one learn about it more? I see Coursera has some course, but better asking from someone with your experience I guess. My approach to a job is that you do it in order to get money to fulfill whatever you enjoy in life, as long as I'm paid I'll be the best I can. Thanks
Most of the data warehouse work is data transformation and scheduling, so Apache Airflow and writing DAGs in python is a large part. For some of the larger streaming things you've got Kafka and others.
Also every cloud has it's own stack that is sometimes worth using.
A lot of the time they do ETL/ELT mostly with airflow nowadays.
Some use little more than SQL and if they're lucky something like DBT to template and schedule the queries.
A lot of SQL now runs on data warehouses of which snowflake and Google bigquery stand out, but it's SQL nevertheless.
A few lucky ones get to use Spark which is more interesting as it's written in scala or python, but from my experience 99% of the time businesses are better off training business analysts to use SQL and writing the queries in snowflake.
Another interesting area is real time data, for existing e with Kafka. This can be challenging and fulfilling except a lot of the time businesses people will tell you it's cool but they don't want the data to keep changing so could you please aggregate it every day... So you end up with an overly complicated batch system anyways.
For me the sweet spot of practicality right now is Airflow/DBT/python/snowflake.
If you want a fun language, it's really the wrong place to be.
The work can be very fun, but you must take the fun from data analysis. The best software engineering can do for you is to not get on your way (and SQL excels on this).
I'd say the people working with Spike are the unlucky ones. Because they have to focus more on their tools, and not on the analysis.
I never thought of myself as a "niche programmer," but, as it turns out, I sort of, am.
I write native UIKit applications, using Swift. No PWAs, no hybrid systems (like React, Electron, or Ionic). I'm pretty good at it. I've been writing Swift, every day, since it was announced in 2014. It's no longer an "edge" language; it is now the baseline, mainstream, native development language for Apple systems, and I'm a fluent speaker.
It means that the apps I write are really small, really secure, really fast, accessible, highly usable, use very few system resources, leverage the latest Apple tech, have almost no external dependencies, work extremely well, and I write them very, very quickly. Also, because they are UIKit, I can get pretty ambitious, as UIKit is a very mature, ship-oriented system. I am looking forward to using SwiftUI, but am yet to be convinced that it is suitable for really ambitious projects.
It's really difficult to find other native Swift developers that work the way that I do. Part of that, I hate to admit, is probably because I'm 60, and I got really sick of sitting in meetups, with a circle of avoidance around me. I have come to understand that I have "cooties." I won't go where I'm not welcome.
But I have also come to realize that an awful lot of apps for Apple systems are written using hybrid systems, and that many folks are unaware that there are Apple app development languages, other than JavaScript.
And they're only available for one proprietary platform [1], no? Excluding half of the user base for phones (in the US), and probably much more for personal computers, seems like a really bad business move in many cases. And depending on the type of application, it could be considered a different type of accessibility problem. It's depressing, but so often we have to compromise technical excellence and even user experience for economic reasons; in this case, using a cross-platform technology to develop a suckier app that can reach all host platforms is often the smart business move.
[1]: Well, one platform for each form factor.
I do this for the love of the Craft.
But I completely get you, about the business reasons. I can't, in good conscience, argue against most deployments of hybrid systems.
What is sad, is companies that release shoddy hybrid apps, developed by lowest-bid offshore shops (who often do a better job than onshore ones), then refuse to continue supporting their crapplets.
The other thing that bums me out about cross platform “solutions” as a fellow UIKit/AppKit dev is their lowest-common-denominator design, making them incapable of the features that make each OS unique and interesting. I’d like to see the opposite approach, where if platform A was missing something that platform B had, the framework would instead fill the gaps and provide that capability on platform A too. At least for me that’d make cross platform development a good deal more pleasant.
As you noted, a robust set of widgets and capabilities out of the box is important too. The miles-long dependency list that comes with the typical JS app stack is unappealing at best, and nothing is worse than having to hunt down an implementation of a widget you need only to find that the 4 options available all have huge holes in functionality in different places, with 2 in some state of disrepair and 1 not being suitable for your project for some miscellaneous reason.
Might this be asking for patent trouble, though?
Also, I use lots of dependencies. It's just that they are generally ones that I wrote.
I have control issues, I guess...
Everyone wants to write unique UI, but I've learned that's a trap. I write about that, here: https://littlegreenviper.com/miscellany/the-road-most-travel...
Actually, that's not the sad part. The sad part is that Apple, despite being one of the richest companies in the world, basically doesn't care about any attempt to make this situation better, and actually actively works against it.
I work on a cross platform desktop application win/mac, and the process of dealing with OSX development is so frustrating it essentially does not make sense for the size of the user-base. You need Apple hardware to develop. You need an Apple developer account to develop. Xcode is incredibly unstable. C++ support of Clang is out of date. IT management of a fleet of OSX devices is a pain. Notarization and code signing fails regularly due to Apple server downtime. Documentation is horrible, many issues you face must be solved through forum posts where other people shotgun debugged their way out and shared the results. OSX systems are not dependable as long running build servers, frequently causing issues with keychain locks, expiring credentials, volume dismounts, blocking remote access, etc.
On top of that Apple happily blocks any attempt you make at doing cross platform work properly by avoiding support for cross platform APIs: OpenGL is stuck 10 years in the past, and now officially deprecated. Vulkan is not supported. Only supported graphics API is Metal, which is proprietary. WebGL2 support took 5 years to arrive in safari after chrome/ff. WebGPU is likely to follow the same pattern. IOS is locked to a single browser engine. Any attempt to make a webpage behave like an app, works on android but not ios. (example: https://caniuse.com/gyroscope).
Apple doesn't want hybrid apps to work at all, and is busy strangling any initiatives for cross platform APIs. If the browser were invented today Apple would be the first to proclaim a proprietary alternative that would be incompatible and split the world in half. It has created an ecosystem isolated from the world, just the way it likes. As a developer you can learn their ecosystem, and place yourself inside it. However, don't fool yourself into thinking that you are allowing Apple users to use your application, no sir, instead Apple is kind enough to allow you to develop your app for Apple users, and that kindness may expire at any time.
I really cannot understand why a developer would choose to live in such an uncontrollable, closed down, anti-developer system, and even evangelize it.
Apple hates you, why do you love it back? Is this stockholm syndrome?
I do what I do, get the results that I get, and I don’t need to justify it to those that view me with contempt.
A number of years ago, I did take a few months, and learned native Android development (Java, at the time). It was a serious effort, and I spent months, learning the IDE, build system, Play Store, etc. I did publish an app on the Play Store (long since deceased, but I still get Google spam, from it).
I found it to be unpleasant, and returned to the Apple fold. This was nothing against the system. I just didn’t like it.
But usability is always reduced, in cross-platform systems. I have been writing cross-platform stuff for decades. Usually, I wrote the Apple part, and another developer wrote the [usually] Windows part. We have tried things like Qt, which is acceptable, but not especially nice.
No matter how much people crow about how hybrid systems are "every bit as good" as native systems; they are wrong.
If you (and/or your users) care a lot about the Quality of the user experience, then native is the way to go. This is especially true, if there are unusual user interface concepts and widgets involved.
No matter how you write it, though, a released software product is a Responsibility. I liken it to having children. Making them is fun. Having them, is less fun. Once they are in your life, you are Responsible for them.
A native app is limited by capabilities of the platform. Perhaps Xcode is so bad because AppKit does not quite support the use case.
On the other hand you have VSCode, a slow Electron app, but, by it's nature, really easy to extend.
Electron seems to eat a lot of resources, but it can still be fast. I think it tends not to be because the people building stuff with it aren’t necessarily well-versed in writing software. Or perhaps they don’t have the time and resources to make it happen due to constantly shifting business goals, for example.
By all means vscode rarely presents performance issues for me anymore, even on my 2017 MacBook Air. Some things can be slow, but they tend to be specific to extensions and not vscode itself.
Anyway, the actual end result was impressive for how much code we were able to reuse, we were able to build it pretty quickly, etc.
But it wasn’t that great in a number of more subtle ways, like in terms of usability as you mention. Accessibility features were missing in some cases. Various behaviours didn’t match the OS quite right, and we couldn’t easily find ways to make it happen. Text handling of all things was extremely convoluted and hard to get right.
You’re right that it suits cases where you want a skin over a more complex back end service. But even then, I’m not convinced it isn’t worth learning to build with native tools.
We’re obsessed with saving time. Every team I’ve worked on that tried to save time was just saving time to build more stuff with corners being cut. It’s rarely actually worth it. Make a few things, do it well, and I bet you’ll see better results than if you build 100 shitty things.
I’m not particularly successful in software so who knows, I’m certainly not an authority.
Sounds like a dream scenario. Pure native Apple development is without a doubt the most seamless, intuitive, and enjoyable dev environment I've ever worked with. And libraries like UIKit put anything the JS ecosystem has on offer to shame.
What type of applications do you? Are you contracted or a solo dev?
Pretty much a solo dev. I'm semi-retired (but work harder than I ever did, when earning a paycheck).
Since 2012, I've had over 20 apps on the App Store, but most have been retired. I think I'm down to three or four. I list them here[0].
I'm in the process of rewriting AmbiaMara[1] (I'll clean up the docs, as it gets closer to release). It's a ways off, but it's coming along nicely.
[0] https://littlegreenviper.com/AppDocs/
[1] https://github.com/RiftValleySoftware/ambiamara
I've been enjoying Elm for a few years, because it keeps me away from most of the bloat and churn in web UI tech / frameworks, and it's enjoyable (for me) to work in. It really helps to keep my sanity and avoid burnout. Your choice of Swift is really appealing to me... I'm not a huge fan of "apps" in general though. Still, I would guess that Swift will be around for a long time.
I'll add that it helps to be financially sorted (and no longer motivated by trying to become uber rich).
Yup. I'll have to admit that I was quite nervous, when I was first being shown the door, repeatedly, upon looking for work at 55, but I've managed to "lean in" to living humbly, and being happy with my work.
It's not an "either/or" choice. We don't need to be a captain of industry, or raking in big bucks, in order to be a highly-relevant, productive engineer. I think that some of these companies were insanely self-destructive, to have ignored me; but, as things have turned out, I'm glad they did. I needed to be pushed out of the nest.
I have been writing systems for all my life. These usually have some kind of a "backend," which could be a device and/or network-connected server, and a "frontend," which is what a user of the system sees and interacts with. In some cases, I designed the backend, and in others, I adapted, or wrote, a frontend to an existing backend. I've written a number of realtime APIs; some of which have lasted for decades. I do good, robust, work.
I've really enjoyed writing software that presents a user interface. Over the years, I have come to enjoy the process of developing a "mental model" of a software system, and presenting it to a user. I come from an artistic background, so making it aesthetically-pleasant is also something that I like.
Here's an example: I'm in the process of rewriting one of my apps; a "speaker timer."[0] Simple enough, and the iOS system already has one, so there's no "burning need" for the app; but it's something that I use frequently, and I'm not so happy with the "stock" one.
But the one that I wrote a few years ago (Actually, it started with an ObjC one, in 2012) is too complex and awkward. It needs a rewrite anyway, because it's "dated," so this gives me an opportunity to "get it right."
I'm just finishing the initial setup screen. This screen is actually a greatly simplified amalgam of three other screens in the previous version. I think it works great. I'm not moving on to the other screens, until I consider this one "done," meaning that it has all the autolayout complete, works on an old iPhone SE, running iOS 14, has all the voiceover strings done in English, and has zero (as in "zed") bugs; even small ones. I use a personal process that I call "constant beta," where the app is always at "beta" quality; although it may be incomplete. This results in astonishingly high Quality, and a fairly predictable ship schedule. It also means that integration testing starts from Day One.
Just this morning, I spent a couple of hours, chasing down a weird bug, that turned out to be an iOS14 issue, on iPhone SEs (the 1st gen). I couldn't get it to happen on any other devices, running iOS14. Even though it was a UIKit bug (that seems to have been fixed, since), and it was on a deprecated OS, on a deprecated hardware platform, I still figured out how to work around it, and fixed the issue in my app (for the curious, it was because a toolbar that is directly attached to the safe area insets of the main view would cause a weird hang, upon rotate).
There's three more screens to go, and each one will receive the exact same level of attention. Once that's done, I'll do the localizations for the three other supported languages, and give it accessibility testing.
All along, it will be tested on devices, ranging from iPhone SE (1st gen), running iOS14, to iPad Pro 12.9 (running the latest iPadOS), and even Macs.
All that, for a $0.99 app. It sells like crap, and no one really cares, but I won't do any work, unless it has this kind of polish.
I'll probably write a Watch app, after I get the main iOS/iPadOS/Catalyst one done. I'd started one, previously.
I'm qui...
Yes, I think this is a really important point. I've discovered over the course of my career that I'm unintentionally very picky with my work. Being in a position (financially) where I'm not forced into work that makes the days feel really really long is amazing.
I like getting older because one's preferences, opinions, and control are so much more refined.
Xcode is a bug farm. I would be filled with chagrin, if it were my project, but it's always easy to be a Monday morning quarterback.
It gets the job done.
Wouldn't surprise me a bit, if it could be done with Eclipse (not my favorite IDE).
It's certainly doable command-line.
So, keep using the native tools as close to the platform is smart strategy on the long term (as fads come and go).
SwiftUI however has made UI Testing at any level unviable.
Man, this makes me sad. I come from a traditional engineering field; in meetup situations, the old guys were ALWAYS the most popular people around due to the sheer volume of problems they've solved and situations they'd seen. I got to talk to so many people whose names are synonymous with their (admittedly niche) fields (except for Ted Anderson[0], who's pretty well-known in the relevant industries) and learned a ton from all of them.
[0]https://fracturemechanics.com/
Generally speaking extracting data isn’t the hard part. The hard part is organizing it and presenting it in a meaningful manner.
You can find a list of companies that hire without any prior Clojure experience on this page: https://jobs-blog.braveclojure.com/2022/03/24/long-term-cloj...
The drawback though is that the job market is so small that you have to be prepared to move overseas to have more than a few companies to choose from.
I wish my anecdotal interview experience was LeetCode-less, though :)
Also my job involves writing cuda code... does anyone know if cuda is niche? Def not as niche as clojure but I'm thinking cuda stuff is niche enough to have the properties purported by the author.
I live in Europe and work for a European company and it is near 100k (EUR), which in Europe is (afaik) really-really good. I've also seen Clojure job offers for 150-200k (EUR) here in Europe.
I'm a Machine Learning Engineer, and that seems to check all those boxes. It is niche, it has low offer, and crazy high demand. Sure, salaries are high, but the interview process isn't easier, in fact is way harder. As an MLE I need to excel both as a software engineer (yes, that includes leetcode), and in MLE/science/data science.
For example, the last position I entertained included a phone screen and then 4 rounds: behavioral, coding, machine learning expertise, and a science round, where I was given a problem, had to find 2 papers and make a presentation explaining my approach to solve the problem using the ideas from the papers.
At this rate I'm considering leaving Machine Learning altogether, since the barrier to entry is too high for the people already in.
The barrier for entry means that interviewing for the job, even with experience, is very difficult. As others said maybe the different is there is huge demand. Still I find it paradoxical. You'd think having experience in a field with high demand and low offer would be a pretty good deal. And yet it would be easier for me to find a job as a generalist than as an specialist.
My advice to get in is based on my experience so YMMV.
I'd say the easiest way is to transfer internally to an ML position. That's how I got here. If you are a solid engineer, teams are happy to fill in your ML knowledge gaps. Anecdotically most people I interview got to ML the same way. If your company doesn't have official ML Engineer roles or ML projects, you can position yourself to jump in when the opportunity arises, or even pitch a project yourself (leadership seems to be suckers for ML-for-anything).
The second easiest way is as a student/new grad/junior. Expectations for juniors are lower so it's always easier to get in. The ML round of the interview is mostly theoretical so students aren't at a disadvantage.