28 ms·

Ask HN: When has switching the language/framework made an important difference?

• deleted 9y ago
  [deleted]
• amirouche 9y ago
  I am not familiar with F#. I think it's a functional language, did you take advantage of immutability? What is the main difference between the F# implementation and the C# one (outside less bugs)
  • banashark 9y ago
    F# is a Functional/OOP language. In this case the original code had a class like: class DeliveryItem { public bool isTagged { get; set; } public Deliverer previousDeliverer { get; set; } public Deliverer nextDeliverer { get; set; } public string itemName { get; set; } public DateTime lastTransferTime { get; set; } } The code would take a single DeliveryItem and each time something used it, it would update the properties on it. While not ideal, this worked fine if pipeline was an ordered sequence. The pipeline had grown into a complex graph, with many different possible states, and new properties were incrementally added to shoehorn the new states and transfers between states into the single object. The class grew large and it became difficult to determine from logs what path of the pipeline that an item had taken. It could have been scanned, weight analyzed, compaction determined, etc, etc. And these didn't always happen in the same order because of the business process. Instead I created types like `NewDeliveryItem`, `PreProcessedDeliveryItem`, `ThirdPartyVerifiedDeliveryItem`, etc. It allowed for explicit modeling of the pipeline, since functions could take a `PreProcessedDeliveryItem` instead of a `DeliveryItem` and would know that they wouldn't need to send it for processing. The example has been translated a bit and isn't the best explanation, but gives a small amount of detail. You can check out https://fsharpforfunandprofit.com/series/designing-with-types.html https://fsharpforfunandprofit.com/series/designing-with-type... and https://fsharpforfunandprofit.com/ddd/ https://fsharpforfunandprofit.com/ddd/ to get more information on how this can decomplect seemingly simple applications.
• amirouche 9y ago
  > I'm curious about real world examples where a change has lead to a significant positive outcome in performance, code quality/maintainability, etc. I wanted to build a database in a dynamic language. While others have succeed to do so by layering their DB on top RDBMS (like EdgeDB or Datomic) I went lower level and built a datomic like DB with GNU Guile Scheme using wiredtiger (now mongodb storage engine). The reason for that is that Guile doesn't have a Global Interpreter Lock (GIL). Using the same design in Python would simply not be possible. I did not benchmark, but I don't think it's possible for a single thread DB to be faster than multithread DB. In this chance changing language made the project possible.
• amirouche 9y ago
  > I'm curious about real world examples where a change has lead to a significant positive outcome in performance, code quality/maintainability, etc. Another example: same language, new framework: In a Python web app, we needed to have websockets. But at that time Django had no real websocket support. But there is future proof framework that does: aiohttp! Also one might argue that you can use old django with websocket using another process. But it leads to a more complicated architecture. We want to keep monolith the app as long as possible/sane.
  • swah 9y ago
    Is the Django-websockets story ok now?
    • npolet 9y ago
      Not really. There is the "channels" project which brings it closer to proper websocket capabilities, but it still isn't great to work with. I tried using it for a production project and gave up as I encountered too many issues. Ended up rewriting the app in phoenix as we needed really solid websocket support. Phoenix makes websocket seriously nice to work with and we've found the performance to be quite impressive.
      • swah 9y ago
        That's nice to hear. I'm trying https://github.com/olahol/melody https://github.com/olahol/melody in a smallish project right now, and it seems very promising.
• abeisgreat 9y ago
  The biggest change for me was when I switched to strictly typed languages. It doesn't matter if it's Go or Typescript or whatever. As long as it has types it dramatically improves maintainability and ease of scale.
  • amirouche 9y ago
    what about measurement/profiling
    • banashark 9y ago
      I think measurement/profiling in a case like this is hard. How do you measure maintainability without a large database of bugs, iteration performance, etc. I wish it were an easier thing to do, but I think as far as maintainability and codebase size scalability go, it's hard to quantify properly without metrics that are usually only tracked in enterprises. I'm trying to think about how to make this more clear in the original post.
  • jnbiche 9y ago
    I'll echo this sentiment, although I found Go much more limiting type-wise than Typescript, Java, or other mainstream typed language. But in general, moving from PHP, Python and JS (where I started out years ago) to languages like Java, Flow-typed JS, and even Scala at work have made me realize how much dynamically-typed large projects loose in maintainability vis-a-vis statically-typed projects. Yes, excellent test coverage can help mitigate this, but static types go so much farther when used effectively.
  • brightball 9y ago
    I've never experienced this personally, although I hear it said a lot. I generally work on server side applications with a database behind them and 90% of the work involved is taking data from the client and putting it in the database or the other way around. The database handles actual type enforcement. The requests come in as strings and they are returned to the client in string based format. Introducing types to the server side language has never done anything for me other than making sure that the types are in sync with those of the database while creating a lot of tedious overhead converting data that the application itself might not ever need to process to a particular type. The Elixir gradual typing approach has always seemed like the ideal balance to me.
