With Python I dislike everything related to packaging.

Rust – TL;DR: It’s a very impressive language with a clear vision and priorities, but the user interface needs a lot of work. Also, the collection library is much better than Scala’s.

• Generics with <>. It’s 2017 by now, we know it’s a bad idea. One of the reasons why the language suffers from abominations like the “turbofish” operator ::<>.

• Strings don’t offer indexing, because it doesn’t make sense for UTF-8. Correct! But Strings offer slicing … WAT?

• Misuse of [] for indexed access. Having both () and [] doing roughly the same thing, especially since [] can be used to do arbitrary things, doesn’t make sense. Pick one, use the other for generics.

• Inconsistent naming. str and String, Path and PathBuf etc.

• :: vs. . is kind of unnecessary.

• Mandatory semicola, but with some exceptions in arbitrary places: struct Foo; vs. struct Foo {}

• Arbitrary abbreviations all over the place. It’s 2017, your computer won’t run out of memory just because your compiler’s symbol table stores Buffer instead of Buf.

• Can someone decide on a casing rule for types, please, instead of mixing lowercase and uppercase names? Some types being “primitive” is an incredibly poor excuse.

• Also, having both CamelCase and methods_with_underscores?

• Library stutter: std::option::Option, std::result::Result, std::default::Default …

• iter(), iter_mut(), into_iter() … decide prefix or postfix style and stick with it.

• Coercions do too many things. For instance, they are the default way to convert i32 to i64, instead of just using methods.

• Also, converting numbers is still broken. For instance, f32 to i32 might result in either an undefined value or undefined behavior. (Forgotten which one it is.)

• Bitcasting integers to floats is unsafe, because the bits could be a signaling NaN, causing the CPU to raise an FP exception if not disabled.

• Forward and backward annotations: #[foo] struct Foo {} vs struct Foo { #![foo] }. Also /// for normal documentation, //! for module level documentation. Documentation already uses Markdown, so maybe just let people drop a markdown file in the module dir? That would make documentation much more accessible when browsing through GitHub repositories.

• Also, documentation can cause compiler errors … that’s especially fun if you just commented a piece of code for testing/prototyping.

• Type alias misuse: In e.g. io crate: type Result<T> = Result<T, io::Error> … just call it IoResult.

• Macros are not very good. They are over-used due to the fact that Rust lacks varargs and abused due to the fact that they require special syntax at call-site (some_macro!()).

• Pattern matching in macros is also weird. x binds some match to a name in “normal” pattern matching, but matches on a literal “x” in “macro pattern matching”.

• println! and format! are very disappointing given that they use macros.

• Compiler errors … ugh. So many things. Pet peeve: “Compilation failed due to 2 errors” … 87 compiler errors printed before that.

C++: Gives me so much power to hang myself and decorate my body beautifully. I love and hate you so much.

Ruby: You were the chosen successor to Smalltalk, but never adapted the VM and the powerful GUI runtime editor. Instead, you eloped and married Rails.

Rust: So elegant, until I get to an inextricable line, and with the compiler fighting me, that line is as painful and takes about as long as giving birth.

Clojure: Its inconsistent treatment of nil remains hands-down the most common source of errors for the codebases I work on. Also tends to be a memory hog. Also bizarrely omits pattern matching from the core language, which is very silly.

Fennel: Shame that the runtime doesn’t support concurrency. The zero-overhead design goal means that it can’t add creature comforts like map/filter/etc; you need to bring in a library for that.

Elisp: Having functions split out into the lisp-2 namespace makes higher-order functions usually too tedious to be worth it. The built-in functions are inconsistently named with weird historical quirks.

Racket: No matter what the question is, the answer will always be “write a macro”.

Rust: I wish there was an alternate version of the language that was garbage collected. It would simplify so much.

Python: In a language that values simplicity, the distinction between attributes and dictionary members always seemed weird and unnecessary to me. Every time I need to look up this, I think that something went wrong somewhere.

Langs I’ve used much less but still mostly appreciate:

F#: There seems to be a slight consensus in the community that Results shouldn’t be used, and that you’re always going to be dealing with Exceptions, so get used to it. I think that’s backwards. If I’m working with an ML-style lang, I want error handling to be explicit.

Go: the nil interface problem is a bug. You cannot change my mind about this. The FAQ literally starts with “Under the covers”– you need to know an implementation detail in order to use interfaces properly. Seriously?

Idris: the main premise is interactive development in the sense that the compiler can add definitions, split a pattern variable in cases, print out the type into of variables in some context (and this info is way more useful than in other languages), and autocomplete holes. There are functions that literally write themselves out of their type.

The major issue is that compilation times get insane. This process works when you start a new file, or use only basic constructs, but as soon as you start using overloaded >>= a lot it can take minutes, essentially removing one of the biggest conveniences of this language.

Another major practical issue is that error messages get broken easily, i.e. unable to find (an often simple) root cause when you’re in some monadic context and need to lift/call.

