I always suggest Go. If this is a project that will be “complete” soon, then you have good chances to release your code after years, compiled with newer versions of Go, without the need to rewrite it. (If you used standard library packages.)

Unfortunately, writing CRUD in Go can be tedious because there are no generics, but this is fine. Later, when you realize that your abstractions where wrong, you will thank Go for the lack of generics anyway.

I don’t want to sell you on my favorite language, but on my favorite method.

Do you want this thing to just work? Choose a boring tool.

Do you want to spend the least amount of time? Choose something you’re familiar with (unless it’s ill-suiter for the task).

Want to learn a new language/framework and have more time to complete it? Choose something you want to learn that doesn’t seem to be outdated in a year, or you’ll keep rewriting it again in 2 years.

What I would choose right now? I’m learning Erlang atm, so I’d try to get this done with Cowboy. If not, Python is a solid choice, but so are PHP or Go.

I’m a fan of Rust, and I think it’s a reasonable choice for a personal project language. It’s more or less as suited for writing a CRUD webapp as any of the dozen or so popular general-purpose programming languages in widespread use. It’s an increasingly popular industry language, so knowing how to write code in it has a good chance of improving your marketability as a professional programmer. The language semantics and tooling do a lot of innovative things that many other mainstream programming languages don’t in my opinion (ML style types, memory safety in a GC-less context, cargo and related build tooling).

I might also suggest writing it in Haskell, if you’ve never touched Haskell or a similar functional programming language before. It’s a genuinely different way of thinking about programming from more mainstream languages.

Give Ada a shot. It’s used in high-reliability contexts, is ISO-standardized, has been in development since the 70’s and constantly updated and has had a pointer ownership model long before Rust came and claimed to have invented it. Admittedly, it’s not as “cool” and your code looks “boring”, but is very well-readable. The type system is also very strong (you could, for instance, define a type that can only hold primes or a tuple type that can only contain non-equal tuples) and even though Ada is OOP, which I generally dislike, they’re doing it right.

Additional bonuses are a really strong static analyzer (GNAT prove, which allows you to statically (!) verify there are no data-races or exceptions in a given code based on the Ada Spark subset) and parallelism and concurrency built into the language (not some crate that changes every week).

Many claim that Ada was dead, but it’s actually alive and kicking. Many people are using it but are just not that vocal about it and just get work done. As we can already see in this thread alone, the Rust-evangelists love to spread their message, but if you ask me, Rust is doomed due to it’s non-standardization.

You wouldn’t build your house on quicksand (Rust), but bedrock (Ada).

You could do a lot worse than trying Lua via OpenResty. It uses the lua-nginx-module to bridge nginx and the LuaJIT, giving you a slick package incorporating a powerful, fast web server and language runtime environment with tons of package-managed quality libraries, including some solid web frameworks. It’s basically nginx’s guts exposed neatly in a well-organised async Lua API, so you’re effectively scripting the entire non-blocking web mechanism using a clean, simple language that lets you layer pretty much anything you want on top, from a straightforward web app to per-request load-balancing decisions and scriptable TCP socket servers. Pretty amazing.

If you want to something really new, I will try Janet programming language https://janet-lang.org/.

The language and ecosystem are very young, but you mentioned parsing text for which Janet has powerful tools in the language’s core: the PEG.

Feel free to contact me if you need further advice. I am a co-maintainer of the packages registry for the language to help you choose the right tools.

Haskell.

There are some things it’s extremely good at, but I think it’s worth learning because it’s a very different way of thinking about code than you’re likely used to. The lessons learned will travel with you to other languages.

Most notably, after learning Haskell, I find it maddening that other languages don’t have any notion of enforcing purity outside perhaps variable mutation. It encourages code that’s readable, testable, and composable, and speaking of readability it allows you to take mental shortcuts that mightn’t be obvious if you’ve never worked with this style of code.

Likewise function composition allows you to take some mental shortcuts; when practicing type-driven development, I can picture the data transforming from a to b on either side of the composed function without thinking about what’s going on in there internally. This, alongside the tendency to encode the unhappy path in the type system, is I think what gives many Haskellers that feeling of “if it compiles, it’ll probably work”.

You should give a serious thought to Common Lisp. It’s still an unmatched platform. It offers:

