Create account

DEV Community

What are the best and worst things about your favorite programming language?

Ben Halpern on March 05, 2024

What is your favorite programming language, and what are the best things and worst things about working in it?

Isaac Lyman • Mar 5

It's a tough call between C# and Dart. But I think C# has the edge.

The good

Boring and predictable
Great support from Microsoft, with new language features on a regular basis
Concise, expressive syntax
LINQ (the built-in functional-style collection extension library) has everything you could ever want and makes you feel like a genius
First-party support for web APIs, no third-party framework required
Very fast for such a high-level language

The bad

Only portable in theory. In practicality you're locked into the Microsoft stack by convenience and defaults: .NET Framework, Visual Studio, SQL Server, Azure, Windows. Again, you can break out of this, but you'll be carving your own path through the forest.
Hot reloading is also purely theoretical. Most of the time it's a stop-and-recompile development cycle.
The configuration for .NET Framework apps is XML-based and it's a bit of a black box because the documentation is very spotty and frequently out of date. Messing around with config files is always a bad time. Contrast with Node.js, where everything is JavaScript and if something is configured a certain way, it's because you coded it that way. The difference is night and day.
Autoformatting/pretty-printing isn't a first-class feature and I haven't ever gotten it to work as well as Prettier works on the front end.
Occasionally you get fatal errors with no debugging information other than a hex dump (no, not even a stacktrace), and figuring them out can take days. I've never seen errors this opaque in any other runtime.
Visual Studio is much better than any other IDE for writing C#, but it's slow as hell even on a top-of-the-line development machine.

Ben Halpern • Mar 5

I'll start with Ruby

The Good Parts

Simple, flexible syntax to dive right in and make changes
Tremendous scripting language, really easy to whip up a file to execute a behavior
Mature ecosystem
Language creator still involved and enthusiastic
Generally supportive community
Robust library
Ruby on Rails is still going strong and a great framework if you like established conventions with flexibility to diverge as you need

The Bad Parts

Pretty slow
Eats up lots of memory
Iffy support for concurrency/parallelism
You might hate writing in it if you're used to more rigid syntax or don't like "magic"
Isn't getting new innovative tooling at the same pace as "hotter" languages
Not really the language of choice in any newer wave

Nikola Stojaković • Mar 6 • Edited

Rust

The good

Borrow checker that ensures you won't shoot yourself in the leg like you can with C and C++.
Powerful type system which is much more powerful than what other static typed programming languages can offer (except few exceptions like Haskell). I would quote No Boilerplate's amazing explanation on this - It's not C++, but better. It's Haskell standing on LISP's shoulders, hiding in C's coat to sneak into production.
Everything is immutable by default.
There is no null.
There are no exceptions - every function that can fail returns Result<T, E> and ? operator allows you to easily propagate errors (so you get best of the both worlds). Edit: there is a panic! which is similar to exceptions in it's behavior but it's used for non-recoverable errors only (see my comment below)
Hands down the best official documentation I've ever seen - the book, rustlings (small interactive exercises allowing you to learn how to write idiomatic Rust) and the reference is everything you need to become proficient pretty quick.
rust-analyzer is pretty great and gives you the experience of an IDE in VS Code and other code editors.

The bad

Compile time. Because of the various checks that need to be done, every crate (library in the Rust world) needs to be compiled.
Output size. This could be improved by optimizing release profile.
Because of the borrow checker, it's much harder to do some things which are quite easy in other languages (recursive data structures are one of the most notorious examples).
Because of the guarantees borrow checker gives us, asynchronous programming in Rust is much more complicated than in other languages.
It can become very verbose very fast. Check this example which shows how to set up tracing in an Axum web app.

Isaac Lyman • Mar 6

I'm a bit of a Rust newbie, but some of the "good" things seem like semantics. Maybe you can correct my thinking here?

There are no exceptions

The compiler throws a ton of exceptions, Rust is famous for it. And there's panic!, which in my experience is more common than advertised.

There is no null

But there is None, which doesn't seem that different to me. Is there a difference in the way you handle a nullable value in another language (say int?) and the way you handle optional values in Rust (like Option<isize>)?

I agree with your other points. Rust is my favorite language for performance-sensitive scripts, and I'm always happy to see things being rewritten in it.

Nikola Stojaković • Mar 6 • Edited