Rust: I feel that sometimes I have to hit the wall with my head a few times before I’ll figure out how to write this specific line, which simply moves data from point A to point B. Also sometimes the fact that I need to change the architecture of the program is quite discouraging, because writing in Rust has a high-energy cost, but maybe it’s because I’m not very fluent in it.

Ruby: Documentation simply sucks and sometimes it’s a joke. Sometimes I wonder how Ruby was ever a thing with documentation like that. Very often I need to puts() a variable to the screen to know its type, because docs doesn’t say anything about it.

Scala: Why sbt was created anyway? In order to torture new Scala programmers? I’ve spent a long time before I’ve found a clean solution how to write Scala code under Vim (sbt-client) without waiting 10 seconds for clean build to finish.

Java: InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState. Also, JVM is a behemoth; it eats RAM like a hungry cat at 5:30 AM, and its startup time discourages writing any CLI tools in it. Plus, it’s a TOP-1 language on TIOBE Index, and it doesn’t have any decent GUI frameworks for writing desktop apps.

C++: I have a real love-hate relationship with this one. It’s 2019, let’s add a filesystem support to standard library! Then, introduction of auto made things more modern. But, let’s get quickly back to 1970’s because I need to #include a file. Only 5 people on earth have created a full C++ parser, which will get outdated in 3 years because a new standard will come up. C++ still doesn’t have library management (there are contenders: nuget, conan, but still nothing standard).

C: treating a leading zero in an integer literal as an octal signifier is just a spectacularly bad idea (a mistake sadly replicated by countless other languages). Also, the fact that int* x, y declares one pointer-to-int and one int is utterly nonsensical.

Python: lack of type checking is painful; the fact that they added type annotations but made them semantically equivalent to comments just adds insult to injury. Also, the enum bodge, ugh – why even bother?

Bash: while set -e is still helpful enough that I typically use it in scripts, it has many sharp edges and totally unexpected quirks.

I love Clojure, but we need to have a talk. Specifically, the use of nil-punning is pretty terrible. (if (seq xs) ...) is not actually a good way to spell (if (not (empty? xs)) ...) but both the language designers and the community embrace this conflation of null and the empty sequence. There are other issues around nil and collections as well.

Kotlin is my current favorite, but it’s not OK that the best way to write Kotlin currently involves a behemoth of an editor that takes like 2 GB of memory. I can write Clojure in Emacs, which only takes about 80 MB.

Ruby: Mixins can make you feel like you are improving code, but I’ve seen some Ruby classes with a dozen modules included. It makes the class “smaller”, but adds a ton of misdirection. It leads to situations where 1000 lines of interrelated code are split over 100 files.

6809 assembly: Why do you not allow indirect indexed with direct addressing? You allow JSR [$A002] but not JSR [$02] (8-bit address; DP provides high address). That hurts.

x86 real mode assembly: Segment registers. I know why you have them, but I don’t like them.

x86 32/64 bit assembly: Stop. You are already the King of CISC. You can’t stop adding new instructions now. Having a 1000+ page tome describing your instruction set is silly.

Forth: stack noise words like DUP, ROT and DROP litter the codebase.

C: Undefined behavior lurks everywhere. One comment for the standard committee—stop pretending the world hasn’t standardized on 2’s complement with wraparound. That’ll force compiler writers to stop pretending it doesn’t exist and break working code.

Lua: You are missing += (and others, like *=, etc). This isn’t bad for things like i = i + 1 but it is seriously annoying for things like a_long_name[another_name] = a_long_name[another_name] + 1.

Go: I dislike how much it penalizes you for trying to hide your data. Especially when it comes to dealing with reflection based serialization. This is a deep consequence of how the language is designed and is a trade off from other features of the language, like default values for all types, which have their own benefits.

Rust: My biggest gripe at the moment is probably compilation times, but that one is kind of boring. I have other boring gripes. I think my most interesting gripe is the lack of GATs, or otherwise some mechanism to permit iterators (or an equivalent) to return a borrow to its internal state. It prevents a lot of interesting performance related patterns. Thankfully, it appears to be on the path to fully supported async/await, so I am hopeful. But at the same time, I lament the additional language complexity that it will bring.

On some level, I love C. It’s really easy to write C programs with massive security holes because something you done ended up being undefined behavior. It’s not really doing its job as cross platform assembly with syntax sugar, not is it a nice modern high level language.

I love Python. I wish the python 2 vs python 3 bollocks was over already, and I wish doing a sync stuff with it was as nice as with JavaScript and promises (including the community support and adoption JS promises has).

I love Go, but I generally prefer when packages are identified through their names rather than their github URLs. Also, GOPATH can go fuck itself. In general though, it’s an awesome language in-between dynamic scripting languages and C.

I love Rust on a conceptual level, but its syntax is intimidating and I haven’t taken the time to learn it.

I like C++, but the standard library and other libraries rely wayyyy too much on template magic, to the point where error messages become megabytes of incomprehensible compiler soup. There’s also so many ways to do things, each with its own really subtle but important set of pros and cons, that it’s easy to feel paralyzed by choice. Also, compile times are truly ridiculous, with whole-day compile times not being unusual for the bigger C++ projects out there.