• a stable language and ecosystem (even though they keep improving). Seriously, something written 20 years ago still runs.
• compile-time type checking with instant feedback (you compile your code function per function as you develop) (the type checking is not as thorough as true ML-like languages, but it catches way more things than Python, which doesn’t catch any, or needs a third-party module and more work),
• image-based development: the REPL is the most interactive you will encounter (similar to Smalltalk maybe) (this could be a cons: you must find your way in this workflow). There feedback loop is very short. Write a function and test it instantly in the REPL. Then if you want build a command line interface. Don’t wait for compile times.
• part of the image-based development is the interactive debugger (when it pops up, you can fix a function and resume the execution from anywhere in the stack),
• ability to build and ship self-contained executables (static executables are on the way) (compared to Python again, this is pure joy),
• it may have more libraries than you think:https://github.com/CodyReichert/awesome-cl (no problem finding tools to parse text, interact with a DB, returning JSON and building a CRUD web app (I did it)). You would not be the only one coming from Python, so there are some libraries inspired by it. See also py4cl if you really need to run Python code.

Here’s my comparision of the workflow and ecosystem with Python: https://lisp-journey.gitlab.io/pythonvslisp/

and a State of CL 2020: https://lisp-journey.gitlab.io/blog/state-of-the-common-lisp-ecosystem-2020/ (with nice comments on HN, see link in comments)

I hope the Cookbook is useful: https://lispcookbook.github.io/cl-cookbook/ It greatly improved in the last years, hopefully answering many newcomers’ concerns.

PS: CL is not tied to Emacs any more. Find good plugins for Atom (SLIMA), VSCode, vim, Sublime…

If your language doesn’t have a rationale page, then they should get around to adding it so you don’t have to rely on people posting comments about it on some random site! Here’s the one I wrote for Fennel: https://fennel-lang.org

for CRUD, I highly recommend Elixir.

• good first class tooling to “do the right thing”
  • beautiful docs
  • clean project-specific dependencies
  • amazing testing framework (lets you trivially do concurrent testing against the the database, for example)
  • most things are immutable since it’s an FP; you have escape hatches to statefulness that aren’t cognitively burdensome like some other FPs out there.
• being lazy is ok.
  • if you have a miscode, you don’t need to try/catch it
  • most resources will be cleaned up for you (e.g. sockets, files) you don’t need to .close() unless you NEED to for performance tuning.
  • it’s easy to shell into the vm (even in prod, if you need to) and debug code interactively.
• features
  • concurrency support, but for a CRUD app you’re typically not writing concurrent code, your code gets called by the framework concurrently (no red/blue functions).
  • database access is not an ORM, but it is a very opinionated query-builder
  • language is “unofficially complete”, no major new features planned, most future changes are going to be incremental improvements and QOL improvements in the stdlib.
• non-features
  • elixir is slow. Probably faster than python, but not as fast as Java, or C#, though things are getting better since it’s getting jitted.
  • if you absolutely can’t stand the fact that lists are actually lists and many searches are O(n) then it’s not for you (but how long are your lists, really?)

Here’s a pitch I wrote for Clojure. One major advantage with Clojure in web dev space is that it runs both on the server and the client. Here’s comparison of different front-end frameworks for a real-world app, and Clojure does consistently well in terms of bundle size, speed, and conciseness.

Clojure is a delight to use, and immensely practical as a language to work with as well. Clojure is stable, has stable library support, can access the full enterprise legacy of the JVM, and can be made to run damn nearly everywhere without too much effort.

It’s hard to oversell this last point.

It’s not only possible (but surprisingly easy, and I’ve done it!) to write a single application that can run:

• On a mobile phone
• In a browser on the client
• In a browser on the host
• On a server
• As an app on Windows
• As an app on Linux
• As an app on OSX
• As a tool in the shell
• As a notebook (this is the preferred method used by most Clojure devs… believe it or not)
• etc. etc.

It can accomplish this feat since it can target JavaScript Runtimes and the JVM, which was yesterdays “Big fat VM binary”, but has a really tiny footprint compared to other technologies with such broad deploy bases.

I think if you try it, you’ll find that you’ll begin to reach for it for everything and be better off for it. The only major criticism that I’ve seen leveled against the language is that libraries are rarely updated, but I can speak from experience it’s because they’re really damn good and there is little or nothing to change or improve.

Also in terms of fun languages and building up your CV, Clojure is a Lisp dialect, and Lisp is a superpower.

You should learn a new language only if it learns you something along the way. Some language can be put in a “bag” of similar patterns:

• Python/Javascript/Ruby/PHP/Perl; common scripting language spirit
• C/C++/Java/Go; compiled in spirit, feel “not modern” quite low level
• Clojure; has my preference to have fun while learning new concepts along the way, should make you quite productive
• Haskell; if you prefer never finish your work but learn a lot of things along the way trying and feel good about yourself because you mastered the beast (partially)
• Rust; if you still like to learn a low level imperative languages but with a lot better compiler that checks common mistakes for you so your CRUD API will probably be a lot faster and use a lot less resources than using Python