• taurath 9y ago
  Developer ergonomics is underrated. Having an easy to understand system that has no magic, and in 90% of the work has no dependency chains that you have to hold in your head can really help people avoid bugs by being able to focus on the intent and execution rather than the framework quirks.
  • christophilus 9y ago
    I agree. Do you have a platform/framework that does this for you?
    • marcofiset 9y ago
      Functional programming languages are better at it, simply because there are constraints in place preventing you from having mutable state everywhere.
    • taurath 9y ago
      I have it for some applications. For smaller (<50kloc) services I use node in a functional/immutable style with minimal context objects (too convenient to go full immutable). When you learn the ctx object and the utils module you know how to make almost anything. For larger I'm still looking, but my rule of thumb is to avoid most OOP paradigms and most especially inheritance at nearly all times. Think more in terms of the code state than the conceptual/business state, because when the code state is readable and understandable and low-overhead, it leaves you all the brain space to think about the problemset. No matter what, working on establishing patterns, share them with other people working on the same codebase, and make them better over time - build only enough tests so that you can cleanly refactor whole files, while not bogging everything down in the details. If you are ever afraid of changing a file (except at top level tooling), even in production, you're doing something wrong, because the potential footprint of your changes should be as low as possible.
• wink 9y ago
  Yes, switching something heavy on cpu (mostly real mathy computations) from python 2 to Go - we could keep working eith current number of CPU cores/boxes and not having to like, double our expenses.
  • icebraining 9y ago
    Did you try PyPy?
• sbov 9y ago
  Things like bug count and time to market seem difficult to separate from having more experience as a developer or knowing your problem space better. We use almost all Java, and we have several projects that we did major re-designs of in the same language, which increased maintainability, found bugs, etc. But if I chose a different language, I would have probably attributed it to the new language or framework. Unless you have a problem that fits a specific technology really well, my experience is that your time to market will be minimized by using the tools you know best.
• carsongross 9y ago
  This is more than a little self serving, but when I switched us over to intercooler.js it made a huge difference in our app. When I pulled the trigger on it I was terrified that I was screwing us over by not using Angular (which was the cool tech at the time) or some other more javascript-oriented solution. Thankfully it has worked out well, and my co-founders don't hate me any more than they already did before hand. (And maybe even a bit less.)
  • jonahx 9y ago
    This isn't surprising to me at all. Having the creator of a framework working with a team using a framework is a huge benefit, almost regardless of the framework quality (within reason). And that's not a dig at intercooler's quality (I've never used intercooler, and am no fan of Angular), but I do think it's a huge confound. Meaning, if I had access to creator of framework A on my team, and was choosing between framework A and B, and objectively liked B better than A (but not by too much), I would still choose A.
    • ThrustVectoring 9y ago
      If you like framework B more than A by too much, it seems unlikely to me that you'd have the creator of framework A on your team.
      • jonahx 9y ago
        Really? Was it really unclear to you that I was presenting a hypothetical to illustrate a point and not practical advice?
        • deleted 9y ago
          [deleted]
• dmlorenzetti 9y ago
  Due to the desire to support Windows as a first-class citizen on a project, I've lately moved some support scripts from Bash to Python. These include dependency-scrapers (that assemble makefile rules), and archiving scripts (that back up selected files from selected directories). This has been a big win in terms of the readability of the code, which has in turn made me more aggressive about adding features.
  • jxramos 9y ago
    I have some similar work cut out for a batch file to Python port for a bunch of automation work. It's totally worth it like you say with readability and widening the feature pipeline.