I love JavaScript, especially after ES6, but I hate the community. Any serious JavaScript project ends up with thousands of dependencies, and as someone who feels like I’m responsible for my whole project, not just the code I personally wrote, that’s a hell of a burden.

C: Look, man, I really love ya, but can you maybe chill with the undefined behavior? Right now, your choice is between under-defined signed integers and unsigned integers. Can you maybe give us a portable way to clear sensitive memory? While you’re at it, remind me why I can’t assume uint8_t is an unsigned char if uint8_t exists; can we do something about those aliasing rules there? Devil’s in the details, and it’d be nice if we could maybe figure out those details and ignore one’s complement and 36-bit integers for a second.

Perl: I think at this point it’s too late, but function calls with & will never sit right with me.

PHP: Your documentation is generally useful, but I do wish that you’d hoist user comments into the “main” documentation on occasion.

Ruby: Please stop iterating so quickly. A release every couple of years is fine. You’re making life hard on Debian when everyone jumps on the new feature bandwagon. And please get your documentation in order; the OpenSSL module is basically “fiddle in irb until it works) land permanently, and separating out half of the core modules (but not all) onto a separate website keeps getting me.

Java: I hope you were listening for the “iterating so quickly” part I just told Ruby. Because you’ve now started going down that dark path, too. Lambdas just broke the paradigm, too, so now it just feels kind of alien at times.

C# (or .NET in general, I suppose): I want to like you, but your portability is just not quite there yet if I want to use you on OpenBSD. Maybe someday.

Literally everything that isn’t C or C++: Operating systems have package managers for a reason. Please at least try and cooperate with them. I’ve already given up that idea that you write some kind of man-compatible format like Perl does.

Python: The major additions to the language in the last few point releases feel like they’ve expanded the surface area of the language significantly, without really adding useful affordances that would change what I use Python for in the first place. It no longer feels like the calm, simple language I fell in love with.

Clojure: Close JVM integration is a crutch as much as it’s a boon. It’s hard for me to feel like I’m working in a real, self-contained language when things like the backing Java class for a map instance are leaking all over the place in stacktraces. I don’t see how nil punning provides any value at all.

Rust: This is petty, but I’d like a better IDE experience than is currently available. A GUI library without extensive caveats would be nice.

Haskell: The documentation culture is extraordinarily offputting in its terseness (especially for modules providing less-publicized abstractions like e.g. bifunctors).

Python: I wish asyncio never happened.

Racket: I wish the compiler was faster and that it had better error reporting.

Despite having used many other languages, I don’t think I can say I love any of them as much as these two.

Python: The GIL ruins lots of things. https://realpython.com/python-gil/ :(

Common Lisp

Backquote doesn’t guarantee the resulting list structure is freshly consed, so using it as a quick way for “templating” lists isn’t completely safe.

There’s no reliable way to determine whether a stream is a binary or character stream, i.e. no way to answer “can I call read-byte on this thing without it erroring?”. There’s no binary-stream-p or character-stream-p, and stream-element-type doesn’t work for bivalent streams:

