Maciej Szarliński

I’ve been thinking a lot about where multiplatform development is heading. With tools like Kotlin Multiplatform becoming truly practical, the expectation to share more logic across platforms is growing fast. Lately I started exploring Rust as a multiplatform option. Rust is usually aimed at C++ developers and systems programmers, but I keep coming back to this question: What if Rust were approachable for mobile developers too? One of the big reasons Rust interests me is its mix of performance and safety. You get native speed without garbage collection or ARC, strong guarantees around memory safety, and the ability to ship the same core module to iOS, Android, desktop, backend, or even WebAssembly without rewriting it per platform. That makes it another compelling option for shared business logic or core components across platforms. Some apps already use Rust as a strong core layer. I'm exploring to see how viable it is for mobile devs to try out, even if it's for a small module rather than replacing a full-blown business layer across multiple apps. I want to see how we can make it less intimidating and more accessible for everyday app developers. I’m exploring this and will share more as I go. If there is enough interest, I’ll go deeper. I'll share my findings on https://lnkd.in/emVy_hFv

97

15 komentarzy

What I find interesting about the addition of GenAI to the development toolset is that we seem to be speed running through the history of ideas in software development, only with a new tool. - Let’s just vibe code - maybe not that seems to have a high failure rate (software crisis) - Let’s write clear specifications to help us succeed (documentation driven methodologies) - Let’s work in small batches, as opposed to writing a detailed specification for everything and steer based on feedback (RAD and agile emerge) And we are revisiting older coding strategies: - Code Generation (and running into the realisation that more LOC is more bugs, more complicated and frameworks can fix that) - Outsourcing- can we just write a specification and outsource that to cheaper resources [GenAI] and accept lower quality (depends on purpose and feedback loop, see above). Now, I don’t disagree that we should revisit how we work when a potentially transformative technology arises. Old assumptions may not hold true. But a couple of points stand out for me at this stage: - If you don’t have experience of this journey, it’s worth understanding why decisions (short feedback loops, work in small batches) emerged. You may be able to leapfrog some expensive lessons. - There are reasonable challenges to concepts like disposable code derived from our past experience with code generation and outsourcing. It is reasonable to ask what has changed. - We have yet to disprove Brooks that there is no order of magnitude improvement in productivity from changing how we develop software. The elusive nature of productivity benefits from GenAI may be because the true gains are not in optimising that loop. But the message that we have to do the hard work on what Accelarate tells us to improve productivity, may not be as easy as we can use GenAI to fix it. I get that. It is easy to become captured by the excitement - playing with GenAI can seem magical and fun - but our process looks very haphazard right now. We can learn from our past.

246

23 komentarze

Have you heard about "Declarative Gradle"? Gradle is experimenting with a new Declarative Gradle configuration model, designed to let you describe what a project needs in clear, concise terms while still allowing advanced build logic where necessary. Why the change? Gradle realised its current configurations can feel like a maze. They want every developer to configure projects in a fast, crystal‑clear, intuitive flow – while still leaving room for pros to perform advanced build magic when needed. How does it help you? Focus on declaring your project’s intent, not stitching together imperative tasks. Enjoy lighter, more readable files that newcomers (and future you) can grasp in seconds. Drop back to Kotlin DSL whenever you need a custom twist. The feature is still experimental. But once it graduates, everyday Gradle work should feel much smoother and more manageable.

59

4 komentarze

Common overengineering pitfalls to avoid: 1. Building an entire framework for simple tasks that may not require future automation. Start small and extend from that. Generalize and automate only when there's an actual need. 2. Creating excessive abstraction layers for straightforward workflows.  Abstracting isn't always good. It has its merits in certain cases, but as with everything, you can overdo it. Simplicity has the advantage of being easy to understand and quick to grasp. If you can keep it simple, there's no need to add additional layers of abstractions just because it's supposedly 'best practice'. 3. Premature scaling: implementing fully-fledged solutions before prototyping.  You probably want to start from the prototype. Get early feedback. Iterate from this. It will help you validate the usefulness of your solution faster. 4. Adding unnecessary features for improbable edge cases.  If you catch yourself adding features that don't have an immediate or clearly scoped need, stop. There's 90% chances that you waste your time and add useless code which later everyone will have to maintain. Anything I missed? I'd love to know your perspective!

102

25 komentarzy