I don’t think anyone has mentioned it yet, but how about Deno with TypeScript? After I saw @dillonkearns talking about the type system in his videos about elm-ts-interopt, it made me much more interested in using TypeScript. I have no practical experience with either Deno or TypeScript, but I’m seriously considering it for my next application.
Hello, adding my emphasis here
These two things seem pretty contradictory to me. Of course they’re not really, what you’re saying is (IIUC) “Rust screams at me too much” and “Go doesn’t scream at me enough”. I personally find Hindley-Milner based languages a pretty good sweet-spot of complaining about enough things whilst also allowing most of what I’d actually wish to write. If you conclude that you’re of a similar vein then that at least narrows your search down to those style of languages. Alternatively, since your preferences for what you want the “language” to “scream at you about” are perhaps quite narrow, you might consider less strict languages that comes with a good linter.
But error check in Rust is often just ?
And you can use unwrap to “not check” the error.
ps. I’m loving Rust and it will likely be my only language in the future for everything except frontend.
Good thoughts – no, I think your description of Go is likely pretty good. I’ve not used SQL recently, and my APIs are fairly small – I tend to re-use simple data types a lot and try to keep API and storage DB schema simple. For distributed systems, this becomes important so that it is possible to efficiently synchronize data between systems.
Concurrency is also very important in the problems I solve and Go does that pretty well.
For web apps, I use the SPA architecture, so I don’t really need a “web framework” on the backend – just an API.
When deploying an app to a lot of systems, the efficiency of Go (small runtime, embedded dependencies) helps a lot. Again, sounds like a different problem than you have.
Comments about Rust are interesting – definitely something I will look at in the future.
Scream was probably a bad term 
What I mean that if you don’t check your error, you’ll definitely hear about it, soon than later (which is a good thing!).
In short, I like the idea of forcing the programmer to deal with his inconsistencies.
I have to play more with rust to form a proper opinion tbh, but I’d say that if you do that, then you do this knowingly which is a big difference from blissfully ignoring an error waiting to happen and carrying on.
I say it’s fine to ignore an error if you judged the likelihood of it happening is basically zero from a practical point of view.
Yes, Rust forces you to be explicit when ignoring errors, blissfully ignoring an error is not an option.
So I guess I’m confused, if you find it a good thing to know about omitting to check your error, why did that then make you “even less interested in the language”?
Anyway I do not wish to derail the topic in semantics.
I haven’t used Deno for for anything large or at work but I’ve used it a lot in my spare time and combined with Elm. Most of the current server frameworks for it are based off of Express, with Oak probably being the most popular. I do enjoy working with Deno more than Node, however I wouldn’t say that JS backends are my favorite. For me, TypeScript is still not a pleasure to use all of the time. It can be nice in small chunks here or there though.
2 Likes
I’m pretty sure he meant “Go” as “the language”
No worries, I enjoy the conversation 
That’s right
The golang designers took the KISS approach of just returning errors from functions. As the consumer, you have to check and decide what to do with the error.
But this design has some drawbacks. On this line, I iterate over returned rows via rows.Next() (thats stdlib stuff). And even tough I check for errors inside the loop, I still have to check for other errors with err = rows.Err() because other stuff could be happening under the hood to which I don’t have access to (say a network error).
It’s not obvious, easy to forget, especially if working with a new library.
Same goes for defer rows.Close(), you have to remember to issue this method call, otherwise the connection may not return to a connection pool properly.
Funny fact, I made a mistake, by not handling the error returned by rows.Close(). That’s translatable to a potential production bug. Ideally, the compiler would have complained.
Another downside to this approach is that you don’t get errors pointing to file and line numbers. There are workarounds but in practice you grep for error messages to find broken code.
So that’s the bad side of golang for me, but despite my criticism I still think it’s a great language though
To add a few more experiences to the pile!
I’ve been working on a Kotlin / Spring Boot backend project at work and Kotlin has been surprisingly nice - there are aspects of its design I find similar to Elm. It’s not a massive language (like Scala or Haskell) but gives you a few simple but expressive language features (sealed classes, data classes and extension functions are my favs!). If Spring isn’t your style, http4k (https://www.http4k.org/) is a great functional alternative.
I recently tried Purescript on a personal project, it was also very pleasant. I found it superficially similar to Elm but closer to a more cohesive Haskell. Because it compiles to JS it can be a nice fit for environments like AWS lambda. The JS interop is a lot more powerful than Elm ports but you have to be very responsible how you use it (unless you’re absolutely sure about the types of your JS functions you can see some very strange and unpleasant errors). I used this GitHub - hoodunit/purescript-payload: An HTTP server and client library for PureScript as a web layer and it was pretty impressive - API as a type and can auto generate a http client from it.
Will echo some similar thoughts above on Typescript, it’s nice in small doses but in larger projects I really missed the strictness of something like Elm + the JS ecosystem is a wild wild place!
+++ on Hasura as well, if you’ve got a CRUD heavy app it cuts down a ridiculous amount of work, and scales really nicely when you need to add more detailed logic. It’s also insanely fast, this has a Hasura backend on a free heroku dyno https://realworld-hasura.vercel.app/
2 Likes
Thanks, looks like a great suggestion!
It’s on my radar. It seems doable to build an API server with it, but not sure if it’s practical (or a good idea).
Yeah I gathered that
That’s very good feedback thanks
Sweet, looks appealing, I’ll look into it 
I understood Hasura has caching is built in, so maybe that’s cheating 
I haven’t looked into GraphQL yet. The proposition doesn’t fit my use case at all (I access and code everything). Also I understood that lack of flexibility may be a downside to GraphQL. But mainly I find properly using SQL technology hard enough to think twice about introducing an abstraction on top of it.
I’ll have to look into though.
Side note: I played with PostgREST a while ago which adresses similar concerns to GraphQL. My conclusion from playing with it was that it’s just better to properly design an API, otherwise you just shift complexity to the frontend. And I just learned from a friend yesterday that you can’t query over a joined table! I looked into it and indeed, that’s a limitation for which you have to workaround. So all that to say that I probably prefer staying in the driver seat to manage the complexity here rather than delegate it 
I use Supabase, and they use Postgrest. I can query over joins. So it’s either solved by Supabase or by Postgrest already. Supabase actually employs the dev behind that Haskell project.
2 Likes
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.