- Frontend: Vue with TypeScript and Bulma or TailwindCSS
- Backend: Go (no framework) with monolith first approach with well defined internal logical interfaces that can be easily implemented as external services when they need to scale (session service, user service, notification service, slack integration service...)
- Storage: embedded BBoltDB or Badger, separate db for every logical service and PostgreSQL data structure is very very complex
- Services communication: Protobuf with GRPC
- Monitoring and alerting: Prometheus with Grafana
- Log aggregation: simple central rsyslog, indexing when really needed
- Editor/IDE: VS Code
As less operational maintenance is needed, the easier is to live with your creations.
YTBmp3 https://www.ytbmp3.com is built completely with Go. Autoscaling cloud instances based on load with a custom scaling solution is also written in Go. It handles very long running requests on streaming transcoding and compressing. Go's net/http is exposed to the internet with great results which adds to infrastructure simplifications, graceful reloading (important for long running requests). Go allows so much infrastructure simplifications that there is not even a single container involved. :)
I work in Go full time, so i don't know if that counts as without prejudice. But I do not think it is fun or particularly productive (if measured by the amount of stuff i can get done in a particular set of programming time). I'd say I haven't used a language I was less productive in or that I enjoyed less since Java 1.
What I think Go has done for me, is crystalize a belief I was already leaning towards, which is that a language being productive or fun is a lot less important than standards cutting through the issues that don't matter.
Not arguing about the best way to format code, or which test library to use, or how to share memory across threads is what makes Go valuable. It is implied that the language has to be this bad to achieve that, which is the open question to me.
With golang, it is incredibly easy to get productive fast. It's like modernized, safe C with good standard library and trivial deployment. Those are pretty good selling points for getting stuff actually done.
Using Haskell for similar stuff is more tedious, even if a actual coding is more fun. I can see (and sometimes feel myself) the cognitive dissonance here.
I think the issue here is that you're comparing Go to C and Haskell.
C is decades old. Haskell was designed to help you write correct programs, rather than simplicity of use or productivity (or that's how I'd characterise it).
If you compared Go to C# or Java 8 or Scala, it'd probably look a lot worse. Deployment isn't so difficult that Go has any advantage in my experience: install a JVM on the server, ensure your build system is producing a fat jar, run it. Done.
With Capsule you can even make self-executable JARs that have a little shell script attached. Then you can run the program like any other UNIX app. chmod +x and ./execute it. Fully self contained, and can even update itself automatically.
I use C# at work, and I use Go at home. I really do like C#, but there is a reason I am using Go at home. I find I am more productive, and can develop better code faster with Go even though I am very new with Go.
> Using Haskell for similar stuff is more tedious, even if a actual coding is more fun. I can see (and sometimes feel myself) the cognitive dissonance here.
I don't think the same could be said for say, Scala or F# which offer many of the same paradigms but in a more flexible way though.
The practical side of distributions is package management in every sense. From the point of package management software (dpkg, rpm, apt, yum), repository size (official packages supported), standards in maintenance of the packages, Debian is the winner. That means that your sysadmin work will be much pleasant, and enjoyable. Having to reinstall 100+ servers from CentOS 5 to CentOS 6 will be remembered as the lowest point in my work experience so far. I still regret not convincing my boss to migrate to Debian or Debian based distribution.
I do maintain both rpm and deb packages for the company that I work for, personal projects (only deb) and community. Working on Debian related projects is always nicer and enjoyable, at least for me.
Having worked with both, and been intimately involved in package/repository creation and maintenance, I would have to disagree completely.
I'm not sure how you were managing it, but I've installed very large bases if redhat systems, from dozens of individually configured systems to clusters of thousands of nodes. I would say that neither are too difficult for general deployment, but redhat's kickstart system had a leg up on Debian for years.
I'd also say that the yum/rpm repository system is far easier to manage. Setting up internal repos, and making custom packages takes so much less work in the redhat ecosystem, because the sets of tools are much better integrated. Setting up a custom signed apt repo takes a lot more work, and research into various sources of documentation. Don't even get me going on trying to sign and verify a deb on it's own.
This sounds more that your experience with Debian tools is much weaker then with RHEL based ones. The discussion on this is endless, both systems have advantages, I just prefer Debian from majority of reasons.
I was more or less responding to the focus of your comment being:
> "Having to reinstall 100+ servers from CentOS 5 to CentOS 6 will be remembered as the lowest point in my work experience so far."
I've worked with both very extensively, I just don't see this as the case at all if one is well prepared, and wanted to point out that RHEL systems aren't lacking in that respect. I have numerous ubuntu systems that are lined up for a 10.04 -> 12.04 upgrade, and I don't see it as being any more or less difficult than the RHEL 5 -> 6 transitions I've done, just different.
The difference is that reinstallation requires more work and it is more difficult then upgrades. What I wanted to say is that I would recommend everyone to try to avoid massive reinstallations between RHEL clones major versions, especially if you are supporting large number of services and fast development cycles,
The other big difference is in regards to upgrades - I've upgraded Debian servers in-place for years. Even in the announcement this post links to the upgrade instructions are "reinstall".
The differences in packaging systems, and similar are largely something you can learn about. But the idea of reinstalling to upgrade has always struck me as something I'd rather avoid.
I disagree with you. Making good free software improved GNU/Linux position (GCC, Linux kernel, Apache httpd, python and may other successful projects) instead just providing what vendor is shipping binary (drivers for graphic cards, Sun-Java...) All good free software projects would not exist if we ignore them and use proprietary software instead, and community could not have impact on features that are important.
And you can never ignore the possibility of the proprietary software vendor deciding to make your life hard. With free software it's you, not them, who are in control.
- Backend: Go (no framework) with monolith first approach with well defined internal logical interfaces that can be easily implemented as external services when they need to scale (session service, user service, notification service, slack integration service...)
- Storage: embedded BBoltDB or Badger, separate db for every logical service and PostgreSQL data structure is very very complex
- Services communication: Protobuf with GRPC
- Monitoring and alerting: Prometheus with Grafana
- Log aggregation: simple central rsyslog, indexing when really needed
- Editor/IDE: VS Code
As less operational maintenance is needed, the easier is to live with your creations.
Example: https://newreleases.io