• nickpsecurity 9y ago
  The SPARK people at AdaCore found a bug in the reference implementation of Skein just rewriting it in SPARK: http://www.adacore.com/knowledge/technical-papers/sparkskein/ http://www.adacore.com/knowledge/technical-papers/sparkskein...
  • valbaca 9y ago
    Interesting. And the tl;dr for the bug is: byte_count := (n+7) / 8; When n is near max size, it overflows to a small number, then (small number) / 8 = 0 the fix is to restrict n to [0,MAX-7)
    • jjnoakes 9y ago
      One can do it without restricting the range as well, if the full range of inputs is needed. In C: (n / 8) + !!(n % 8);
      • adrianratnapala 9y ago
        This is correct, and is sometimes necessary, but is a last-ditch save, since as written, it involves a branch. Much better if you can let the n+7 expand to a wider integer type. Or better yet, if you can ensure that it won't overflow in the first place -- which is what they did by restricting the type.
        • jjnoakes 9y ago
          There's no branch required on architectures I'm familiar with. What branch do you refer to?
        • einmaliger 9y ago
          My x86-assembly has become very rusty, but couldn't it work like this, not using a branch: (with eax being the unsigned 32-bit input word) xor ebx, ebx test al, 7 stnz bl shr eax, 3 add eax, ebx (edit: replaced a movzx with an xor)
• dmlorenzetti 9y ago
  A few years ago, I rewrote an `R` script into Fortran, for better than order-of-magnitude speed increase. The script optimized the placement of samplers in a building, in order to maximize the probability of detecting airborne pollutants, or to minimize the expected time required to detect. The rewrite cut the runtime down from 2-3 days to sub-hour. Some of the speedup was intrinsic to the interpreted/compiled divide. However most of the speedup came from the greater control Fortran gave over how data got mapped in memory. This made it easier for the code to be explicit about memory re-use, which was a big help when we were iterating over millions of networks. Re-using memory was helpful in two ways, I think. First, it avoided wanton creation and destruction of objects. Second, and more importantly, it allowed bootstrapping the work already invested in evaluating network `N` when it came time to evaluate a nearly-identical network `N+1`. Of course, I could have made the same algorithms work in R, but languages like C or Fortran, which put you more in the driver's seat, make it a little easier to think through the machine-level consequences of coding decisions. That experience actually taught me something interesting about user expectations. When the Fortran version was done, my users were so accustomed to waiting a few days to get their results, that they didn't run their old problems faster. Instead, they greatly expanded the size of the problems they were willing to tackle (the size of the building, the number of uncertain parameters, and the number of samplers to place).
  • fhood 9y ago
    This is the first time that I have ever encountered someone who used Fortran for something other than earth sciences related modeling. Thank you, now I have a second example the nest time someone claims "nobody used fortran anymore".
    • azag0 9y ago
      I’ll say it again. If the natural language of your problem domain is linear algebra and/or matrices (tensors), Fortran is the perfect tool.
      • kutkloon7 9y ago
        Why is it better than C(++) for this?
• tomohawk 9y ago
  Several years ago, our team refactored a large Java control system into a Ruby based one. The Ruby actually performed faster, scaled better, and was much easier to understand and maintain. The ergonomics of Ruby enabled clearer thinking about the problem, leading to the better results. More recently, we've replaced Python, Ruby, and Java based systems with golang based ones. Not having to lug around a VM and associated other parts (jars, gems, ...) is a huge win. Performance is better across the board, and we've reduced the amount of hardware needed. There's also much better understanding of the code across the whole team.
  • kornish 9y ago
    Out of interest, to what degree do you think the improvement in comprehensibility is from the new ecosystem vs performing a rewrite with learnings from the original write?
    • tomohawk 9y ago
      In the first case, we inherited the codebase. However, it was clear that too much attention was paid to low level stuff such as threading, etc. Ruby allowed us to more easily focus on the problem with more of a micro services approach. The Java monolith we replaced was emblematic of its time. Frameworks piled on libraries piled on other things. A lot of complexity to achieve the intended function. The move to golang has been really interesting. The language really does seem to scale well with teams. Its great to be able to pick up even code that you would expect to be complicated, such as the golang tls library, and be able to understand it. The much easier to use concurrency and fantastic standard library mean there's a lot less looking around for which framework to use or which approach to apply.
      • twunde 9y ago
        I want to explicitly call out an important point here. They inherited the original codebase and were able to understand the domain problems and what the original solution got wrong AND what it got right. Pretty much any language or framework they chose to rewrite the application in should have seen similar benefits (even if rewritten in Java). I've seen several projects where a rewrite was given to a entirely new team and those projects tend to be as complex or more so than the original (and tend to take a long time to ship)
• bleonard 9y ago
  Switching to React Native allowed our team of 6 to become a team of 2 and still go twice as quickly. It's not just the cross-platform capabilities - React is also just really great.
  • faitswulff 9y ago
    I have to wonder if the other 4 members of your team were as happy about the switch...
    • bleonard 9y ago
      Ha! There is plenty to work on and they have skills for other apps and the platform. They are not-laid off or anything. This tech change was about leverage to spend our time wisely.