What I wanted to say is that there are no exceptions in the same sense there are in other languages (like Java, C++ or C# for example). panic! exists but is used for non-recoverable errors (and while technically it is possible to catch a panic with catch_unwind it's not guaranteed you'll be able to do it). Basically, try / catch mechanism has been replaced by introducing error handling by Result.

Returning Result allows you to have information about functions that could fail ingrained into the type system, forcing you to act on it. But I understand that this could lead to confusion for beginners so I'll edit my comment.

None and null are not the same thing. Option<T> type is in fact an enum which could only be Some<T> or None, therefore everything that could be done with other enums could be done with Option<T> - you can match on it and there are several built-in functions like and_then or unwrap_or for more granular control.

null on the other hand basically means null pointer or a pointer that does not point to any valid object. While modern languages like Kotlin do introduce optional types, they won't prevent you from having uninitialized variables, because you need to use String? instead of String to ensure you don't end up having null. In Rust, this is prevented by ensuring every variable must be initialized before it's used. Whether you have an Optional<i32> or i32, you need to initialize it first.

So, while they may seem as the same thing, null and None are not the same.

Keep in mind that things I wrote are focused on the safe Rust. Unsafe Rust, on the other hand, is a different beast and topic for itself; there is for example std::men::MaybeUninit for wrapping possibly uninitialized instances.

Ryan Brown • Mar 5

I don't know if I have a favourite programming language... For sure I have ones I use more often than others and some that are my go-to for specific project types or even just the hacky-get-something-processed-quick-and-throw-away-to-the-misc-folder projects.
That being said... I will pick the top one I do the most work in these days: The Dread-Language: JavaScript!

Good Bits (not the book)

It's the closest thing to a Run-Anywhere language I think we have now... Browsers, Servers, Apps, Phones, In-Line processing... it is in so many places.
It's a living language. JS & ECMA Script is actively getting new features, standards and generally keeping up.
Low barrier to entry. (nearly) Everyone has a runtime in the form a browser on their system to get started learning the basics.
High ceiling of capability: People and Orgs are doing a TON of stuff with JS. Major platforms utilize it to great effect as well as utilities and smaller apps & tools.
Large Community to support and contribute knowledge and libraries.
Execution sandbox should result in a higher level of safety than most compiled languages.
Duck-Typing helps to make a very flexible language where some very neat things can happen.

Not to very good parts

Some legacy parts of the language are just not correct for a modern language. I won't link to the details as I'm sure there are innumerable listicles identifying the peculiarities of JS.
Competing engine and execution implementations may not be compatible enough depending on what you're trying to do.
Strongly tied to consumer-hostile vendors such as Apple and Google who influence their browser's implementation. As behemoths in the market, they are like the tail that wages the dog. This may lead to wider splintering of capacities and features.
Speed... as an interpreted language (or JIT compiled in modern engines) it is not quite as close to the metal as a fully compiled language wold be, and thus imparting a speed penalty.
Confusion around core concepts like the this reference, how var differs from let not only in allowing redefinition, but in hoisting behaviour.
node_modules potential for explosive size on even medium projects. (not really a problem of the language but of that the mechanics of that specific ecosystem)
The type system plays at being duck-typed, but... there are, as always, some weird exceptions. Mostly these exist under the hood in the various engines and could end up with some hidden effects in the form of speed penalties or possibly even unexpected results.
Seen as a bad language, no matter what fixes will be enacted.

Often I jump to JS to do some quick processing of lists or data or try out an algorithm, or some meta-programming task.
Is it a favourite? Not really, there are a ton of flaws and reasons to choose something else. But it is handy, its there and it's good enough for most of the stuff I use it for.

Isaac Lyman • Mar 5

Great summary.

Backwards compatibility has got to be the best and worst thing about JavaScript (and the web in general). On the one hand, if your website worked in 2008, it will probably always work, with minor exceptions for non-core technologies like Flash and ActiveX. On the other hand, our grandkids will probably still be seeing "use strict"; and wondering why NaN !== NaN.

When you spend time working with any other platform, you come to appreciate "don't break the web." But then you come back to JavaScript and start to wish we could break just one or two old websites by getting rid of things like "null and undefined both exist and don't mean the same thing" or "0 is falsy, so you can't null-guard a number using !".

Kaamkiya • Mar 6

The Good

Simplicity
Backed by Google
Very type-safe
Fantastic concurrency support
Has a built in formatter and linter (go fmt or gofmt)
Huge community

The bad

Over simplicity
Backed by Google
Not the easiest language to start with
It's simplicity can make it complex

Dung Tran • Mar 11

why backed by Google are both Good & bad?

Kaamkiya • Mar 18

Depends on your perspective. It helped with giving Go a huge community (pro), but there are plenty of people trying to "DeGoogle", which means for them, it's a con.

mahdi1297 • Mar 21

You Know, google has many failed or forgotten projects.

Shai Almog • Mar 5

I wrote this about Java. I think a lot of people write bad stuff about Java so it's important to highlight some of the good stuff.

Cesar Aguirre • Mar 5

Good parts: LINQ and async support. Love it
Bad parts: Many alternatives for the same task :/ For example,

AnObject anObject = new AnObject()
var anObject = new AnObject();
AnObject anObject = new();

raselldev • Mar 11

Microsoft Stack (VB.NET, C#)

Pro:

Easy if you love microsoft ecosystem(windows, azure, sql server)
IIS is easy
VB.Net liked by many boomers

Cons:

Migrate from .NET framework to .NET core is painfull
Cross platform mobile not ready for production

eerk • Mar 11 • Edited

Of course it's javascript, what else could it be?

PROS

Works everywhere.
frontend, backend, microcontrollers, server, client, machine learning, AI, everything man...!
All code is correct. Granted it will give you some errors here and there, but hey you can just offload those to your end user.
no compiling!
no installing a huge tool chain with dependencies all over your system, that still only work on your own machine and nowhere else.
IDE editors are crazy fast (except webstorm).
Exceptional at programming user interaction. No other language has so much out-of-the-box support for building and responding to user interfaces.

CONS

All code is correct. Granted it will give you some errors here and there, but hey you can just offload those to your end user.

Adolfo Neto • Mar 6

Worst thing: there are not many jobs for juniors. The language: Elixir.