Hm, so, as someone who literally did language evangelism for quite a while now (Ruby and Rust for over a decade): I’d stick with python and maybe use something current like modern Django or one of the smaller frameworks. If you really want some fresh air, maybe switch to a language close to it, like Ruby or even PHP (with all its bad rep, there’s a reason PHP is still the dominant language).

Given that you don’t want to maintain the old code, trying out a new ecosystem on your know problem will almost surely yield the next code base that you don’t want to continue to maintain - especially if the ecosystem is far out.

Also, given that it sounds like the app has a web part, I’d avoid all things Rust. Not because I don’t like it, but there’s not stable web frameworks and their general security/templating stack is very diverging/incomplete (e.g. things like safe cookie handling, CSRF, XSS, and such). So you either forgo the whole problem or you have a lot of things to investigate. APIs, I’m less hesitant, but for the rest, the story is still very spotty.

That all being said, taking slices from your problem and reimplementing it in languages you want to try is a very useful method of learning, but I’d prepare myself for throwing the code away. Detaching learning from necessary success also makes the thing far more relaxing.

Give asp.net core a try with C#. Good en framework, good ORM, good db support and all the goodies. Works well with VS code.

Give Janet a try. It has an amazing built-in PEG module, which is a breeze to use. There are SQLite bindings and an SQL library that supports SQLite and Postgres. There’s also a web framework and a more Sinatra-inspired web framework.

Apart from library support, the documentation is very good, the Core API is full of useful functions for list comprehension and the like, and it has a very comfortable REPL. I’d say you’d finish at least a prototype of it very quickly in Janet.

AS of 2021 if you are interested in a production ready, widely used and supported language that can run on-prem and in the cloud with ease I would recommend F#.

It is almost comical how easy is to get productive in F# even is you have no idea about functional programming just want to write for loops and return nulls. Once you understand that map / reduce style functions are nicer and Option is a better (safer anyways) way of dealing with missing values you are going to have a better time. If you also start to grasp that AND / OR relationships are easily expressed with a type system that F# (and Haskell and other ML languages) have you realize that you can implement poker purely in types and with very few functions in a self explanatory way. (https://fsharpforfunandprofit.com/series/designing-with-types/).

Later on you can wonder into railway oriented programming and get rid of visible branches in your code.

All of these are optional, you can use F# on the level that you are most comfortable with. This is why F# is a beginner friendly language as opposed to Rust.

Purescript is a great sort of mind-altering experience, if you have the patience for it during the learning phases.

You get the base goodies of an ML-based language, but you get a couple extremely important details that completely change the name of the game:

• strict evaluation by default. I don’t actually like this but it does mean you don’t have to read a bunch of “Haskell lazy evaluation” discussions all over the place. It does what is written.

• Built-in dictionaries (as records). You don’t have to go building a bunch of data types by hands, you can just write out a JSON-looking structure and use that to hold your data. Type infrerence “just works”.

• Row effects! You can just say “take these two objects and merge them” and you just get what you want. You can have your lightweight object declarations and your type checks.

• No more “OK this is pure or this can do any IO whatsover” type signatures. You can label your methods for extremely specific variants of IO. My favorite version of this is labelling a function as being “read-only”: you can read data from the DB, but no writing! Extremely valuable in my opinion and I think we’ve only scratched the surface here.

• Relatively painless FFI, so you can always just cheat if you need to.

If your project is mostly CRUD, you don’t need a server side component other than your database.

Just put postgrest in front of your database and proceed to impleme te the UI with whatever you would need to use anyway. https://postgrest.org/en/v7.0.0/

You might need to write some PL/pgSQL, but this will be an order of magnitude or two less code than you would need otherwise. The reason being that you can work directly with references to the database. Instead of a whole lot of silly piping.

I think you should try Rust. No good reason aside from having your own point of view on a programming language that supposedly solves the pointer/memory error issue of programming without GC.

I would advise that you stick with Python and modernize your code and practices. For example, you can use static types to your python code or if there’s a part of the code base that is number-crunching, you can try to implement it in Rust or something else and use FFI, …

Python is a really decent choice and don’t chase the new shiny things just because you can! Many people are still using Python and get things done!

I still use C. Don’t use C; at least not for web development. I like Node.js for web stuff.

Express.js is my tool for everything Nginx can’t do on its own (except gitweb, which is a Perl CGI script). Most of my pages are static, but templating with EJS is easier than slapping PHP onto HTML. Wrapping one’s head around the different ways to do things can be frustrating, especially with many libraries providing promises, asynchronous callbacks, or standard synchronous APIs. I still don’t know how to use promises, and haven’t found a good reason to with how tiny my apps are. It’s also really nice to have everything including your config, messages, server code, and client code in the same langauge.

If you want to use C, Kore.io’s documentation is underwhelming at best and misleading at worst. BHCS seems cool, and parsing JSON with jsmn is very easy. Alas, footguns aplenty and I just crawled back to Node for anything web-facing.