• daddykotex 9y ago
  At work, we greatly benefited from a transition from Spring with Java to Play with Scala. This mostly due to the inherent complexity in Spring and the fact that Spring developers are also Spring experts. When the main developer behind the application left, we struggled to add new features or even fix bugs because the team lacked the Spring expertise. The rest of the business mostly dealt with Scala, so it was almost a no-brainer to go with Play. The outcome has been very surprising. The application has better performance overall, is better suited for streaming and we have much more expertise in-house to add features and fix bugs. The re-write was not without pain though. Spring is a well-supported and very rich framework. It probably does a bunch of things that the casual web developer will likely forget.
  • cooervo 9y ago
    Oh man I would love to work with Scala
    • hiram112 9y ago
      I would not recommend Scala anymore unless you're a small team with smart devs eager to learn it. My project is not so small, and the average developer is not interested in spending the time to really learn the language and functional style. So in the end, we have code that not everyone reads and writes well, an ecosystem that is years behind Java, and tons of incompatibilities between Scala versions as it's still not stable. It's a mess, and most just end up writing Scala imperatively a la Java from 2005. Java 8 is actually pretty good and has a lot of the power of Java without the complex features few use correctly. I'm hoping Kotlin continues improving, too.
      • daddykotex 9y ago
        This was not my experience. Of course you need a team that has the drive to learn the language, whatever it is. If you go out on your own and decide to build your project with Scala and a big focus on using a functional style but no one else is following, you are going to have a bad time. I'd like to know what are your issues with Scala and versions because we don't have these. IMHO, Scala is years ahead of Java and it's possibly so different that comparing them does not even make sense. The transition from Java to Scala is awkward because you can do most of the things you do with Java in Scala. With that said, I think it's counter productive to do it. Scala is very different and approaching it with an imperative Java (even an OO) style is the worst thing to do. One thing that I realized is that some people can go off and write cryptic code in Scala, very easily. This is true of other languages as well but in Scala, you can do a lot of things that will make you regret it the next time you try to read the code.
• paulbjensen 9y ago
  When our Rails team delivered our projects and Christmas came in 2010, we peeked our heads out and discovered Node.js, CoffeeScript, and WebSockets. We created a real-time web framework from the combination of those technologies, and demoed it at the Hackernews London meetup of June 2011. It was known as SocketStream.
• charlie-r 9y ago
  We're starting to develop greenfield APIs in Scala (with Play) rather than PHP (with Laravel) and we've noticed new developers without experience in either language have a surprisingly similar time-to-productivity. Here are some major factors: PHP's dynamic typing combined with Laravel's magical approach makes discoverability hard. A developer can't trace through a request by starting from a controller method and navigating through a codepaths with the support of their IDE. Our application code uses typehints almost exclusively, which helps. But whenever the code you're debugging drops into the framework (or PHP), you'll need to break out your browser and spend time a great deal of time reading documentation to understand how to use the function. For example, certain functions in Laravel accept no arguments in the function signature, but the function body calls PHP methods to dynamically parse function arguments. We spend a fair amount of time documenting all the framework and language-level magic constructs. If we've dropped the ball on documentation (which happens often) a new developer is at the mercy of coworkers to explain where the framework (or language) magic happens. On the plus side, Laravel's batteries-included approach significantly speeds our time to MVP. Scala's category theory approach to functional programming is not easy for new developers to understand at first glance. While most of our code (framework or otherwise) is now easily navigable with an IDE, developers now need to spend time understanding concepts such as for comprehensions, monads and ADTs. However, most functional concepts are understandable without the help of coworkers, which means a new dev can rely on Google to help understand a concept, rather than relying on a coworker. Once knowledge of syntax has been attained, Scala's strong type system makes development far easier. We can communicate semantics through types and monads (such as Either, Future, Option and domain-specific ADTs), and incorrect code is immediately flagged by the IDE. A new developer making a change to a database schema may now change a database column name, recompile, and be presented with a list of every bit of code they've broken. Using types to represent the semantics of our domain has been incredibly powerful, and makes potential bugs much easier to spot when reading the code. For example, rather than checking a user's subscription status inside a method, we can require a "SubscribedUser" type in our method signature. With this type in place, a new developer can no longer accidentally call that method with an "UnsubscribedUser". Perhaps most importantly, the long term benefits of Scala's strong type system are incredibly valuable. We're a software agency, so our large projects experience development in phases. It may be 6-12 months before our team circles back to a large project for major development. In that time, we've forgotten all the quirks and gotchas of that particular framework and language, and Scala's strong static type system significantly decreases regressions during the new development effort. In summary, new developers have a similar learning curve for each language/framework. And in the end, Scala's long term maintainability is more valuable than Laravel's speed to MVP.