(subtypep (stream-element-type *standard-output*) 'character)
T

(write-byte 64 *standard-output*)
@

You just have to try calling read-byte or write-byte and see whether it errors, but of course that has side effects. Welp.

read-line always returns a string, even if you’re reading from a stream with :element-type 'base-char. So if you want to read lines and get back simple-base-strings for performance (e.g. when reading data from 20gb FASTQ files), you have to implement that yourself. (I’m not 100% sure the standard requires this — maybe this is something an implementation could actually do.)

peek-char and unread-char are nice, but there’s no peek-byte and unread-byte.

Pathnames are bonkers.

If you want to write a nicely-behaved iteration macro in pure CL you really have to use do as a base, not loop (and do is annoying to use). Otherwise if a user uses your iteration macro inside a loop and calls loop-finish it won’t do what they expect.

Allowing defmethod without a corresponding defgeneric makes it way too easy to typo the method name in various ways and spend 15 minutes wondering why the hell your method isn’t getting called.

(subtypep 'real 'complex) ;=> NIL

Package local nicknames aren’t part of the standard. This is improving though — most of the major implementations support them and there’s a trivial-package-local-nicknames library now.

There’s no custom hash functions for hash tables in the standard (there’s a portability library for it though).

There’s a lot of fancy features on arrays that not very many people use (e.g. displacement) that make it harder for implementations to optimize them unless you do everything with simple-arrays. Removing some of the lesser used features would let implementations do more.

Performance profiling is not great. SBCL’s statistical profiler is alright, but not as nice as something like the profiler in jvisualvm.

There’s probably more, but that’s all I can think of off the top of my head.

SQL is hardly one language but a fragmentation of competing languages (PL/pgSQL, T-SQL, PL/SQL, ..?) that will likely never converge. Handling of nulls can surprise you in bad ways (not in !) that might take you a long time to figure out (no errors, no signs). Migrations & packaging are kinda DIY / leave-it-to-the-framework. SQL really deserves a standard lodash library: there’s still no pad-left in T-SQL, and group_concat/string_agg took ages to ship.

Haskell: the syntax. Yes, it’s as basic a complaint as they come, and I shouldn’t care. I even like minimal syntax in general. But it always seems to turn into operator soup. Also, I dread having to compose monads.

Python: type annotations are almost completely useless. async fn is hacky and feels like a shark-jumping moment. I despise refactoring a system in Python, which always happens. The GIL.

Ruby: the ecosystem was taken over by Rails, which encourages unnecessarily tight coupling in a dynamic language, making refactors/upgrades awful.

C++: header files are a burden to keep in-sync with the corresponding implementation file. std::move() is utterly laughable when compared against Rust (“the moved value is considered to be in an invalid state and should not be accessed”). The whole trend of deferring runtime type checking to libraries like Boost.Any mixes slow compile times, templates, and runtime type-checking to achieve the worst of all worlds.

Kotlin: the right ideas in a language without the conviction to go all-in on them, resulting in a proliferation of syntax.

Rust: compile times. Lack of native UI libraries on most platforms (excepting GTK), and, more importantly, this isn’t seen as a problem due to the existence of WebViews.

Objective-C: the memory management story really suffered, Cocoa was horribly documented, and of course now it’s on the scrap heap of history.

OCaml: the Batteries/core split is really maddening.

Haskell: I am not entirely in love with Haskell, but I do like it a great deal, but man alive, it can turn into operator soup pretty damn quickly, and the packaging/build story is … deeply, tragically suboptimal. No, I do not want to use nix, thanks.

SQL: It’s not closed under composition, so you have horrible workarounds to do basic declarative things; it’s a 4GL mess of syntax; it gets the ordering of projection and selection completely backwards; and the NULL treatment is an abomination.

Erlang has some confusing error messages.

C++: My true love, but even two full decades after C++98 you are still trying to absolve the sin of template overuse. And you really, truly need something better than #include (I personally love #import from Obj-C, maybe look in to that). You finally have first-class lambdas, so I have hope for you yet.

Python: Giving everyone so long to stick with Python 2 has ruined the ecosystem for me. Even as recently as two months ago, I still had issues getting upstreams to accept patches to let their code run on either 2 or 3 because they were so afraid of losing compat with 2. You should have killed Py2 off when 3.3 came out and forced everyone to use the objectively better 3. Also, pip still has silly bugs that are unfixed after years. I’ve lost a lot of my hope for you, but maybe in a few years when 2 is Really Truly Dead things will look better.

C♯: You’re a beautiful, modern language that is basically unusable on any usable, modern platform (Linux, OS X, *BSD) primarily because there are three warring .NET implementations (Mono, .NET Core, CrossNet) instead of the community just committing to one and making it run really well.

F#: Despite being an “ML” the metaprogramming functionality leaves a lot to be desired. Code quotations really aren’t all they should be for example. Type providers can’t generate F# types.

Rust: Refactoring something is a pain in the ass. For example, if I’m working on writing a new struct and think I need a lifetime as part of the struct, I have to add two annotations to each impl block where the lifetime is used. Although this has gotten better with lifetime elision, it’s still just a lot of boilerplate that makes it incredibly frustrating to deal with.

Python: Please let me have static types, I’m begging you (mypy is getting there, but it’s not perfect)

C++: After writing Rust, and then trying to move something without using std::move, 1000 lines of error messages leaves me aghast at how people are able to be productive in this language. I realize that you begin to see patterns in these error messages (e.g. trying to copy something without a copy constructor) and if you really take the time to read a handful of error messages, you can usually pinpoint what’s going wrong. But it’s a lot of work.

Scheme: car and cdr just upset me; who cares how they were originally implemented on the IBM 704? Also, as much as part of the reason I love Scheme is how small it is, there are some very blaring omissions that virtually every implementation adds as (incompatible) extensions, and that is pretty silly.

Python : I loathe the choice of the + operator for string concatenation. I looks ridiculous to me. Addition is commutative, and string concatenation is the least commutative thing there is. Any other operator would be a much better choice than plus: the product, a dot, a space, whatever. Heck, even the minus operator (which looks like a hyphen) would be better than plus. I force myself to use string formatting in convoluted ways just to avoid the concatenation operator; it just freezes my blood when I see it.

Elixir: Sometimes it rely too much on sugar. For example why make :console logger backend “special” when it could be used in the same way as any other Logger.Backends.Console?

Rust: I still dislike how ? works. <> choice for generics.

SQL: It should be QUEL that won. The SQL syntax is pretty much inconvenient.

JavaScript: class syntax obscures the prototypal inheritance behind the scenes, causing confusion particularly for folks who are not familiar with it. Promises are nice but their syntax is not great if you’re not using async/await. There is probably too much syntactic sugar going into the language right now.

Lua: 1-based indexing. I always forget. Also, weird syntax like -- for comments or .. for concatenating strings.

Python: Py2 is still a thing and still confuses folks. I really, really, really hate writing self as the first param in methods.

LuaJIT: Mike Pall abandoned it and nobody else can understand the codebase :(

Python 3: Making the REPL harder to use. To give one example: That dict.keys() returns a dict_keys instead of a simple list like it used to. I’m sure there’s a good reason, but it still drives me crazy. The REPL (and Notebook) experience is what keeps me coming back to Python. Otherwise I’ll just write Typescript.

Edit: Here’s another one. map has become lazy, and now returns a map object that I have to wrap in list to see what the results are. I don’t think I have ever wanted that. map should map the function over the collection and return the results as a list, like it used to. Stop making me think!

Edited again: Also, doing anything async related in the REPL is just painful.

Javascript: Ok, I don’t really love JS. But I do a lot of work in it. And I think adding generators was a mistake. They’re so rarely useful to anyone, and they’re difficult to reason about and test compared to… anything else.

I think C# would’ve been better without properties.

Python has batteries included but some of them are puffy and corrosive.

Haskell: It’s incredibly burdensome to get a usable environment to work. Especially since everyone has started pushing the LSP stuff.

(Common) Lisp: It’s standard library has too many compromises to please groups from the 1960’s. The file system tries to support everything from case insensitive file systems to ones without directory hierarchies. Most things practical issues require installing the same external libraries again and again.

Rust allows you to build structure to your code, but this structure can easily turn into a maze where you need to “just know” about the trick door that lets you get to the end.

Common Lisp has too much ancient baggage. In practice people just don’t use the clunky archaic parts, but it would be nice to not have them.

Scheme: I’ve never actually programmed in Scheme or any Lisp dialect. I’ve just learned to read it well enough to follow along in SICP and SICM. I find it beautiful and ineresting, and Sussman uses it brilliantly to convey his ideas. Here’s the problem, nothing in the language specification requires it to be readable for humans. We depend on the author judiciously inserting white space, line breaks, spaces, tabs. This is a convention, not a requirement of the parser or compiler/interpreter. Even when well-formatted, I still find longer snippets difficult to read. I don’t care for the blizzard of parentheses.

F#: This has been my go-to language for over 6 years. I have 2 problems with it: 1) Too much of the Microsoft F# team’s valuable time has been wasted in the past keeping it compliant with changes to C#. Ironically most recently this had to do with C# nullable types, which was an attempt to catch up C# with F#. 2) The temptation to do overly-sophisticated things with the F# type system is just too great. The type system is good, but not that good, and improving it and cleaning up existing issues, like the problems with statically resolved types (basically making SRTPs more useful), is often hindered by problem 1.

Rust: long compile times. Far and away the biggest problem with Rust. Luckily, I’m not the only one who feels this way, and many people are working on it.

Rust: For me, I get confused by the fragmentation of solutions that exist for common problems out there. Asynchronous programming has been one of the most anticipated features for Rust and I still don’t know what will be accepted by the community. We have tokio, async-std, and runtime just to list a few. Having choices is nothing to complain about but they all have their own interpretation of what asynchronous programming should look like. I know this feature is stabilizing in Rust soon so hopefully that will settle things a bit.

Python: It’s slowly developing static types… without the benefits of becoming a compiled language or at least having significant speed improvements. asyncio is a mess and the packaging is a well known never-ending source of problems. Transitioning from Py2 to 3 with hard compatibility-breaking changes was a terrible idea.

Nim: It’s unpopular. The async system and packaging are in line with Python.

PROLOG: It lacks a modern-looking syntax to fit the popular taste.

Rust: like how burntsushi said, compilation times yes it’s the worst and also the most boring complaint, but I’d say part of this is how easy it is for a dependency to pull in a massive number of proc macros, overzealous generics, and outdated versions of crates you use elsewhere. I guess that can be mitigated by simply living as a hermit and not using other peoples’ code though. My real gripe with the language itself would probably be how coarse lifetimes are. It’d be nice, for example, if I could more easily produce split non-overlapping borrows on collections without transmuting lifetimes. It’s a hard problem to solve though, about hard enough to where I don’t understand what it’d take to solve it

Python: namedtuple is awkward.

Rust: The compiler is slow.

D: The community is so small. I’m skeptical about the meta-programming power because it makes the fast compiler arbitrarily slow. Some defaults are done the wrong way, e.g. default is unsafe and you have to annotate @safe.

I guess I’m a little bit late, but I love Emacs.

1. Concurrent operation support is still really lacking. It’d be nice if most calls got their own thread or something, so that downloading mail doesn’t hang my whole operating system (which is basically what Emacs is, right?)

2. Maybe something of an extension to the above, but while Elisp is still waaay better than most other languages I can configure editors with (except maybe Fennel in TextAdept, but I can’t do all my Emacs stuff with TextAdept) it’s indisputably pretty bad these days. Replacing it all with a more modern scheme would be nice, but I think it’s definitely unrealistic. (What I absolutely do not think is the answer is to simply reimplement everything in Rust.)

3. I run Emacs in a terminal, which is general considered not that worthwhile because GUI Emacs has so much good stuff. I don’t run a display server a lot of the time so it’s just the easier thing to do. But the way that the graphical Emacs runs is a bit of a mess, and doesn’t really work in the way that a GTK application is meant to. It’s definitely a hack.

4. Like most big old pieces of software with a long history, Emacs comes with a bunch of legacy support for hardware and software which pretty much no one uses. I’d argue that if you’re still using a 40-year-old operating system today, you definitely have the nous to maintain any software you might need as a separate fork, leaving the main project with a cleaner codebase and less wasted resources making sure that stuff still works.

5. Syntax highlighting support is not great. So syntax highlighting is provided by a mode, normally the major mode but sometimes minor modes like to get in the fun. Emacs doesn’t come with major modes for a lot of languages which are pretty common these days (Lua, Markdown, web-mode), which means that not only do I miss out on language-specific features, but also that I don’t see any syntax highlighting by default. Vim doesn’t have this problem, gosh darn! In the same vein, syntax highlighting is slow. Font-locking a hundred-line org buffer on my phone visibly drags it. Using some kind of PEG system for syntax highlighting would be cool.

And finally, because 1 and 2 were kind of similar, and also because 6 is a perfect number after all:

6. The packages Emacs comes with out of the box are an ecclectic mix. It’d be nice to have a sort through and prune out a lot of the junk (in my opinion). For example, viper mode is available by default, even though Evil is a significantly better vi emulation. Emacs has a rich history and in some ways pulling out the bad stuff is kind of chipping away at that (following this logic, tetris would almost definitely go), and I don’t know if I like that, so it’s difficult - but I still think it’s a bit of an issue.

Regardless, Emacs is a pleasure to use and I like it to bits.

English: I know you mean programming languages, but since I’m not a native English speaker I consider English a tool. Something I don’t like about English is how random written English seems, specially vocals, they have so many sound variations, that’s specially difficult when you learn vocabulary by reading, sometimes I know the written word, but if someone pronounces it I can miss it if that’s the first time I hear it.

Python - Though I’ve gotten used to them, the syntax for list comprehensions is unnecessarily obtuse, especially considering how un-clever the rest of the language is. Also, some of the libraries adopted as standard like argparse, logging and test_unit are straight lifts from Java and are pretty awful to use. The community has built far superior offerings - pick one!

Perl - This is 2019. I totally resent having to manually unwrap references in data structures and pop values off the argument stack. Having the flexibility to do these things in non standard ways just isn’t helpful. I’d rather focus my energy elsewhere, and when i’m forced to read code where people do crazy things it’s just painful and awful and WHY?

Bash - the array syntax seems unnecessarily verbose and easy to screw up.

I saw this thread coming from a mile away. ;) This is actually one of my favorite interview questions; IMO if you love a tool enough to actually use it regularly, you should have found pain points in it.

• Rust: Ownership is hard to grok (which is not helped by borrow checker limitations, so things you can easily determine are safe in your head may require significant modification to pass the borrow check). Ecosystem is very unstable. Severe language-level feature creep.
• Kotlin: Nullability is awkward and limited in more complex cases (e.g. there’s no way to have the equivalent of Option<Option<T>>). Ditto for smart casting (e.g. you can never smart cast a var field). It has sum types, technically, in the form of sealed classes, but they’re rarely used. On the JVM, inherits a bunch of JVM weaknesses (e.g. all those non-nullable fields are actually nullable, and are in fact null during initialization). Tooling is surprisingly rough, given that Jetbrains is a major sponsor.
• SQL: Syntax is mega-awkward. Composibility is nonexistent. APIs are surprisingly bad. SQL injection. It scares people enough that we now have to contend with ORMs. (All this is, IMO, a small price to pay for a very widely-supported, well-understood mostly-declarative query language.)

Clojure: Dependency hell with Leiningen. Occasional very confusing performance issues with the JVM. Dealing with IO stuff is always very frustrating (although this is probably more on Java). Very easy to make mistakes with lazy sequences.

(SWI-)Prolog: The module system seems very “leaky” and, while the “pack” system is nice, there isn’t a built-in way to version the dependencies.

Clojure:

1. I need to be running a JVM, including in production.
2. Java only dependencies can introduce dependency hell. Ask me about writing Excel format files. Or don’t, it’s been a while.
3. Checking for empty or null with seq, as suggested by upstream, is not as easy to read as just (not (empty? Thing-Here))
4. It is but straightforward or commonly documented for how to do repl driven development, specifically with choosing active namespaces automatically on repl startup. It’s easy to do, just one line, but not without hunting for that line.
5. The abstraction leaks too much when switching from the JVM to JS. I don’t want certain library functions to need a different signature in cljs than in JS (looking at you, transit).

Haskell It doesn’t have dependent types and it has a garbage collector, so I keep reaching for Rust or something like Idris, thinking it will better suit my problem, but I always end up back with Haskell.

I think being a Haskell maximalist is the new bitcoin maximalism.

I like Scala. I worked at two jobs and a startup where I did a lot of professional Scala work.

I hate some of the overloaded operators used in some libraries, as well as how complex some libraries are. That combined with implicit to make Domain Specific Languages is really terrible. You can’t understand what’s really going on with some tools, or fully dissect error messages, without a PhD in category theory.

F#: Should have been more like OCAML++/Haskell and less like “FP for nerds who don’t wanna C# no more” Type classes, functors, better notation. I could go on.

C++: What the hell did you do to this? Is Keep It Simple, Stupid just too hard to understand?

HTML/JS/Web Tech in General: See C++ above. Also, who is the genius that came up with the idea of trying to reproduce the entire universe of technology inside the browser, from data storage to low-level code?

PowerShell has a horrifying number of “gotchas” you need to be aware of for complex scripts/modules.

Scala. sbt is great once you learn it but learning it is like learning rocket surgery. Compile times will only get faster. Implicits are great but they can really suck to debug without a good IDE. IntelliJ has only gotten good with them in the last year or so. When I started doing Scala in 2013, my team simply avoided implicits because of how difficult they were to trace.

Scheme: implementation fragmentation, especially when it comes to bindings with external libraries. R7RS small, and cond-expand have certainly helped, but I don’t think it’s quite there yet.

Go: reading from nullable columns with the default sql library is, in my opinion, needlessly painful.

TypeScript: if and switch are statements rather than expressions. In Rust you can assign to the result of an if but in TypeScript you have to use either a ternary or a mutable variable.

[Comment removed by author]

Elixir

• Does a bit too much magic in its parser. Calling functions without parenthesis, combined the compiler trying to figure out what -> should be associated with in a case expression, can make your parser error messages or incorrect runtime behavior really painful to figure out.

• Should have had mix release built in from the beginning. It’s a language specifically designed for writing network servers; there’s a reason Go made such a big deal of creating self-contained binaries.

• Probably should’ve had pipelining put the piped parameter last, for consistency with Erlang’s existing libraries.

• IntelliJ-Elixir is very, very slow. I’m not sure if the plugin is just badly-written, or if IDE work is excessively hard in Elixir.

Ruby: the Array() constructor doesn’t really do what people want but people keep using it because they think they “should” do that when they want to wrap a pre-existing object instead of just using a literal. It’s a bit too easy to accidentally create a local variable when you were trying to call a peer instance method. Rubocop’s constantly expanding and ever more squirrelly and specific formatting rules have long since passed the point of diminishing returns, but the updates and new rules continue apace. Also the community has a significant, frustrating portion of developers and bloggers who think they’re writing in Java or some other static language, and really mis-apply patterns from those languages in Ruby without doing enough thinking about whether or not there’s a less tortured way of accomplishing what they want that would make more idiomatic use of Ruby’s strengths (blind enthusiam for an overuse of parameter-based dependence injection being a super obvious example of this).

Scala: SBT fucking sucks, and the spotty documentation does absolutely nothing to improve the situation. Scala’s Either with Left and Right having “conventional meanings” is fuckawful and insane and coworkers seem to love using it to write impenetrable, opaque code – about half the time they get the convention backwards, probably because the convention is backwards. Implicits were a mistake. Also the community also seems to be drifting away, and there’s a lot of wheel-reinventing required if you want something native feeling instead of using Java libs and feeling like you’re writing Java in Scala.

Go:

• It’d be super nice if it had a properly supported GUI toolkit, even if it was just TCL/Tk.
• I’m the group that can live without generics, but would really like to have them
• Error handling is more verbose that I’d like it to be. It works ok in webapps where you can just panic if you’re needing to stop the request, and can set a global handler to do the right stuff, but it makes exploring ideas a lot more tedious

C#:

• The deployment story for anything written in C# is messier than I’d like, between ClickOnce, publish, setting things up in IIS, and so on. It’s not terrible, but it’s not nearly so easy as Go
• Equality is messy in C#. To do it right, you have to define an operator, implement an interface, and work out a way for your object to generate hash values.
• Microsoft has at least 3 ways to accomplish many important things, with different tradeoffs:
  • User Interfaces (WinForms, WPF, Silverlight, etc),
  • background threading (BackgroundWorker, TPL DataFlow, Threads + BlockingCollection, etc),
  • Websites (ASP.NET MVC, WebForms, and the versions thereof)
  • Database access (Linq to SQL, Entity Framework, ADO.NET, which seems to sit under the other two)

Lua:

• The documentation is pretty sparse. It’s there, but one ends up rolling one’s own versions of things more
• 1-based indexing is a big turn-off for a lot of people. I don’t mind it, but it is a transition cost when moving in/out of it.
• function instead of func or fn makes me sad when I want to write higher order code.

Clojure - so elegant and fun to write coming from an OOP background. I constantly get hung up when you need to bring in new dependencies due to classpath weirdness. Sometimes, restarting the repl is the fix, other times not.

Python - Love the brevity of it, but I would love some editor help with parameter types. I have to try out mypy still. I use PyCharm, and I’m constantly surprised how little autocomplete and keyword highlighting helps me make sure I am using valid keywords, types, etc. Maybe I’m just underwhelmed with the tools I use….

Go:

1. It does not plays well with other programming languages and cgo is a mess. This results in situations where you would feel everything is going well right until the moment you have to interface a program written in Go with a program written in any other language. I don’t like this and I believe it should be more co-operative.

2. nil.

3. Lack of enums. You can sort of hack your way around with a custom declared type but it’s not pretty and I’d like to see better builtin support for those.

Rust:

1. It’s a vast language and it was much more intimidating for me given my background was in writing Go almost exclusively.

2. I had tried to get into async/await in the past and it’s all very complex and confusing. I gave up a few times after reading random blog posts and tokio docs and only recently(read, this week) got into async/await by reading up the async/await book and just experimenting with it.

3. Lack of libraries. Go has a very good library ecosystem and I miss that in rust.

4. I assumed traits were like interfaces and made huge refactors in my code and only later learned that they are actually not like interfaces and I had to undo all the work I did.(learnt some important lesson that day). The issue I faced was, There is no safe way to get the underlying concrete type from a trait.

5. Compile times

C: having tons of ways to interpret (). As a ( *function ), as container for parameters to a function(p1,p2), as a cast (int)long or as the simple mathematic precedence to calculate 2+(5*3) in the correct order. Somehow the compilers gets it right even though I might not always.

Love Clojure, but like everything it’s not without its problems. I think that conj having a type specific behavior was a mistake, especially for a dynamic language. When you use conj with a vector it appends, but with seqs and lists it prepends. Seeing how most standard library HOFs will return a seq it’s easy to miss the type changing from under you.

The Go runtime is terrible and rules out Go’s applicability to a huge set of problems.

I like JavaScript, especially TypeScript. But just about everything touching it is a garbage fire.

• Community obsessed with polluting the global package namespace trying to make a name for themselves
• Published artefacts full of garbage like test code
• Global namespace. In fact, just about every decision made by the npm team
• No (easy) ability to publish artefacts for specific environments under a single name (like es5/node, modules/node, browser, etc)
• Everything is designed to be as small as possible, requiring thousands of packages and dependency bloat

I could (and do) go on…

Haskell’s indentation aware yet extremely fragile syntax, also laziness.

Typescript has been very pleasant to work with, but sitting on top of the JS ecosystem is a blessing and a curse.

JS itself is becoming less horrible, but again the underlying ecosystem is a clusterfuck.

Clojure is fun and interesting to play with, but I really, really like types.

Haskell is also interesting, and has types, but the amount if effort to become proficient is plain intimidating. I wish I’d found it in my 20s (rather than my 30s) when I could have aunk some serious time into it.

For C and C++, speaking as a novice programmer who grew up with BASIC on a TRS-80 Color Computer, I have to say that I dislike that every time I declare a new variable I have to remember to set it to zero or an empty string depending on my needs or else there could be some sort of garbage in it. It would save me a lot of extraneous typing of things like “int foo == 0;” if the variable could start off blank or zeroed when first declared. I know this is a small thing to quibble about but for me personally, this sort of thing irks me.

Ruby: if your only parallelism story is processes, then pretty please with sugar on top can we get that compacting garbage collector?

Ruby: I didn’t like Rails when it was still new(ish), and I still don’t like it, all the way up to today. Sadly, Ruby was and is too often conflated with Rails into one single thing, which they aren’t. The ecosystem has hardened so much by now though, that you can hardly find developers or gems that don’t assume you’re using Rails. On a minor note, I am occasionally jealous of some of Javascript’s syntactic sugar like destructuring.

Go: has constant strings, but not constant byte slices.

Scheme: The already small ecosystem is deeply Balkanised and writing a large Scheme program that works on multiple implementations is nigh impossible without expending great effort on portability. You have to pick an implementation and stick to it. As a consequence, the library selection is scarce. Even Common Lisp is better than Scheme at cross-implementation compatibility.

Clojure: I can’t stand the worse-is-better approach that deviates from the Lisp tenet of do-the-right-thing. The “let someone write a library for it” principle puts me off. The majority of useful libraries that do something that really should be in the core library are abandoned on GitHub.
Edit: Oh and Clojure’s nil punning is a ridiculously bad design pattern and you can’t change my mind about this.

Go Why make dependency management hell?

PHP Why didn’t we get typed class properties when we got typed function parameters?

Ocaml: surprisingly poor support for namespacing modules, usually bites me when I’m trying to link in a new library and it clashes with one of my modules.

Racket: Memory usage of the GUI framework (100+ MB) makes me sad.

Ruby: Seems to be standardising on a clunky syntax for type annotations. Python has a far more readable solution for the same thing.

Over the past 5 years, I’ve been thinking of what programming language I truly 💙 (or want to), and two contenders have emerged.

Common Lisp: I write Clojure for $DAYJOB, but right at this moment, my biggest problems I have with CL are the modern niceties that Clojure has. Clojure’s lazy sequence abstraction and the rich standard library for manipulating them, first class concurrency primitives, immutability and persistent data structures. Many of these things do exist in various forms in the CL ecosystem as libraries, but it is by no means standard practice.

Perl 6: From what I can understand (barring the complexity of the language), the only real hindrance to adoption is the performance issues, and fledgling library ecosystem. They seem to be actively working on performance, so it will be interesting to see how it turns out a few years later.