1. 4

    “do it in one fell swoop” I think is often so unpractical that I would not consider this advice for anything but the smallest of code bases.

    Adopting habits as a team (and individuals) that continuously improve a code base is the way to go in my experience. Yes it might not be obvious or easy to agree on those habits, but it’s doable. Making things better as you go is indeed a moving target and never ending endeavor, but that is the nature of living, used software/code where requirements/features evolve.

      1. 1

        I’ve been following Loom (and its predecessor Quasar) for a while. The concurrency story of Java was the biggest reason for me to look at alternatives like Clojure and later Erlang/Elixir. Loom’s going to change the game. Feels like a great addition to Java.

        1. 4

          I take notes and usually turn those into some summary of my favorite talks. I find conferences good for expanding your horizons, ie finding the next area to get into deeper.

          1. 2

            Really digging the new features, should definitely help with getting more people to try out the language (myself included). Thanks and congrats on the release!

            1. 1

              Thank you very much!

            1. 1

              Love the list! Would be cool to go through it and add answers for a couple of languages.

              1. 1

                https://forvillelser.vorce.se/ - I write about things I make, learn, and like. Its purpose is mostly for myself (documenting things), but could also be interesting for other developers.

                1. 7
                  • jq - “lightweight and flexible command-line JSON processor”, super useful when working with json APIs
                  • dependabot - get dependency update PRs automatically
                  • trello - I use a separate boards for all kinds of things, from software side projects to keeping track of things I have to do when moving for example.
                  1. 19

                    Elixir is probably the most practical language to learn today that meets your criteria.

                    Not exactly statically typed, but has type annotations and the compiler checks all function calls (names and arity) at compile time. Erlang’s static analyzer (Dialyzer) can check the types but i haven’t used it.

                    The official guide is pretty good : https://elixir-lang.org/getting-started/introduction.html

                    1. 4

                      Regarding static analysis with Dialyzer, I’m using it day-to-day right now and I’ve found that the tooling situation has improved greatly for me over the past couple years. I use VSCode and the latest versions of the ElixirLS plugin work great:

                      https://github.com/elixir-lsp/vscode-elixir-ls

                      I used to have to add a package called dialyxir to my project and run stuff manually, now I get first-class editor integration with everything taken care of for me seamlessly. I think most of the Elixir community still doesn’t use Dialyzer, though, which means help can be hard to come by.

                      Dialyzer itself isn’t perfect, and there’s no comparison with a type system like Haskell’s. It can be frustrating running up against its limitations and figuring out which surprising things it will let you do to shoot yourself in the foot…but over time I’ve found that I can kind of “meet it half way” by adjusting my coding habits and expectations. Right now I have a pretty good relationship with it, and it helps me write Elixir code in a way that feels almost-sort-of like it were a language with a strong first-class type checker built into the compiler.

                      1. 4

                        Oh, I totally blanked on Elixir. Thank you for the reminder! I always did want to poke around at it.

                        1. 2

                          The cool thing about learning Elixir is that you’ll also learn the most of Erlang for free. Syntax differs a lot and Elixir has a whole bunch of additional libraries and tooling, but that’s about it. Types, semantic, memory models, runtime are just exactly the same and there’s no FFI, calling Erlang code from Elixir is so easy and seamless that I often use the Elixir REPL to play with Erlang libraries.

                          Maybe you’ll wonder what’s the point of learning Erlang if Elixir is better*. The point is about existing code. Lots of super interesting software has been written in Erlang since decades and is still in use.

                          *: This is subjective of course! There are probably people out there who prefer Erlang.

                          1. 2

                            I’ve been wondering about the relation of Elixir to Erlang, is there an analogy one could make, that goes beyond just the technical aspects, and reflects how the communities see each-other? Is it like Java to Kotlin, or Javascript to Typescript? C to C++?

                            1. 2

                              Not an active member of the Elixir community, but from what I can tell it’s probably most similar to Javascript to Coffeescript; the developer isn’t making any particular changes to the language like with Typescript or C++, rather just making the syntax more conventional. Maybe that’s like the Java-Kotlin relationship but I’ve never really used either. José Valim seems to have a very healthy relationship with a lot of the Erlang community.

                              That’s just what I can tell as an outsider, though.

                              1. 2

                                Is it like Java to Kotlin, or Javascript to Typescript?

                                Yes! This is a very relevant analogy because both Elixir and Erlang share the same virtual machine (ERTS), which is similar to the JVM or a JavaScript engine like V8. Interoperability works without FFI (at least for JavaScript/TypeScript).

                                C to C++

                                Well, it’s more complicated. I’d say “not really” because these are not dynamic languages, there’s no big runtime and they are not compatible (C++ is not an exact superset of C, and more importantly you need extern "C" in C++ headers and this is a kind of FFI, and AFAIK there’s no way to use C++-specific features from C).

                            2. 2

                              I second the Elixir recommendation. If you’re valuing types more and are ready for a bit more experimental / early stuff, I would give Gleam a shot.

                              1. 1

                                Elixir runs on the Erlang VM, right? Has that VM’s performance been improved since I last looked at it circa 2012? Back then it was a standard bytecode interpreter without JIT or native compilation options, and so rather slow, e.g. way slower than JavaScript. (Too slow for my use case, which was on smartphone-class hardware.)

                                I know people tout Erlang’s performance, but it gets that from parallelization and scalability, even though each CPU core isn’t being used very efficiently. Or wasn’t, at the time. Maybe it’s better now?

                              1. 2

                                Just tried this in an app at work. Super easy to plug in. Looks useful already at this stage.

                                1. 2

                                  Same here! I’m really pleased that it works with Phoenix 1.4 and not just the upcoming 1.5 release.

                                1. 9

                                  Yes plenty of times. I’ve used Processing (and its Clojure variant Quil). My process is usually to sketch with pen and paper first, then try to implement something sort of similar, and play around with it -> iterate on the code until I think it looks good :)

                                  1. 10

                                    Shorter workweek is a total win-win situation in most workplaces. The employees will be more efficient and happier and the companies will end up paying less for it.

                                    1. 3

                                      I agree. I work four days and I honestly think I do more effective work in those four than I do in 5. The day off also works great against burnout.

                                      1. 2

                                        I did the same for a while. I believe this was one of my more productive (per hour) periods. Also everything outside of work got a lot better; health, relationships, hobbies. Which naturally led to more happiness.

                                        1. 2

                                          for a while

                                          So why did you stop?

                                          1. 2

                                            I changed teams (which meant re-locating) and the new one insisted on 100%. I’ve since switched company, might go for it again if I have the opportunity.

                                    1. 11

                                      Unit tests are intended to speed up development. If they do the opposite, then yes, you should stop writing them, because they’re not useful to you.

                                      Two ways in which unit tests do speed up development:

                                      • When tests fail, unit tests help pinpoint the part of the code that needs to be fixed.
                                      • Integration tests often take longer to execute than unit tests, so a good set of unit tests can speed up the change-compile-test cycle.

                                      The author hit the nail on the head here:

                                      When a large change lands, unit tests, in the best case, need to be heavily modified, and in the worst case are obsolete and need to be removed.

                                      In a development cycle involving unit tests, we do our best to avoid large changes. If a given change requires changing lots of tests, then either the change itself is too large, or the tests are not really unit tests.

                                      1. 2

                                        Well put. This was also going through my head while reading the article. “Unit” and “integration” tests serve different purposes.

                                      1. 5

                                        I’ve been working on lasso, which started as an excuse to play with Phoenix LiveView. Starting to feel pretty good about it, might even upgrade to a non-free tier at gigalixir.

                                        1. 2

                                          lasso looks really cool, I’ve built something similar for my company but it isn’t nearly as cool as yours. I looked into liveview for something else and it looks like a good alternative to just pass JS around for some things.

                                        1. 1

                                          The question, then: “is 90/95/99% correct significantly cheaper than 100% correct?” The answer is very yes.

                                          :D

                                          Great article. And I’m even more hyped to read my fresh copy of Practical TLA+.

                                          1. 16

                                            I feel like there’s such a big difference between the JS world and pretty much any other language ecosystem that it’s hard to identify with articles like these unless you’re a JS front-end dev. At least my own experience is that most other communities has moved on from FOTM frameworks since long, or never even got into that mode. I guess it’s got a lot to do with how fast browsers evolve compared to “backend stuff”.

                                            1. 9

                                              As a backend developer I’d say it also has got to do with the fact that the fundamental problem the front-end is trying to solve is so hard that we haven’t come anywhere near an acceptable solution. The number of deeply interacting concerns are simply too high. So people always come up with completely new ways of doing things that do improve on the state of the art.

                                              1. 3

                                                I think the fundamental problem the front-end is trying to solve is undefined.

                                                1. 1

                                                  User experience is undefined? O_o

                                                  1. 2

                                                    UX functions like language. An intuitive UI is defined largely by what the user already knows, and it suffers from “slurring” as seemingly redundant indicators shrink away to nothing, “punning” and “coining” new terms, and, of course, fashionable ways of expressing things and fashionable ideas to express.

                                                    So even if it is kind of “defined” in what it means, it definitely isn’t as “stable” as core algos are.

                                                    1. 2

                                                      I don’t think there is a single problem. We all know many examples of products and services where user experience is less important than ad profits. I would say the most fundamental problem for front-end is minimizing time and effort required to push new products and services out - while maintaining acceptable user experience.

                                              1. 6

                                                I’m pretty excited about LiveView as a way to sprinkle some interactivity on phoenix apps without having to venture out to JS land. Can see it being a pretty good way to enhance admin UIs and the likes.

                                                1. 11

                                                  I can’t keep this to one thing, sorry.

                                                  Go slow & correct first. Pre-requisite to be able to eventually go faster and correct.

                                                  Learn new languages. Helps with thinking about problems in different ways.

                                                  Short feedback cycle! Anything that improves this will make you faster – TDD or at least test first development, and Continuous Deployment are big ones.

                                                  Spike and Stabilise pattern (this and more related good stuff by Dan North in https://leanpub.com/softwarefaster)

                                                  Pair programming can sometimes make you faster and better, depends on the problem and the pair.

                                                  Drawing things (whiteboard or pen and paper) can help a lot

                                                  1. 10

                                                    Good idea, writing a nice README is important and can be hard. I don’t agree with the badge overload some of these seem to encourage though. I feel like a lot of the time they do not add any value, for examples badges like: “contributions welcome”, “built with <3”, or “code style: standard” – come on. Write it in text or skip it IMHO!

                                                    1. 7
                                                      • Skateboarding. Picked it up 3 years ago again, after a 15+ year break. So much fun (and frustration), and good workout. Slams are worse though :/
                                                      • Programming. Always got some side projects going.
                                                      • Listening to music. Been an obsession for decades. Most genres. Really into contemporary stuff.
                                                      • Art – Painting, sketching, and some digital stuff (using processing or quil)