• mamcx 9y ago
  Change languages is the only way so far, to step-out serious blind-spots in the previous language. Is a shame that langs are rarely fixed, only added more and more features without learning anything in the process. Devs are so change adverse that is not even funny. I have done a lot of business/enterprise development (a very hostile space to innovation and working solo or with very small teams), and have done small-to-largeish (from my POV) rewrites in several languages. From: - Fox 2.6 to Visual FoxPro. A breaking change in a lot of ways, a total win in the process. Not just because the app was native windows now. - From Fox to Delphi. Now I discover the beauty of Pascal and improve the app and deployment scenario. Static types is a net win overall. My other love is python, probable code faster on it, but have FAR LESS trouble with strong type systems. (However take a me some years in note how bad all languages are aside the DBase Family in talk with databases, but other wins distract me from that...) - Visual Fox to .NET (1.0, 1.1 with both Visual Basic and C#) was a total net loss. A Massive increase in code size, yet the (desktop) apps were way slower than Visual FoxPro, even more than Delphi (but my boss not let me use Delphi). The web was also terrible in performance and complexity. Sadly back in the day I was unaware of how do web properly and drink all the MS KoolAid on this. This sink the project and almost the company. Only saved returning back to full FoxPro. - To Python. I move several things to python, mainly .NET stuff. How boy, how big was the win. The net reduction in code size and the clarity of the code! Also, (web) apps way faster. Take .NET some years in learn the way here, so... - To RDBMS (Heck, even sqlite): Still big wins when someone else try to use a nosql/desktop datase (in my space, NOBODY is Facebook. With no exception, step-out of a RDBMS is one of the biggest mistakes) - To F#: I return to .NET past year (because MS do a lot of the right moves to fix old mistakes!!!) and again a lot of reduction in code size, removing of problematic logic obscured by years of OO-only code. Still not happy about the way lower quality tooling, but enduring it even in Xamarin Mobile because I see the benefit. I wish I could use swift for Android, so F#/.NET is my only sane option left... ---- Mainly, move from a lang to another that is not similar, help in see the problems with the old one. Learn new or better ways to solve stuff, and get access to different toolsets and mindsets. This payback when returning back to the old, too, when this ideas are migrated.
• Rjevski 9y ago
  Well I'll provide a somewhat different story where the lack of change has caused quite a loss in productivity. At my current employer's a big part of the codebase is in Perl and the boss is a fan of the language, so we keep using it. The problem is, Perl is pretty much dead, and most of the packages out there on CPAN feel like they've been built 10 years ago. Not to mention, the language itself lacks what I would call essential features like exception handling, classes, etc (which has to be tacked on by using "shims" from CPAN like Moose or Try::Tiny) At some point I had a particular issue in one of our apps where it would be making tons of DB queries and we need to cache them. In Python land there are plenty of packages that give me transparent caching at the ORM level. In Perl land? Oh yeah this post on a mailing list from 2007 about someone having the same problem, and a bit of untested code that may or may not work. I gave up on that particular issue and it'll probably never get fixed, but let's just say that have we been using an "alive" language things would've gone much smoother.
  • reacweb 9y ago
    The problem of old languages like perl and Ada is not lack of libraries, but lack of good developers that know how to write idiomatic code. Performing caching at the application level is so trivial in Perl that I do not see how a caching at ORM level could give any benefit.
    • zimpenfish 9y ago
      > I do not see how a caching at ORM level could give any benefit. I don't know anything about the Python libraries as such but if they implement pluggable modules like memcache, redis, SysV SHM, etc., for the caching, then you can chop and change as required without having to make any application level changes[1]. Which is also handy for testing because you can supply your own mock cache module to do ... whatever. [1] A good example would be going from "direct DB access" to "global memcache" to "local memcache backed by global memcache" - all without application changes.
      • mfontani 9y ago
        > A good example would be going from "direct DB access" to "global memcache" to "local memcache backed by global memcache" - all without application changes. I strongly disagree: I'd rather debug something wrong with the lone application level change which added the cache support at the application level, rather than have to enter the long and deep rabbit hole of the path the code takes at the point I ask for a resultset and I get something from the DB-backed ORM, or from a global memcache, or blah. But then again, I happily develop on mostly-Perl codebase(s) ;)
• dhd415 9y ago
  I was involved in the conversion of over 500k lines of Visual Basic 6 to C# motivated by Microsoft's EOL'ing of VB6. Most of it was a desktop application although part of it was a server component. We used an automated code conversion tool which did a surprisingly good job of handling the mindless parts. Some pieces such as the database interaction code had to be hand-ported. I was pretty surprised that we were able to pull the whole thing off while maintaining functional parity. In the end, there wasn't much of a change in performance, but C# proved to be a much more productive development platform than VB6 in terms of tooling, ability to refactor, use automated test tools, etc., so the team's velocity increased significantly over the next few years.
  • teyc 9y ago
    Interesting. Is the conversion tool internally developed? How did you handle semantics like -1 is true?
    • dhd415 9y ago
      We used a code conversion tool from Artinsoft (now Mobilize.Net) and brought one of their consultants onsite for a week. The cost for that was in the low 5 figures, but our CTO (rightfully) recognized that as a bargain given the amount of developer time it would save us. The consultant helped us analyze the code conversion results and got us some custom builds of their tool to handle certain edge cases in our code. We had to make a pass over the converted code by hand for certain things such as changing from VB6 to C# coding conventions, etc., but as I recall, the overall effort was 3-4 months for a team of about 10 developers. That's not bad considering it was a critical part of our flagship product in ~2010 and MS had dropped support for the VB6 IDE.
• __coaxialcabal 9y ago
  Related post from 2013. tl;dr: Don’t build your app on top of a pile of crap in-house framework. https://www.cloudbees.com/blog/about-paypals-node-vs-java-%E2%80%9Cfight%E2%80%9D https://www.cloudbees.com/blog/about-paypals-node-vs-java-%E...
• davidjnelson 9y ago
  Wow, that's awesome! Which FP constructs did you use?
• di4na 9y ago
  Anything long lived to elixir/erlang. Not for less bugs or better speed. But for the ability to bulkhead the errors and the debugging capabilities. Dynamic tracing all the things has reduced the time to solve bugs by an order of magnitude for us.
• jackmott 9y ago
  i wanted to compute perlin noise to make planet textures fast enough thay the user would not have to experience a loading screen when flying into a solar system. i could not make that happen in c# which the bulk of the game was in. c++ allowed me to compute it around 11 times quicker via SIMD intrinsics.
  • pirate_avogadro 9y ago
    Did you try generating your textures in a pixel shader or compute shader?
• thepratt 9y ago
  It all depends on the team, but personally the larger the team gets and the more complex your application becomes (monolith/microservice/etc independent) types are invaluable when it comes to shipping an actual product. You gain speed increases due to paths being evaluated ahead of time (compile time), but these are all secondary to developer peace-of-mind and time saved when work actually needs to get done - this includes ticket revisits due to "oh I forgot about that case", or "user did x and now this object is a string". Yes, you should write unit tests to cover this in interpreted languages with weak or no types, but this depends on the developer a) doing it, and b) not missing any cases - PRs/code reviews are not a catch-all. Especially in the case of factoring common logic out or some other form of refactoring, a strongly typed language is my best friend.