For a database, I either roll my own simple thing using the filesystem, or pick between PostgreSQL and SQLite. SQLite is easier to set-up and is infinitely more portable. You can just up with your files and walk with the database in your pocket instead of having to fiddle with system services and actually configuring your database, which means less shit to fuss with on my desktop. With the hobbyist volume I work with, SQLite is more than enough.

Python seems like a fair candidate, but I’ve never used Flask or Django or anything, just gave WSGI half a shot back several years ago. Same with Perl. PHP is really the only other web langauge I’ve used as extensively as Node. I’ve heard it’s gotten better. If you really want to shoot yourself in the foot, give it a shot in Bash!

I probably don’t have all the information I need to make a recommendation for you specifically. I can only tell you what options I’d be looking at. I’m going to surprise myself a little by suggesting TypeScript. Like a lot of JS devs, I’ve already started writing TypeScript for my day job. There are at least three other languages I’d reach for first that I consider more fun to write. But two of them have already been mentioned (Haskell and Elixir) and the third (Elm) doesn’t have a back-end runtime (unless you count Lamdera, which is still in alpha), so it doesn’t sound like a great fit for your project, especially you end up writing all the guts in Python and your use of Elm is limited to an upload form. Instead, I’m going to make the case for TypeScript on behalf of a company that doesn’t want or need my evangelism. Here’s my reasoning:

1. Strongly typed functional languages are well suited to writing parsers. For all its warts (many of which were inherited from JavaScript) TypeScript is one such language. I’d take a look at parser-ts if you’re interested in exploring FP in depth or ts-parsec if you’d prefer something more mainstream.
2. You can import existing mainstream JavaScript libraries into a TypeScript project and with type definitions too, thanks to the rapid proliferation of type definitions both inside those projects and outside via DefinitelyTyped.
3. You could use your parser on the front-end, the back-end, or both. (The same could admittedly said about Rust by compiling to wasm.) This isn’t terribly exciting for a hobby project but I’ve encountered inline validation as a design requirement enough times in my day job to want to practice sharing this kind of code on both sides of the wire.
4. Deno is shaping up to be a very promising back-end runtime for TypeScript. Like Python, Deno’s magic performance sauce is its bindings to code written in a compiled language. Even if it turns out Deno is missing something you need, it’s still possible to use ts-node to run an Express server.
5. In spite of its initial appearance as a C# straitjacket over JS, TypeScript opens up some interesting possibilities you can opt into at your own pace and comfort.

If the user interactions are simple enough, you can probably write the front-end without a framework. I’d still want to keep my front-end source pretty modular and the output minified. I’d use something like esbuild for that.

you haven’t said enough about what your goals are to answer this question in a way that can really go beyond being a popularity contest for various languages. Most language can parse text, interact with a database, and serve a JSON API these days, so those requirements aren’t really a lot to run with. What should it run on? How many users? How does the data get there? What does the save state look like? Is parsing the save state data a difficult parsing problem? Do you have to reverse the format or do you already know it? Should other people be able to run the server? Will you want people to log in? Are you trying to learn a skill that you can get paid to use? Are you trying to expand your brain?

Anyway use Go I guess.

I don’t have a favorite language/framework/library for this kind of project. It’s more about how easy it’ll be to host it somewhere that won’t cost me anything or very little. In this case, it seems like it won’t be a massive amount of visitors (older video game) and a database could be anything but let’s say SQLite. With these requirements, if you go with Go, you still need to find somewhere to run your binary. With Python, you’ll find some cheap hosting like OVH, same with PHP. Always keep it as simple as possible to get your base project working and then improve on it once you’ve learned more. You could even use glitch.com and use a file based DB.

• How much time do you want to devote on this? This will tell you whether you want to make in a language you know, or a new one.
• Do you want to learn a new language? Why?
• Will this give you a marketable skill? If so which language is closest to what job you’re in?
• Do you really care if it is going to be a marketable skill, or do you want only personal hobbyist happiness?

I’m not an evangelist for any language, but I’d suggest Go, Elixir or Clojure.

Why not play a game? Pick some outward-facing feature you’ve always wanted to code in a CRUD app. Perhaps you’ve always wanted to make a SPA, or use the .NET ASP stuff under linux. Maybe there’s a CASE engine for a database (or a database feature) that’s supposed to expose tables for simple CRUD.

There are a lot of different things you can show or play with in the end result. Pick something you’ve either wanted to do or would really like to know how it works. Once you’ve picked the end-result, choose the code/language/platform/framework that you think would be the best match for that thing. This way you’ve got a better question than simply “What’s cool?” and when you’re done you can evaluate your experience with what the boosters said.