1. 12

    If you want to check out a practical gradually-typed language, I’ve been using Typed Racket.

    It’s very convenient to use untyped code early-on when the design of the program is unclear(or when porting code from a different language), and to switch individual modules to typed code later to reduce bugs.

    1. 4

      Another great gradually typed language is Perl6. It has a Cool type, a value that is simultaneously a string and a number, which I think is pretty… cool!

      1. 1

        Basically how every string / number in perl5 work{s|ed}?

        1. 2

          Based on reading https://docs.perl6.org/type/Cool, kinda? Although it also looks to me as if this is at once broader than what Perl 5 does (e.g. 123.substr(1, 2), or how Array is also a Cool type) and also a bit more formal, typing-wise, since each of those invocations makes clear that it needs a Cool in its Numeric or String form, for example.

          1. 1

            That makes sense that it changed. perl5 is not so.. structured. But this stuff worked:

            "4" + "6.2"
            $q=42; print "foo$q"
            print "foo" + $q

            It makes things like numeric fields in HTML forms very easy (if $form["age"] <= 16), but the subtle bugs you get…

            Anyway. That was perl5. The perl6 solution seems to make things much more explicit.

      2. 3

        stanza is another interesting language that is designed from the start to be gradually typed.

        1. 2

          Typed Racket is indeed an awesome example. I believe TypeScript would also qualify very well here (as might Flow; I’m not as familiar with it). This also reminds me of Dylan of yore, too: https://en.wikipedia.org/wiki/Dylan_(programming_language)

          1. 1

            Is this the same thing? I had the same thought and I wasn’t sure if it was.

            1. 4

              Yes, Typed Racket is gradual typing, but for example, the current version of Typed Clojure is not. The premise is that gradual typing must support being used by dynamic typing, to simplify a little bit.

          1. 2

            Zach Tellman’s On Abstraction

            1. 2

              The City of Illusions by Ursula Le Guin.

              1. 9

                Leiningen for Clojure once again defaults to the latest version.

                Leiningen doesn’t default to any latest version as far as I know. Leiningen does

                1. reproducible dependency resolution: For the same dependency list, you always get the same dependencies ¹
                2. in no way “default” to anything, as inserting dependencies and their versions is the user’s responsibility

                Versioning/pinning is not only about having an API-compliant library though, it’s also about being sure that you can build the exact same version of your program later on. Hyrum’s Law states that any code change may effectively be a breaking one for your consumers. For example:

                • Fixed a bug in your library? Someone will depend on the buggy behaviour, or attempt to fix the bug downstream while it’s still an issue. If you forget to quote apostrophes, for example, fixing that in a bugfix release may cause some tools to double escape them.
                • Fixed an edge case/security issue? You’ve most likely introduced some checks which will have some overhead. If your library is used in a hot spot for a consumer, then it may lead to performance degradation of the program they’ve made.
                • User complains that an old version of your software is buggy/breaks, but you cannot reproduce on HEAD and you want to know what fixed it? That’s hard if you cannot use old dependencies. If git-bisect doesn’t test a commit with the dependencies you used at the commit time, you’re not testing your software as it was at that point in time. And if the bug is upstream, it’s hard to figure out what dependency caused it and how it was fixed.

                Of course, pinning is not a panacea: We usually want to apply security issues and bugfixes immediately. But for the most part, there’s no way we can know a priori that new releases will be backwards compatible for our software or not. Pinning gives you the option to vet dependency updates and defer them if they require changes to your system.

                1: Unless you use version ranges or dependencies that use them. But that happen so infrequently and is strongly advised against – I don’t think I’ve ever experienced it in the wild.

                1. 3

                  Hyrum’s Law

                  FYI, Hyrum finally made http://www.hyrumslaw.com/ with the full observation. Useful for linking. :)

                  1. 2

                    Hmm, perhaps I misunderstood the doc I read. I’m having trouble finding it at the moment. I’m not a Clojure user. Could you point me at a good link? Do library users always have to provide some sort of version predicate for each dependency?

                    Your point about reproducing builds is a good one, but it can coexist with my proposal. Imagine a parallel universe where Bundler works just like it does here and maintains a Gemfile.lock recording precise versions in use for all dependencies, but we’ve just all been consistently including major version in gem names and not foisting incompatibilities on our users. Push security fixes and bugfixes, pull API changes.

                    Edit: based on other comments I think I’ve failed to articulate that I am concerned with the upgrade process rather than the deployment process. Version numbers in Gemfile.lock are totally fine. Version numbers in Gemfile are a smell.

                    1. 3

                      Oh, yes, sorry for not being clear: I strongly agree that version “numbers” might as well be serial numbers, checksums or the timestamp it was deployed. And I think major versions should be in the library name itself, instead of in the version “number”.

                      In Leiningen, library users always have to provide some sort of version predicate for each dependency, see https://github.com/technomancy/leiningen/blob/master/doc/TUTORIAL.md#dependencies. There is some specific stuff related to snapshot versions and checkout dependencies, but if you try to build + deploy a project with those, you’ll get an error unless you setup some environment variable. This also applies to boot afaik ; the functionality is equivalent with how Java’s Maven works.

                      1. 2

                        Thanks! I’ve added a correction to OP.

                        1. 1

                          Hmm, I’ve been digging more into Leiningen, and growing increasingly confused. What’s the right way to say, “give me the latest 2.0 version of this library”? It seems horrible that the standard tutorial recommends using exact versions.

                          1. 3

                            There’s no way to do that. The Maven/JVM dependency land always uses exact versions. This ensures stability.

                    1. 5

                      I’m not an expert on Java, but why are we putting method implementations into interfaces when we already have abstract class inheritance for (what feels like) this exact thing?

                      1. 4

                        Interfaces allow multiple inheritance.

                        1. 4

                          Then it feels like the solution to this is to enable multiple inheritance on abstract classes, rather than adding default implementations to interfaces.

                          1. 5

                            But that’s not the point of abstract classes. Abstract classes enforce that (1) you must inherit from only one of them and (2) you cannot instantiate them without inheriting them. If you remove either of these constraints you have a regular class, and there definitely are use cases where you want rules 1 and 2 enforced.

                            1. 2

                              Ok, I’ll think this one over and try to understand.

                              1. 2

                                I disparaged Java 9 for this too, because it felt like they were further blurring the line between interfaces and abstract classes. After talking with some of my friends (pinging @dsh), it helped me outline some more differences. To expand and maybe give you more to work with:

                                abstract classes (to me) feel more class-y, even with these changes. You can’t have final methods in interfaces, nor can you have member variables. As mentioned, you also can’t have multiple inheritance with abstract classes - they are a strictly one-to-one relationship with child classes. Interfaces, on the other hand, are just collections of methods. All you’re doing with a default implementation is telling the compiler to use the given method body if it’s not been specified by the implementor.

                                That being said, I think the muddying does harm to people learning the language and the idea of OOP. It gives you two different ways to solve the same problem, and I can see that difference really messing with beginners/intermediates until they fully grasp the philosophy of OOP and when it really is appropriate to use an interface or abstract class.

                            2. 1

                              No, the solution is default interface methods.

                              1. 1

                                I know I’m asking for some free mental labor, but I really fail to see why that is the solution.

                          2. 1

                            I think the intention was to introduce something like Scala’s traits construct without introducing a new keyword. New keywords are practically impossible to add without breaking code.

                          1. 2

                            Whenever Carmack’s .plan is mentioned I think org-mode should be mentioned as well. Any rigorous life changing program, whether manual or automated, is potentially life-changing.

                            1. 3

                              After lobste.rs talked about A Fire in the Deep and A Deepness in the Sky, I just finished reading them. Developments like these make me think of the tech, thousands of years old and completely irreplaceable, that exists in A Deepness in the Sky. On one hand we lambaste the JS world for rewriting itself every other week, but at the same time we keep Java alive and kicking. I am one of those people that thinks the JVM is long past its prime (every heavy use of Java is running it on hardware the have defined ahead of time and don’t benefit from anything the JVM gives them), but I guess we’ll be stuck with Java for a long time as it keeps on doing accreting new functionality to keep chugging a long. IBM posted its first quarter in 5 years where it will see growth. Why? Thanks to the mainframe portion of the business.

                              1. 7

                                I am one of those people that thinks the JVM is long past its prime

                                IIRC, the JVM is an incredibly fast VM with hundreds of man years put into performing well.

                                That alone ensures it will stick around for quite awhile.

                                1. 4

                                  Yup. Hotspot is awfully hard to beat.

                                  1. 0

                                    It’s also incredibly complicated. Language implementations like Go and Ocaml are on-par with the JVM in most workloads people care about at a fraction of the complication. The JVM exists because of “write once, run everywhere”, but that vision never panned out.

                                    1. 3

                                      Got a cite for that? I don’t doubt what you say, but I think a lot of people formed impressions about Java that are of varying levels of accuracy.

                                      The fact that companies like Square, Netflix and Amazon use Java extensively even for greenfield projects should be an indicator that Java is far from the tire fire some people make it out to be.

                                      Sure, it’s verbose, and there are parts of its ecosystem that are excessively complicated, but there are newer choices that have learned from the past and eschew that kind of complication in favor of a much leaner style.

                                      I’m not trying to get anyone to love or use Java who doesn’t want to, but I’d encourage people to challenge their long standing impressions and come to a better understanding of what the language is good at and which use cases might call for its use.

                                      1. 1

                                        What are you asking for a citation for, exactly?

                                        I’m not saying Java is a tire fire, I am saying its runtime no longer suits the case it was designed for. People know what hardware and processor they are running their programs on.

                                        1. 3

                                          Language implementations like Go and Ocaml are on-par with the JVM in most workloads people care about at a fraction of the complication.


                                          1. 2


                                            One source:


                                            The JVM beats Go for 3 out of 10 problems (and by a pretty significant margin).

                                            For Ocaml, it’s 4/10 for beaten by a significant margin, and the other numbers are pretty comparable:


                                            The most common use-cases I see today is server-side, which are almost entirely I/O bound. Erlang compares well to Java in this use case, if only for utilizing I/O so well.

                                            I don’t have any studies for you other than the fact that everything is a service now.

                                            For the complexity aspect of my claim, I think that is self-evident if you’ve looked at the code of the various runtimes.

                                            1. 2

                                              So, thanks for some good food for thought. I’ll leave you with this - Every problem is different. There are still large swaths of problem space that the Go ecosystem has barely even nibbled at which have very rich support in the Java world.

                                              That combined with newer frameworks which are the polar opposite of some of the useless complexity we’ve all battled in the past (Take a look at Play for an example of what I mean) can make Java a really great choice for some problem domains.

                                              I just think we need to be careful about making overly general claims, and open minded to the fact that there are huge swaths of the industry still coding in Java for a reason.

                                              1. 2

                                                I think some aspects of my point are being conflated a bit, though. I’m not making a statement about Java-the-language, I’m making a statement about the runtime. My point about Ocaml/Go, which I didn’t make very well, is really that these are languages with a much simpler runtime but still quite comparable performance combined with my claim that the problem the complex runtime is solving is not a problem a vast majority of Java users have.

                                                I just think we need to be careful about making overly general claims, and open minded to the fact that there are huge swaths of the industry still coding in Java for a reason.

                                                If you reread my first comment, I think you’ll see I fully acknowledge that. Mainframes are still a money-making business (would you advocate one use a mainframe, though?) It’s a fact that people are running lots of workloads on the JVM. I even work for a young hip company that uses the JVM. But I’d also be cautious of reading too much into that, IME, the “reason” people do it is often not connected to a technological merit.

                                                1. 1

                                                  Mainframes are still a money-making business (would you advocate one use a mainframe, though?)

                                                  That depends. What do you mean by ‘mainframe’? There are scads of business running on the descendant of mainframes - the IBM Power system to this day, running ageless workloads using tools like COBOL and RPG and the like, because those tools suit he use case.

                                                  Sure, there are tons of people out there supporting legacy hardware and software nobody in their right mind would choose for a greenfield project, but that’s a different problem.

                                                  It’s a fact that people are running lots of workloads on the JVM. I even work for a young hip company that uses the JVM. But I’d also be cautious of reading too much into that, IME, the “reason” people do it is often not connected to a technological merit.

                                                  Technical merit has many variables attached. If you’re really talking strictly about runtime size, then you may have a point. I’d argue that for many (most?) people, runtime size is pretty much meaningless.

                                                  You’ve successfully proven a couple of assertions like “Go runtimes are smaller than Java’s” and even “under certain circumstances, Go can outperform Java” but I respectfully disagree with the idea that choosing Java might not be the right thing based on technical merit.

                                      2. 2

                                        The JVM exists to be a Java bytecode interpreter. It’s counterproductive to assign any more labels to it – write once, run anywhere is hardly its main focus these days.

                                        I would argue, basing on what most Java software is built for, that the JVM exists to be the best abstract bytecode interpreter there is. It’s not particularly great for small-scale algorithmic benchmarks like the alioth benchmark games, but where it shines is long-running processes. Servers.

                                        The TechEmpower benchmarks demonstrate this. JVM languages occupy a significant portion of the top 10 in every segment.

                                        Comparing the JVM to OCaml/Go runtimes is not fair. The JVM is a much more complicated beast, given that it supports some very advanced features like:

                                        • AOT and JIT evaluation (fair enough, AOT support is experimental, but it is there)
                                        • An extremely sophisticated garbage collector which is user-tuneable (this does not exist in Go/OCaml)
                                        • A user-configurable concurrency model (native threads, fibers, green threads) - OCaml concurrency support is blah and Go only has green threads
                                        • Code hot swapping and dynamic class loading
                                        • Direct native code interface (OCaml is better in this regard, but with Go you need SWIG)

                                        And the new Graal compiler is really cool.

                                        And HotSpot is just one implementation. There are several enterprise-grade JVMs out there that include crazy things like real-time support (PTC Perc, JamaicaVM), AOT (ExcelsiorJET) and native execution (IM3910.

                                        I think your citation of the expiry of the write-once, run-anywhere paradigm is anecdotal. I develop on OSX and run my .jars on Linux and Solaris v11.

                                        As I said, the comparison is not fair. The JVM has about 25 years of engineering behind it. For that reason alone, it is extremely unwise to downplay it as outdated.

                                        1. 2

                                          I don’t really understand the core of your response. Part of my claim is that the JVM is a big complicated beast, and that’s not a good thing. And your response is “It’s not fair to compare it to <X, Y> because the JVM is a big complicated beast”. How is one to argue that being a big complicated beast is not a positive thing?

                                        2. 2

                                          Go and Ocaml are on-par with the JVM in most workloads

                                          That’s a huge benefit of the JVM right there. Most developers and their managers have absolutely no idea what their workloads will be 2 years down the road.

                                          Using the JVM obviates the risk of coming back to a system and having to significantly re-engineer it due to Go’s/OCaml’s runtime starting to choke as the amount of data grows:

                                          Service needed 1GB back then, now it requires 10GB.

                                          • Go/OCaml: Rewrite your application.
                                          • JVM: Who cares? Traffic could even have grown to 100GB, and buying more RAM would fix it.

                                          Using lesser runtimes is basically a bet that your application will never experience an increase in traffic.

                                          1. 2

                                            Your claim that the JVM just magically scales up to any workload does not match my experience. I see software rewritten on the JVM as much as any other language. Perhaps you have some specific experience in mind that you could share. Maybe you’re talking about something like Azul? Sure, I’ll grant you that. But in the microservice world, those situations are few and far between. To be clear, I am not saying that some people aren’t just buying bigger hardware to run their JVM programs, I am saying that usecase is dwindling, IME.

                                            1. 1

                                              Well, you said: “Language implementations like Go and Ocaml are on-par with the JVM in most workloads people care about”.

                                              I pointed out that the Alioth benchmark game is not “most workloads”. I gave the TechEmpower benchmarks as a more relevant benchmark environment (web applications, since that’s what most people do). These benchmarks demostrate that JVM is more performant than the languages you mentioned.

                                              Where you are correct is that the JVM is a complicated beast. I do not disagree there. But it’s a performant and sophisticated one, that is definitely not past its prime.

                                      3. 4

                                        I am one of those people that thinks the JVM is long past its prime (every heavy use of Java is running it on hardware the have defined ahead of time and don’t benefit from anything the JVM gives them).

                                        Could you elaborate on this? I find this statement quite confusing.

                                        1. 1

                                          The point of the JVM is a portable runtime so you can compile your program once and run it anywhere. However, every company I have worked for deploys their program to one platform, running one OS, in a very well-defined environment. The value of the JVM is limited. “What about the JIT?” one might say, but IME, the JIT offers no value over AOT for modern workloads and it’s significantly more complicated.

                                          1. 3

                                            I do run across projects that make use of the JVM’s non-platform-specific binaries fairly regularly, but for forward compatibility in case of a future platform migration, rather than cross-platform portability of the style where you need to deploy to multiple platforms simultaneously (where, yes, only one platform is usually targeted). It’s not uncommon to find some random ancient .jar file in the libs/ directory, and for the development team to assume that kind of thing is going to keep working forever even if the project migrates to a different platform; there may not even be source, if it was a licensed commercial library. In that respect it has some of the same uses in enterprise as mainframe-style binaries, which also typically compile to some kind of bytecode to ensure binaries will keep running without a recompile, even across major platform updates.

                                            1. 2

                                              I’m not sure what part of our industry you’re in but I think those usecases are decreasing over time. I hear horror stories about banks that just have a .jar sitting around without source code that they depend on, but I’m not sure that is motivating enough for why the rest of us have to live with a massively complex runtime.

                                            2. 2

                                              I think that was the point once, but I don’t think that has been Java’s primary thrust for quite a while. That paradigm made much more sense when Java was aiming for the browser and the desktop, and today those use cases are not the language’s primary focus.

                                              1. 1

                                                My point is not that the use cases for the language are static, but that they have changed and we are still stick with this hugely complex runtime for a use case that isn’t really used that much (IME).

                                          2. 3

                                            Can you link to this discussion? Sound quite interesting WRT the books.

                                          1. 5

                                            OpenBSD does not support Bluetooth.

                                            This surprised me. Is there any plan to support Bluetooth in future? Not sure I could adopt an OS that doesn’t support Bluetooth.

                                            1. 1

                                              What exactly do you use bluetooth for? I’ve not needed bluetooth on a laptop… ever really.

                                              1. 3

                                                Mouse, occasionally I connect a bluetooth speaker.

                                                1. 3

                                                  There used to be some degree of unfinished bluetooth support. But eventually @tedu noticed it and armed his lightsaber…

                                                2. 3

                                                  Wireless headphones? They are glorious.

                                                  1. 1

                                                    I’ve never had a huge success with them personally. Only use wired generally but point taken.

                                              1. 2

                                                Over the years, there have been a number of these “warts of Scala, problems with Scala, look at how bad Scala is”. I think it is really healthly to have these debates, and it is a sign of a language that people care about. Just to be clear, I am *not” attacking Haoyi in any way.

                                                Does this happen to the same extent in other programming communities/languages?

                                                If not, what makes Scala special in this regard? Is it where the language comes from (EPFL/Martin Odersky), what Scala is trying to do (OO / functional hybrid), or just the people that are in the community?

                                                1. 3

                                                  We occassionally have threads like this on Haskell Reddit:


                                                  1. 3

                                                    As someone who has worked with Scala for the past 5 or 6 years, I’ll say that Scala is just poorly designed.

                                                    • It has a lot features but there’s no check to ensure that they work correctly together
                                                    • Instead of keeping Java compatibility in a useful way, Scala instead consumes all of Java’s problems
                                                    • Syntactic sugar which doesn’t desugar how you expect because of irregularity (e.g. for-comprehension and withFilter)
                                                    • Slow monadic code due to having to trampoline in a lot of cases
                                                    • Implicits
                                                    • CanBuildFrom
                                                    1. 3

                                                      What’s wrong with implicits, or CanBuildFrom, assuming you’re not referring to the silly signature it gives to functions like map?

                                                      (edit: these are not naïve questions, I’m well aware of their design reasons and know they can be problematic, but I don’t consider them as warts)

                                                      1. 2

                                                        Not OP, but the issue with CanBuildFrom (and similar “magic cookies” like ExecutionContext) is that they not only force implementations of the collections API into one specific approach, but also conflate the data you put in, the transformations you intend to run and how these operations are executed.

                                                        That’s why Scala’s collections will never be remotely efficient – CanBuildFrom prescribes that all implementations are supposed to do completely pointless work.

                                                        That design approach is also the main reason of the bizarre proliferation of almost identical, but incompatible APIs in Scala.

                                                      2. 1

                                                        Yeah it’s much more obviously painful when you’ve tried other ML languages, even F# which honestly drinks from a sicker pond.

                                                      3. 1

                                                        Popularity? Scala is probably the most popular[1] advanced language. Haskell has these debates too, but it’s not as popular, so they’re not as visible outside the community.

                                                        Such discourse is absolutely necessary for the advancement of the language, but to those not familiar to the language or the discourse, this discourse gives the impression that everything sucks and things are hopeless. But in reality, for both Scala and Haskell, things are looking up.

                                                        [1] speculation based on stackoverflow careers job postings + TIOBE + github

                                                      1. 5

                                                        If anything it should be performance. Optimization risks being conflated with its mathematical/compsci connotation.

                                                        1. 4

                                                          This also avoids making a judgment call on how to spell optimi[sz]ation.

                                                          1. 1

                                                            optimißation obvs

                                                          2. 2

                                                            I’m a grad student studying optimization… and I clicked on this link to see if it was related. I vote for ‘performance’

                                                          1. 2

                                                            My impression from a distance is that Scala is a language with some incredible ideas in it that has been plagued since the very beginning by implementation problems and a lack of coherent direction.

                                                            Martin Odersky had seemingly moved on years ago shortly after I first heard about the language, and it seems like it never really “broke out” in the ways its fans expected.

                                                            1. 7

                                                              Your comment gives the impression that Odersky is no longer involved, this isn’t the case. He is still very much involved in the language design process and gives talks about it constantly. He is the top contributor to the upcoming Dotty release.

                                                            1. 14

                                                              I’d recommend taking anything Yegor Bugayenko says with a grain of salt, as given the responses on lobste.rs to the submissions of his writings.

                                                              Personally, I think he’s nuts. This article is a good example.

                                                              1. 2

                                                                He also maintains a list of testimonials on his website, so be careful what you say, at least if you don’t want to be mentioned there. Maybe he’s some kind of troll, who knows.

                                                                1. 1

                                                                  Ha! The AMP redirect for that page 404s!

                                                              1. 3

                                                                It’s interesting that lexical scope is only an honorable mention. For all the other listed examples, I can think of major, mainstream languages that do not have them. Lexical scope is the only exception, where I can’t think of a mainstream language today that doesn’t default to it.

                                                                Maybe so widespread that it feels obvious – kind of like a couple of other things I feel should be on that list: Recursion and pass-by-value. Both of those were once the subject of debate, but won so resoundingly that nobody even thinks about them today.

                                                                1. 2

                                                                  Besides the lexical/dynamic distinction, to me an important part of lexical scope is the programmer indicates their intent of where a new variable should be introduced, and as a result shadowing can happen at this introduction point. CoffeeScript does not respect this part of the deal. (Prolog and Erlang are also kind of weird at it.)

                                                                  1. 2

                                                                    Emacs Lisp comes to mind, defaulting to dynamic scope. That said, it isn’t mainstream, but a ton of code is written in it.

                                                                  1. 2

                                                                    Will be interesting whether Kotlin adoption will surpass Scala in the near future.

                                                                    Scala is clearly the better language, but from a developer POV, Kotlin …

                                                                    • has better tooling
                                                                    • has better documentation
                                                                    • has better marketing
                                                                    • has more resources
                                                                    • can leverage existing JetBrain products (e.g. it’s easier to have pain-free interop with C/C++/Objective-C/Swift code if your company already has an existing C/C++/Objective-C/Swift IDE)

                                                                    Considering that “better technology” has almost never won against “better marketing” alone, it seems like the odds are in Kotlin’s favor.

                                                                    1. 7

                                                                      Why is Scala the better language, can you elaborate on that?

                                                                      1. 7

                                                                        I see this claim a lot, but I really don’t understand it. Yes, Scala has more features than Kotlin, but I don’t agree that necessarily makes it a better language.

                                                                        I’d hope we can agree for starters that more features doesn’t necessarily make a language better. The more features there are, the more you have to learn to be comfortable in the language. This in turn increases the chance that any given code base will use only a certain subset of the language. This is why languages like C++ and Haskell have such high learning curves, and also why being proficient in any given C++ or Haskell code base may not immediately translate to you being proficient in another. (E.g., going from a C++ team that has said no to std::move and lambdas to one that does is going to result in you seeing a lot of code as non-performant that works fine, and conversely cause you to be much more verbose than you need to be. Or going from a Haskell project that makes heavy use of lenses to one that doesn’t is going to take away one of your go-to tools for data transformations, requiring you to pick up whatever alternative that project uses.)

                                                                        Beyond that, a lot of Scala’s features have real cost. The incredibly flexible syntax is part of why Scala’s compilation is incredibly slow. (That syntax is also a big part of why Scala IDEs lag behind so badly.) Some features, such as implicits, make code tremendously more difficult to quickly understand and reason about. Other features make interop with Java significantly more difficult (calling Java from Scala’s quite easy, but the reverse can be tricky when you get into Scala-specific constructs–implicits being a great example of that, too.)

                                                                        Kotlin, on the other hand, deliberately does less. It has a more uniform syntax, so it’s not as flexible, but that makes it easier to learn and easier to build tools around. It doesn’t provide enough language-level richness to do some of the things Scala can do, but that in turn means that Java/Kotlin interop is stupidly straightforward, so it’s easier to bring gradually into an existing code base.

                                                                        I do not agree that Scala is “clearly better” than Kotlin. I do think it has more features, but those features come at a cost, and that cost is why I strongly prefer Kotlin.

                                                                        1. 4

                                                                          The Scala grammar is about half the size of Kotlin[1], but its feature set is more orthogonal and powerful. Odersky explains it there from 03:30 onwards.

                                                                          [1] https://www.youtube.com/watch?v=iobC5yGRWoo

                                                                        2. 1

                                                                          Resources wise and marketing I somewhat agree, JetBrains is pushing aggressively, but it’s just trying to get its foot in the door.

                                                                          But better tooling? The best Scala editor is IDEA — the same one you use for Kotlin, marketed by JetBrains, the developers of Kotlin, so it’s the same tooling! Better documentation? Where are all the Kotlin libraries (that aren’t Java) or books?

                                                                          1. 4

                                                                            Scala probably has better tooling, people just have decided to not tell anyone about it. Maybe Kotlin is overselling its stuff, but Scala is hugely underselling its stuff. Tooling nobody knows about is completely useless.

                                                                            Documentation? Just look at the website. It’s a complete trainwreck.

                                                                            • “On which platforms does Scala actually run?” – “Better not tell anyone!”
                                                                            • Downloads that just don’t work for beginners. “Oh, you don’t know what a JDK is? Too bad, no Scala for you.”
                                                                            • Install instructions which don’t reflect how 95% of Scala devs use Scala. “You followed the instructions in the documentation? Guess what, delete everything and start over!”
                                                                            • “Which IDEs support Scala” – “We won’t tell you.”
                                                                            • Glossary which is FOUR major versions out of date
                                                                            • “Tour of Scala” with gems like “Automatic Type-Dependent Closure Construction”
                                                                            • A wiki that has been completely unmaintained for the last 5 years
                                                                            • Documentation spread over roughly 5 different repos to make it extra hard for anyone to contribute
                                                                            • etc etc etc.

                                                                            Official position: “Website/documentation doesn’t need to be more beginner-friendly, because everyone already knows Scala.”

                                                                            My gut feeling is that this language is doomed.

                                                                            1. 1

                                                                              Just to be sure, is this is the website you are talking about? Because if it is, I cannot see how your first four points could be correct. That said, this debate is irrelevant, because Kotiin is new, and needs to sell itself accordingly, and Scala is over ten years old, so it doesn’t have to provide the same amount of simplicity in its getting started steps — the momentum is already there.

                                                                              1. 3

                                                                                I cannot see how your first four points could be correct

                                                                                debate is irrelevant

                                                                                it doesn’t have to provide the same amount of simplicity in its getting started steps

                                                                                This pattern of widespread denial and delusion is one of the many reasons why I left Scala, and I’m far from the only contributor having done so.

                                                                                Just a small hint: Scala on Android had a head start of half a decade and Kotlin completely obliterated it in a few months. People don’t care how old software is, but they care about how they are treated.

                                                                                1. 1

                                                                                  You did not answer my questions. I reviewed your criticism for the second time and still found half of your points to be incorrect. The other half is valid though.

                                                                                  Basically, your criticism is apples to oranges. I’ll explain why.

                                                                                  As a language, marketing wise, Scala does not have the same problems as Kotlin – nobody uses Kotlin, except JetBrains. At least not yet. With that in mind, JetBrains is positioning Kotlin accordingly: making it as easy as possible to use. If you have IDEA installed, you can already use it. That is probably the biggest conversion factor in the language adoption.

                                                                                  So therefore Scala does not need to have the same introductory experience, because it’s a production language with orders of magnitude more users than Kotlin.

                                                                                  A similar comparison would be to compare the introductory experience of Java and Scala. They have a similar age difference than Scala and Kotlin (about ten years, give or take). You google “Java”, you end up at a JRE download page. You have to click an almost hidden “About Java” link on that page where you end up on generic product page, from which you have to follow “Develop Software” to a page that tells you to install JDK and NetBeans. Compare googling “Scala”. There’s a “Download” button that tells you to install either SBT, the scala executable or ScalaIDE/NetBeans/IDEA.

                                                                                  The point is this: Java doesn’t need to. Everyone knows these days that you need to install a Java IDE of some sort. The IDEs will tell you to install the JDK etc.

                                                                                  Conversely, Kotlin is miles ahead, because it needs to, just like Rust, Go, Clojure etc. are doing these days.

                                                                                  As a language, I don’t see anything that Ceylon hasn’t solved, like Ceylon, Kotlin takes nice features from Scala and improves Java in the process. Like Ceylon, it’s somewhat better than Javaslang + Lombok (shudder), and less intimidating than Scala.

                                                                                  Kotlin is a nice language and I hope to see more of it. As someone who works with JVM applications daily, it’s one of the three languages that I hope will surpass Java in popularity (the others are Clojure and Dotty, next-gen Scala).

                                                                                  For what is worth, the Scala on Android story is a sad one. The language authors never really cared about it and it shows. JetBrains is also quite aggressive on that front, because they need to get anyone on board.

                                                                        1. 8

                                                                          If it isn’t obvious, this is an April Fool’s joke.

                                                                          1. 4

                                                                            However, lily is actually written in C.

                                                                            1. 7

                                                                              So the joke is that it was never written in Rust in the first place?

                                                                              The fact that it was a joke is very much not obvious.

                                                                              1. 5

                                                                                Like any good April fools joke, it should make you question why you didn’t know it was a joke.

                                                                                1. 4

                                                                                  It is a joke, however I think there are a few valid point. On the other side check this: https://github.com/FascinatedBox/lily/issues/294

                                                                                  1. 3

                                                                                    I don’t know what the author’s intention was.

                                                                                    It could be an actual commentary on Rust, under the guise of an April fool’s joke. Equally likely, it could be an attempt at satire.

                                                                                    Would have to ask the author to be sure.

                                                                              1. [Comment removed by author]

                                                                                1. 4
                                                                                  Lightweight notation formats

                                                                                  If you really need LaTeX, you can use something like org-mode from emacs, or any other system that lets you write in an easy format, then convert it to LaTeX.


                                                                                  macro packages - You can also use troff. This should be easy to get started as it is alrrady present on your machine to format man page: man 2 name is like groff -Tutf8 -man /path/to/name.1 | less. This is for ‘man’ format, but you also have other output: -Thtml, -Tpdf; and other input formats: -mm, -me, -ms … for papers, books, RFCs…

                                                                                  preprocessors - And then you can insert tables chemical/math equations and formulas, diagrams and drawings… by using preprocessors, that transform a sub-language dedicated to each kind, to the general troff language.

                                                                                  utroff - a well-documented set of macro package for a powerfull implementation of troff: heirloom doctools.

                                                                                  HTML + CSS

                                                                                  Before the web got so popular and still nowadays, HTML + CSS is more a typesetting system than anything else. We pay millions to hire developpers to can make a webapp fit into a typesetting system. We can totally use this typesetting system for typesetting.

                                                                                  All you need is a web browser, and a text editor. Hit CTRL + P and you have a high quality document made by one of the largest software project made by one of the largest IT company, all of that with a debugger that let you click on an arbitrary node of your document to see corresponding source, that you can edit to get immediate result. I do not think any other typesetting system made something as crazy as this.

                                                                                  Bonus: you do not need to learn it: you already know it.

                                                                                  1. 2

                                                                                    I’ve been wanting to switch to HTML+CSS for papers for a long time, but imo the quality of the print output from browsers is still worse then latex, and browser support for the print-oriented portion of CSS is poor.

                                                                                    It is possible to get great print output from HTML+CSS with PrinceXML, but I’m wary of becoming dependent on a very expensive proprietary software product.

                                                                                    1. 1

                                                                                      Better not be dependent on a proprietary expensive software, as you said!

                                                                                  2. 3

                                                                                    We’ve covered a few here recently that are promising (SILE being the one I’m most excited about and most interested in), and there are ways of using TeX without getting knee-deep in TeX itself (e.g. via Pandoc), but there aren’t really any systems right now that have TeX’s breadth and depth.

                                                                                    That said, if your concern is with LaTeX, as opposed to TeX, and you don’t need to work with LaTeX, I personally find ConTeXt on LuaTeX a much saner environment. Similar power to LaTeX, and obviously the same ultimate underpinning, but a shallower learning curve.

                                                                                    1. [Comment removed by author]

                                                                                      1. 1

                                                                                        XeLaTex has support for OpenType fonts installed on the system. LuaTeX has to do this via a package. Both have Unicode support.

                                                                                        1. 1

                                                                                          LuaTeX I just like because you can script in Lua instead of TeX. If you’re just using the verbatim ConTeXt or LaTeX templates, it should work similarly to any other TeX system. (Though, as ane points out below, XeTeX has better out-of-the-box OpenType support.)

                                                                                      2. 2

                                                                                        What is your exact problem? Pandoc/Markdown/Sphinx, LyX and LaTeX-kept-simple all solve (and don’t solve) different parts of this.

                                                                                      1. 2

                                                                                        You could add a long tag and then adjust the “bumpyness” of comments posted after x days, that is, make such comments bump the post up to the front-page. Additionally, make the long tag equal with tags like video or especially pdf.

                                                                                        1. 9

                                                                                          I submit as a counterpoint that, in yosefk’s experience, low-level is easy.

                                                                                          1. 4

                                                                                            Yeah I like this. One observation I’ve had: writing C or C++ is relatively easy, but the corresponding Makefiles and autotools are harder.

                                                                                            Does anyone else feel that way? Once you are situated and understand pointers and all that, it feels pretty easy to write the actual C or C++ code. Particularly if you are only using libc and libstdc++ and not huge abstractions like APR or OpenGL or something (low-level is easy).

                                                                                            But the hard parts seem like getting the compilers and build system to do what you want… debugging preprocessor directives can be harder than debugging the program. Getting the debugger to run against a binary with the right build flags (for an arbitrary open source project) is harder than debugging it.

                                                                                            For one, a Unix-style build system for a mature project requires understanding 3 or 4 different languages: shell, make, sometimes awk, {m4/autotools, cmake, Ninja} etc. Whereas C and C++ is 1 or 2 languages.

                                                                                            1. 3

                                                                                              Learning how to use all tools required to be a truly effective C programmer may indeed be approximately as hard as learning basic C.

                                                                                              1. 3

                                                                                                Where I work, embedded code that runs on our cameras is generally easy to understand, and reads like a captivating yet approachable exploration in low-level systems programming. Our marginally technical product managers can understand this code, and some indeed do send in PRs against it.

                                                                                                On the other hand, our externally facing APIs and various data pipelines are a morass of abstractions and concessions to past scalability problems that make even the gnarliest embedded code look like child’s play. There’s a joke around the office that goes something like “embedded tends to suck in everyone from time to time”, but I suspect that people go there to be productive in a simpler, more straightforward world.

                                                                                                1. 2

                                                                                                  One observation I’ve had: writing C or C++ is relatively easy, but the corresponding Makefiles and autotools are harder.

                                                                                                  Particularly if you are only using libc and libstdc++ and not huge abstractions like APR or OpenGL or something (low-level is easy).

                                                                                                  Those two statements are almost contradictory.

                                                                                                  If your project only depends on libc and libstdc++ and its not using any third party libraries then it’s nobody’s fault but your own if your Makefile is very complicated. Using autotools in that situation buys you nothing but extra complexity and a fancy Makefile.

                                                                                                  IME it’s much easier to create a Makefile template with the targets you want, and then reuse it for small projects. The Makefile syntax itself can be complicated, but 99.99% of the time it’s best to keep it simple.

                                                                                                  1. 2

                                                                                                    Point taken, but if the thesis is “low level is easy” then you can make the comparison between plain C code with no deps, and a huge generated makefile for something with deps.

                                                                                                    In both cases, the higher level layers are what make things hard. I concede that using and understanding the big platform layers in C are certainly more difficult than a makefile.

                                                                                                    I guess the overall point is that on a typical big C project you have two sources of complexity and dofficulty – build time and runtime. Runtime is to some extent essential, but the mess at build time can be fixed.

                                                                                                    1. 2

                                                                                                      Even with simple code and no dependencies, you need a huge messy Makefile if you want to support debug/asan/release builds on win32/win64/Linux/OSX. (doing make clean and changing CFLAGS whenever you want to switch builds is not good enough)

                                                                                                    2. 2

                                                                                                      writing C or C++ is relatively easy

                                                                                                      I don’t feel this way. Writing C that never trips undefined behaviour does not feel particularly easy to me. Also I have to churn out a lot of C code to get it to do fairly trivial things, and then I have to find all the stupid mistakes I left in.

                                                                                                      I don’t think the actual writing of low-level software is itself easier. You’re implementing algorithms on your hands and knees all the time. You so much as look at cc funny and you get undefined behaviour you might not discover for years. The debugging tools are often broken.

                                                                                                      I think yosefk is arguing that being a software developer working on low-level software is overall easier, because the part where you actually write the software is somewhat harder, but everything else involved in the job is easier. You have far less difficulties caused by, for example, people handing you ill-defined requirements to implement.

                                                                                                      I think the important bit of the article I linked is this:

                                                                                                      As a low-level programmer, you have to convince people not to be afraid when you give them something. As a high-level programmer, you have to convince them that you can’t just give them more and more and MORE.

                                                                                                      1. 2

                                                                                                        Well, that’s on you for using autotools and their ilk :)

                                                                                                        Projects under 50,000 lines or so only need a build script like this:

                                                                                                        cd build && clang -Wall -flto ../*.c ../*.cpp

                                                                                                        For larger projects, modern build systems that output ninja are relatively painless.

                                                                                                        1. 3

                                                                                                          It’s relatively painless, but not even close to actually painless.

                                                                                                          You shouldn’t need a several hundred line script to output a several hundred line build config that a ten thousand line build tool parses to run your compiler. But, C doesn’t include any way to specify how your code should be built and our compilers are crap so incremental and parallel compilation are must haves.

                                                                                                          Unity builds solve the problem of needing massive build tools, but your code has to be written to work as a unity build from the start and using 3rd party libraries becomes a big pain. It also doesn’t really solve the performance issues but it does help a bit.

                                                                                                          Compiling your code is one of the biggest pain points with C, and the Jai language is aiming to resolve this by making the build specification part of the language and having a compiler that can build hundreds of thousands of lines per second.

                                                                                                      2. 2

                                                                                                        Do you think systems programming is low-level? This is an honest question – whenever I read something about OS or systems development, like distributed platform development, I see fairly high-level things. Hardware development is low-level though… but what are systems if not hardware abstractions, so by definition, a higher level thing?

                                                                                                        1. 3


                                                                                                          Specifically about this James Mickens' essay here: the essay is about the implementations of kernels, virtual machines, device drivers, databases and the like. The pain this essay discusses is specifically the pain of low-level programming, such as how bugs in the thing you’re implementing can also break the tools that you’d like to use to debug it, such as a stray pointer breaking your logging subsystem and now, in Mickens' words, “I HAVE NO TOOLS BECAUSE I’VE DESTROYED MY TOOLS WITH MY TOOLS.”

                                                                                                          By definition: I think systems programming is “writing stuff intended for applications to be built on top of” so it’s more low-level than applications programming, which consumes the software that systems programmers produce.

                                                                                                          1. 3

                                                                                                            An example I have seen is someone fixing a localization bug, and added logging to debug/verify that it’s working. However, logging actually called into his localization code which infinitely indirectly recursed, causing the system to hang on boot. This ain’t quite an example of low level debugging but it was low enough to break tools your tools rely on.

                                                                                                          2. 3

                                                                                                            In yosefk’s sense, low-dependency code is easy. This describes quite a lot of, but not nearly all, systems code. (E.g. a special case in the PostgreSQL query planner probably isn’t low-dependency.)

                                                                                                        1. 53

                                                                                                          I cannot concede to the author’s point. It sounds like their problems are more due to logistics than anything else. Overall, this article sounds more like “micro-managing development via JIRA sucks”. That, and I think the author is approaching their job with a bit of immaturity. The idea of their ideal workflow is actually destructive in large teams, if not outright dangerous – i.e. working without pull requests, pushing directly to master, with little care placed towards incident documentation.

                                                                                                          One has to distinguish documentation from bureaucracy. Not all documentation is bureaucracy, not all bureaucracy is documentation; it’s not black and white.

                                                                                                          “I create a new branch for my fix, also via JIRA”

                                                                                                          If your VCS tools integrate with your bug tracker (they bloody well should), then it doesn’t matter where the branch is created. I think JIRA & Stash can be set so that you can tag your commits or branch name with a ticket number and JIRA will realize that this is the branch where the fixes are.

                                                                                                          (Whether project or customer management, or the incident reporters, should care about branches, is a completely different topic.)

                                                                                                          “You don’t file a ticket which says “the headline font size should be increased by 0.5px”, you just go and do it.”

                                                                                                          Yes, you do. It doesn’t have to be an actual ticket – it can be anything, as long as it’s documented. Now, I’m not particularly in favour of JIRA-driven development – or letting any tool do dictate development – but jesus christ. This statement belies an extreme misunderstanding of software development practices. One doesn’t simply roam around in a code base looking for problems unless that is the specified mode developers should operate in. Otherwise you’re just doing hobby-project development at work and it is very likely that you’re oblivious to the long term goal (providing working software) and focusing on short term yak shaving (fixing font size because I think they’re ugly).

                                                                                                          I mean it’s a completely different thing to have a backlog and clear it, but this is something that needs co-ordination, not because you have to indulge in processes and management, but it helps to organize backlog clearing into actual goals, instead of patrolling around a codebase as if it were an insane asylum.

                                                                                                          The author’s disparaging of code reviews seems to be rooted in logistical problems, negligent co-workers, than due to any actual fault in the idea of code reviews. Done badly, they are a nuisance, done well, they are extremely valuable.

                                                                                                          1. 5

                                                                                                            “You don’t file a ticket which says “the headline font size should be increased by 0.5px”, you just go and do it.”

                                                                                                            You also don’t need a ticket to open a pull request. I do PR development for my personal projects. It just lets me track the unit I did changes in and look back over the history of them. It also gives me a way to make sure the change passes my checklist (tests) before bringing it into master. It isn’t really expensive and it saves me from letting some silly mistakes in. I don’t make tickets, though.

                                                                                                            1. 7

                                                                                                              It doesn’t have to be an actual ticket – it can be anything, as long as it’s documented.

                                                                                                              A commit is documentation. A PR is documentation.

                                                                                                              One doesn’t simply roam around in a code base looking for problems

                                                                                                              Of course you do — proactively finding and fixing tech debt, test coverage, style errors, etc. is part of being a professional, and the less bureaucracy or process between me and my ability to do that, the better. Ideally it is zero.

                                                                                                              1. 18

                                                                                                                Of course you do — proactively finding and fixing tech debt, test coverage, style errors, etc. is part of being a professional, and the less bureaucracy or process between me and my ability to do that, the better. Ideally it is zero.

                                                                                                                You did not read the latter half of the sentence. It says, with emphasis, that one shouldn’t do bug hunting unless that is the mode one is operating in. For example, one could be pruning the backlog while responding to incidents. This is fairly common.

                                                                                                                However, that sort of work should be somewhat organized. Doing this without any sort of co-ordination or communication is asking for trouble.

                                                                                                                And I doubt the author is currently engaged in this mode.

                                                                                                                1. 10

                                                                                                                  This is true. It was even known back to Fagan with his Software Inspection Process in 1970’s that you should really separate the two activities. The mindset is different enough that he wanted people to focus on building stuff for probably hours/days, then focus only on looking for specific kinds of defects for period of time, then focus on fixing defects, and repeat. Keeps people in the zone with the right information in subconscious mind. The repetition of it with checklists to glance at as reminders.

                                                                                                                  The code review complaints here sound like an organization that’s poorly managed and/or have developers that don’t give a shit. On top of JIRA workflow that also looks bad.

                                                                                                            1. 3

                                                                                                              In my daily life I don’t really encounter many of these. Granted, I use Linux on a desktop computer, and OSX on a laptop. I think the year of “Linux on the desktop (for non gamers)” was around 2010 or so, but Linux on the laptop is still not really reality, though I haven’t tried the new XPS dells. So that has left me with OSX on laptops.

                                                                                                              But on a desktop, as all I do is fool around with a browser or editor it doesn’t really matter. Of course, just last year I had to hop over to Ubuntu since running “dnf update” (without any third-party repositories etc.) installed a kernel that didn’t boot.

                                                                                                              Some steam games work nicely (all Source engine based games), which is fun.