• afarrell 9y ago
  This is a less dramatic change than swapping out the framework since we are still using rails, but a couple years ago my employer switched from using rails controllers to using https://github.com/gocardless/coach https://github.com/gocardless/coach and it is noticeably easier to write good tests.
• d--b 9y ago
  Moving a large C++ codebase to C# has helped us a lot. The legacy code had memory leaks that caused random crashes. It was also long to build, and wouldn't build in 64 bit. The C# version seemlessly let us run the code in either 32 or 64 bit. C# is also a much more readable language, and has a lot of great tools for refactoring and profiling. And C#'s performance is almost as good as C++ in many areas, so all in all it's been a great move.
  • amelius 9y ago
    I'm guessing that moving from C++ to C++ (i.e., a rewrite in the same language) would also have helped a lot.
    • hvidgaard 9y ago
      There is a lot of safety features in C# that are not present in C++, so a rewrite in C++ would probably have helped. However the same class of errors that was a problem in the old codebase are still present.
    • d--b 9y ago
      Actually that particular C++ was very well written. It had been written by a single very disciplined person over 3 years, following a lot of very strict conventions. So, no it was not really messy in there. But it was big and memory leaks are hard to find. The main problem is that there was some low level funky stuff happening that we didn't have a good grip on. The guy who wrote it thought it would be great to optimize the code in some ways, but clearly overdid it.
      • amelius 9y ago
        > The guy who wrote it thought it would be great to optimize the code in some ways, but clearly overdid it. But then I suppose a rewrite would undo those optimizations and solve the problems.
        • d--b 9y ago
• lngnmn 9y ago
  J2EE
• deleted 9y ago
  [deleted]
• BrandoElFollito 9y ago
  I am an amateur developer, mostly using python. I had from time to time to code a front-end in JS and it was a huge pain in the bottom (again, I am a real amateur). This until I discovered Vue.js which changed my life. This and lodash made me actually like JS and front-end programming. So this is an example what a framework did not help to improve code but actually made me choose in something else than the language I was using so far (coming from a background in C, then Perl)
  • dashundchen 9y ago
    Would you be able to recommend any Vue tutorials/resources/projects you found useful while learning?
    • levthedev 9y ago
      All you need are the (excellent) docs! You can read the whole thing in like an hour or so. Onve you've read the docs, just start building.
      • BrandoElFollito 9y ago
        Absolutely agreed. I went from zero (and very poor JS skills) to starting refactoring my app in one afternoon.
    • tribby 9y ago
      I agree with the comment sibling recommending the docs -- they are good. maybe try building something with nuxt[1] first. nuxt a framework/static site generator build on top of vue (inspired by next.js for react). its conventions are easy to pick up. I find nuxt eliminates all the boilerplate and middleware I would normally have to write for a vue app with SSR (especially since vue-cli really only has a good client-side template). it's a joy to work with. 1. https://nuxtjs.org/ https://nuxtjs.org/
      • moosingin3space 9y ago
• circlefavshape 9y ago
  A friend of mine is a java contractor, him and a bunch of java people got hired by a French company for a javascript project. After a few months slogging through an unfamiliar language, the company decided to switch to java. Productivity went up, surprise!
• lucaspiller 9y ago
  I worked on a project a few years ago that was a mixture of Erlang and Ruby. Most of us were new to Erlang, coming from a Ruby background. We wanted to use Erlang to its strengths for high availability and to make the platform distributed, and Ruby (via BERT/Ernie) to its strengths for business logic. Unfortunately Ernie didn't work as well as it advertised, had many edge cases, and in the end it was a big bottleneck (it would have been faster to ditch Erlang and use plain Ruby). In the end we wrote everything in Erlang. It wasn't that hard in the end, and the reason why we went down the Ruby route in the first place was because the platform was over-engineered to be as generic as possible (which wasn't needed), so we didn't actually lose anything.
  • taude 9y ago
    Do you have any experience with Elixir? I'm hearing that Ruby devs like it for similar syntax that runs on the Erlang runtime....(But I don't really know much about it, but I am curious.)
    • lucaspiller 9y ago
      I learnt Erlang before Elixir became popular. Other than a few sanity changes (like ordering of arguments for some built in functions), I prefer the Erlang syntax. The syntax is Ruby like, but it's still different enough.
• sandGorgon 9y ago
  R to python/pandas - deployability
• superasn 9y ago
  I'm a solopreneur and switching to AngularJs 1.x really made a drastic difference to my work. Before we used all sorts of hacks and jquery plugins to do the same and it was really hard to maintain our code. After switching to AngularJs the development time became 20% and it became super easy to maintain. Not to mention programming became super fun again. I've tried react and angular 2 and vue but that just didn't click for me. We're are a small team of two so we don't follow the industry best practices, just whatever works for us and gets the site launched as quickly as possible, so i guess my comment is highly opinionated.
• scardine 9y ago
  10 year ago the RIA (rich Internet applications) platforms were the trendy thing of the day. Microsoft had Silverlight, Adobe had Flex and so on. I made a bet on OpenLazslo, an open source contender. I made a wireframe and the snappy interface impressed a client that gave me a big project. 1 month working with OpenLazslo and PHP it became clear I would not be able to finish in time. I started searching for alternatives and was unable to finish the Rails tutorial - but after 30 minutes I had a basic CRUD app done using Django. I ditched the RIA thing, rewrote everything in Python/Django, was able to finish that project in time and this stack is paying the rent since then. It was really worth.
• galimay 9y ago
  We included Lua in our videogame, and that help us to reduced drastically the prototyping time (screen design, FXs, transitions). Isn't exactly a switching because we still use C/C++. However porting the main logic to Lua allowed us to use the Live Coding feature (we were using ZeroBrane), so you can get rid compilation times, executions and manuals steps to reproduce whatever you are working on. We couldn't be happier with this decision. Totally worth it!
• dsfyu404ed 9y ago
  Literally every time I've switched from bash to anything else. Usually the use prerequisite situation is "this script processes strings and is getting too big and unwieldy for bash"
• simontcousins 9y ago
  My team switched an entire application from C# (~350k loc) to F# (~30k loc). Smaller team, smaller code base, fewer bugs, complete implementation of requirements, clearer code. The whole of the F# code base was less than the number of blank lines in the C# code base and a lot more fun to read and write. https://github.com/Microsoft/visualfsharp/issues/2766#issuecomment-291160401 https://github.com/Microsoft/visualfsharp/issues/2766#issuec...
  • solutionyogi 9y ago
    Wow. I have been using C# for a long time and has dabbled in F# a little bit. And I know F# can help you reduce some boilerplate that C# requires but I have never seen reducing code base by 90 percent like in your case. Can you give us little bit more details? Eg 350k doesn't include blank lines, right? What did the application do? Is it a Windows service or a Web App or a command line program?
    • simontcousins 9y ago
      The app evaluated the expected income from Ancillary Service contracts in the UK energy market and subequently reconciled against actual income: https://en.wikipedia.org/wiki/Ancillary_services_(electric_power https://en.wikipedia.org/wiki/Ancillary_services_(electric_p... It comprised a windows server, a web app and a calculation engine. As well as remorselessly removing boilerplate code using FP techniques the F# solution also allowed us to explore our way, via the REPL, to solving the problems we were faced with and come up with better ways of doing things. The clarity, concision and low ceremony of F# code allowed us to rapidly evaluate and change approaches if necessary. I find getting into the flow of development much easier in a language that supports this exploratory approach to programming - leads to less rigid thinking.
• cjCamel 9y ago
  Years ago I rewrote some liquid flow routing analysis in C# that was precisely one jillion times faster than the original code. This code was written in....a SQL stored procedure. tl;dr Don't use SQL for recursive conditional logic. Probably not a useful example huh?
• f3r3nc 9y ago
  As others have said earlier, if the new tools serve the problem domain better there will be significant gain. My first game server was hand crafted with php/mysql. It did work and was able serve players, however moving to Erlang allowed two order of magnitude more players onto the same box, while the code maintainability increased as well.
• sethammons 9y ago
  At work, our first success in this vein was migrating a Python Twisted service to Go. Due to the critical nature of this service, we strove for feature parity. We ended up with a mostly Go-like code base, but it was very similar to the original code base in basic structure. Most of the improvements we got were due to the language choice, not due to a better design. Our main concern is concurrency, and for that Go excels. Additionally, post re-write, that code base is easier to follow, easier to extend and maintain, easier to deploy, easier to control lower level aspects, and much, much more performant. It was years ago at this point, but I believe our improvement was something like 120x. Since then, at work, we've moved to Go as our main language for services. This has provided even more wins as we continue to move legacy Perl/AnyEvent code over. With new rewrites (and new projects), we are taking the opportunity to also redesign systems, enabling our software to scale even further. We have lots more to do and we are hiring :)
• abritinthebay 9y ago
  Moving from Ruby to both Elixir and JavaScript (node) strongly improved developer productivity, performance, and time to release. Ruby/Rails isn’t bad as such, but it’s slow and promotes a very convoluted & interdependent monolith by default. Very happy with the change.
• tluyben2 9y ago
  Seems focus is on positive differences, but I have seen the reverse a lot; switching native to web because 'everyone is doing it', switching PHP to 'something that doesn't suck', migrating off c# because 'M$' and many others that really hurt (and killed) projects. I did see projects improve as well but that was almost always because it was code from an 'old' team where the framework and programming language was not optimal (to say it lightly) for the new team.
• taphangum 9y ago
  Switching from CodeIgniter to Laravel saved me a ton of time, and ultimately made start to enjoy programming again. I'm actually in the process of writing a book about the key differences between the two frameworks, enabling people to shorten the time it takes to get the hang of Laravel. It'll document the differences and similarities between the two frameworks so that you can use your CodeIgniter knowledge to learn Laravel. I.e. the difference between routing methods in CodeIgniter vs. Laravel, and how migrations work in one vs the other. Almost everything to do with migrations still has to be done manually, for the most part. I.e. having to create your own controller (https://stackoverflow.com/questions/9154065/how-do-i-run-codeigniter-migrations https://stackoverflow.com/questions/9154065/how-do-i-run-cod...) in order to run a migration in CodeIgniter vs the more slick 'php artisan migrate' command in Laravel. If you want to know more about it, you can add your email here: Book info (it's a google form) https://goo.gl/forms/gCAT33rl1h6JbQsw2 https://goo.gl/forms/gCAT33rl1h6JbQsw2