Get the top HN stories in your inbox every day.
faangguyindia
whstl
I am in a similar place.
Especially regarding Bash.
Used to be in a few companies where most developers just couldn’t/wouldn’t write in more than one language and it was always a pain to maintain different runtimes, languages, packages and internal dependencies of things that could have been a 20-line bash script, and had to be maintained and updated from time to time.
I understand people have their own limitations and reasons, but having to constantly deal with “wrong tool for the job” for the thousandth time gets frustrating.
Especially in cases where four different languages were used across the company because different people had different preferences. Worst case was Python/Ruby/C#/Javascript.
I get that Bash is not perfect, but I enjoy the simplicity and directness, and dislike the multitude of problems caused by not using it have shown to me it’s a better tradeoff.
raddan
Funny, I have also converged on shell scripts for simple scripting or configuration, but I use /bin/sh for portability. Many of the machines I use do not even have bash installed.
orwin
When i talk about my "bash" scripts, i mean sh. I assume this is the same forgp (tbh, i tend to use AWK over bash in 80% of cases, but i call it from bash anyway, and still call it bash scripting :/)
gf000
Well, Java would compile and work for 3 decades straight. If anything, go did have an actual breaking language change (for loop variable capture)
kibwen
Note that Java makes breaking changes all the time, which is why it publishes a compatibility guide with each major release. These are usually judged to be minor breakages, but if you have a codebase on the order of millions of lines, there's a very good chance that at least one thing will break and require a little bit of work to upgrade. And Java's not unique here, every stable language makes changes all the time that have the potential to break some user in some edge case.
gf000
Sure, though most of the time it's library-only, not language change (with the only exception I have in mind is new keywords, but those are pretty rare with java).
All in all, Java is pretty unique in the level of backwards compatibility it provides, I don't think any other language is comparable to this level. Especially that it is both source and binary compatibility.
pdpi
Not that I need to tell you of all people, but I do find that Rust's editions system is one of the better ways to minimise this issue.
quectophoton
> 1. Go, when I first saw code I wrote almost a decade ago still compiles and runs in Go, I decided to use Go for everything. There were some initial troubles when I started using it a decade ago, but now it's painless.
And fewer dependencies, and fewer vulnerabilities (if any at all, depending on your few dependencies).
Go is "only" a pain when you want to use your own copy of packages (because `replace` directives are always ignored everywhere except on the "root" package), and whenever you want to work with private Git repositories outside of the forges that have hardcoded config in the Go code (like GitHub) (because Go assumes there's an HTTPS server, and the only way to force it to use only SSH is with ugly workarounds AFAIK).
But despite this I still prefer it for personal projects because I can come back after not touching it for years, and the most I need to do is maybe update `golang.org/x/net` or something like that.
Sleaker
I'm in the same boat, I started using go only a year ago, but don't want to really use anything else now for apps or data processing. I wrote an app that loaded a lot of data for reporting into duckdb. I've been doing so much java and JavaScript that I feel like it was just much simpler to deal with overall.
Shell for the scripts. I haven't tried to work through much DSL as I really am not a fan of DSLs. Maybe I'll give haskell a shot again to see if it sticks.
dominicrose
IME Ruby is really good for working alone on tiny projects without an IDE (trying to get more than syntax highlighting causes problems). Sometimes I write single-file scripts or even just use interactive Ruby.
case_ratchet
Ruby remains a joy for small things. I also tend to use it in place of Bash when I can.
raincole
The funny thing is how ubiquitous TypeScript/JavaScript is. There is no escape. I also only use four languages: C#, F# (for DSL), Powershell (for deployment) and... TypeScript.
Despite we have different tastes in language and are in completely different ecosystems, TypeScript is still the lingua franca lol.
zelphirkalt
Whether there is any escape from JS/TS is a matter of what you are building and who is around you. If you are building SPAs all day, then sure, you will probably have to deal with the JS/TS ecosystem. If you are just building websites, then basically any traditional web framework would do. Only that then it depends on whether you have to work with people, who don't know web basics or people who want to use JS web frameworks even when there is no need, in majority, so that you get no choice, but to work as a team.
In theory most websites could be done statically with rendered HTML and CSS and maybe a little bit JS, but not mandatory, and having noscript fallback flows. MPAs are fine for most things and having noscript fallback flows can also be done kind of systematically, and in many cases isn't that difficult. Just that these days not many people bother or care.
ramon156
Would love to use go for SaaS but things like OmniAuth (RoR) make me stay with Ruby. I actually never used ruby before, but I think its a swell language to do SaaS in.
KingOfCoders
Im with you on Go and SQLite, dropped Postgres for many of my projects, I might add: HTMX instead of a TS frontend, very few apps need a TS/React/... frontend. Doubling development effort with minimal gain (except games etc.)
Dabbled with Rust some years ago, I think it is an excellent choice for sudo-rs and such but for GUI and web apps I (perhaps too stupid) end up with arcmutex soup.
tome
I don't understand why Zig's `Io` is a "monad". In fact I discussed that with the author of this article and the author of Zig here, but no conclusion was reached (https://news.ycombinator.com/item?id=46129568).
But, flipping the script, if you want to see something like Zig's `Io` interface in Haskell then have a look at my capability system Bluefin, particularly Bluefin.IO. The equivalent of Zig's `Io` is called `IOE` and you can't do IO without it!
https://hackage-content.haskell.org/package/bluefin-0.5.1.0/...
Regarding custom allocators and such, well, that could fit into the same pattern, in principle, since capabilities/regions/lifetimes are pretty much the same pattern. I don't know how one would plug that into Haskell's RTS.
noelwelsh
Agreed, Zig's IO is closer to the effect handler / capability passing model. And by closer, I mean exactly the same [1]. However, it's related to monads by duality. A comonadic program is a program that depends on context, which captures the notion of passing capabilities around.
[1] Languages designed around capability passing often have other features, like capture checking to ensure capabilities aren't used outside the scope where they are active. There are only two such languages I know of. Effekt (see https://effekt-lang.org/tour/captures) and Scala 3 (see https://docs.scala-lang.org/scala3/reference/experimental/cc...) However, this is not core to the idea of capability passing.
george_____t
> I don't understand why Zig's `Io` is a "monad".
I don't see how it's true in any meaningful sense. It seems about the same as stating that any function is an example of the reader monad.
The whole point of monads in programming languages is as an _abstraction_ that allows one to ignore internals like how the IO token is passed around.
Maybe Zig is a language for people who are scared of abstraction. Otherwise they'd presumably be using something more powerful like Rust.
psychoslave
I guess that if a burrito can illustrate what is a monad, anything can be casted as a projection of a monad in some perspective.
continuational
Do you really prefer this:
fn Maybe(comptime T: type) type {
return union(enum) {
value: T,
nothing,
const Self = @This();
pub fn just(the_val: T) Self { return .{ .value = the_val }; }
pub fn nothing() Self { return .nothing; }
}
}
data Maybe a = Just a | Nothingrene_d
Optionals handle this in zig:
var value: ?T = null;
value = 10;
if (value) |x| x+=1continuational
Sure, but this is an example from the article, and pertains to sum types in general, not just Maybe.
dnautics
i dont think its generally a good idea to be making complex type generators like this in zig. just write the type out.
the annoyingness of the thing you tried to do in zig is a feature. its a "don't do this, you will confuse the reader" signal. as for optional, its a pattern that is so common that it's worth having builtin optimizations, for example @sizeOf(*T) == @sizeOf(usize) but @sizeOf(?*T) != @sizeOf(?usize). if optional were a general sum type you wouldn't be able to make these optimizations easily without extra information
undefined
undefined
nesarkvechnep
Came to say this. Early in my career I really thought implementing Maybe in any language is necessary but not I know better. Use the idioms and don’t try to make every language something it’s not.
eikenberry
This looks like an example of a low level language vs a high level language (relatively speaking). The low level language makes a lot more of what is going on underneath explicit compared to the higher level language which abstracts that away for a common pattern. Presumably that explicitness allows for more control and/or flexibility. So apples to oranges?
continuational
I don't think so, where's the extra information in the Zig example?
In Rust, which is arguably also a low level language, it looks like this:
enum Option<T> {
None,
Some(T),
}foltik
Low-level doesn’t mean more information, it means more explicit.
In Zig, that means being able to use the language itself to express type level computations. Instead of Rust’s an angle brackets and trait constraints and derive syntax. Or C++ templates.
Sure, it won’t beat a language with sugar for the exact thing you’re doing, but the whole point is that you’re a layer below the sugar and can do more.
Option<T> is trivial. But Tuple<N>? Parameterizing a struct by layout, AoS vs SoA? Compile time state machines? Parser generators? Serialization? These are likely where Zig would shine compared to the others.
rdevilla
My old memories of Guava in Java 6 have been triggered.
dev_l1x_be
I am going to look at Zig after 1.0 is released. The current state is that you are playing catch up with language if you have any reasonable sized project in Zig. A new release might mean that you need to rewrite significant portion of your code.
dnautics
io is not a monad. theres nothing stopping you from stashing a global io "object" and just passing the global wherever you interface with the stdlib.
It's dependency injection. and yes, you can model dependecies like a monad but most people, even in less pure fp langs, don't.
i don't really say this to just be a pedant, but if you're an fp enjoyer, you will be disappointed if you get the picture that zig is fp-like, outside of a few squint-and-it-looks-like things
tux1968
My reading of the article, was that the author seems to be in search of a new paradigm, that moves beyond what he sees as the limitations of "fp-like" languages as they exist today. His point appears to be that Zig provides the benefits of "fp-like" languages that exist today, while avoiding at least some of the downsides.
And he does admit you may have to squint, to appreciate the fp capabilities provided by Zig.
HelloNurse
It is worth noting that some rather "enlightened" type system features are common in other imperative languages, not particularly novel ides in Zig.
For example Swift enums, while in some ways clunky, can do a decent job both as newtypes and as sum types (unlike Java enums, which are a fixed collection of instances of the same class).
danieltanfh95
I am not even sure if its a general pattern (inject any dependency?) or a specific pattern they added to Zig
dnautics
idk in elixir we basically do exactly whats happening with io parameters when mocking or swapping implementations that all satisfy the same behaviour.
here. i am not the only one that refers to it as dependency injection:
https://daily.dev/blog/zig-async-io-io-uring-zig-0-16-rethin...
"Zig 0.16 introduces std.Io, a flexible I/O abstraction that uses dependency injection, similar to the Allocator interface"
danieltanfh95
Sigh. I meant that the zig authors did not make it a general pattern and just slapped on the DI pattern specifically for io, instead of generalising the abstraction so people can DI stuff.
adrian_b
While using "monads" in functional languages is a neat trick, I do not like them.
In my opinion, the concept of automaton is fundamental and it deserves equal standing with the concept of function (even if it is a higher level concept that is built upon that of function).
I believe that functional programming is preferable wherever it is naturally applicable, and most programs have components of this kind, but most complete application programs, i.e. which do input and output actions, are automata, not functions and it is better to not attempt to masquerade this with tricks that provide no benefits.
Therefore, I prefer a programming language that has a pure functional subset, allowing the use of that subset where desirable, but which also has standard imperative features (e.g. assignment), to be used where appropriate.
Paradigma11
For me monads are similar to inheritance. There are areas where one topic/functionality is dominant and it can really help to define a base class in a library or define a monad like for async. The moment you start to mix/compose things, things get ugly pretty fast.
lmm
You can't just put assignment in a functional language though - you lose the ability to fearlessly refactor that's the whole point. You either need something like a stratified language (which I've never seen actually implemented, much less production-ready, as much as I like the design of Noether), or you use, well, monads.
discreteevent
> look at the era of software that garbage collectors have ushered in. Programs are bloated, slow, and wasteful compared to the literal super-computers that are running them.
I don't think this even qualifies as correlation.
mrkeen
Maybe procedural programmers should take a look instead. I don't see functions.
a function from a set X to a set Y assigns to each element of X exactly one element of Y.
rienbdj
Under this strict definition you can’t even throw exceptions!
mattalex
Of course you can: you just have to define it in your type. The output set becomes a union type of the normal output and whatever you want as an exception.
If you write this as a monad, your get very similar syntax to procedural code.
rienbdj
I get what you are saying, but…
An exception is different to an Either result type. Exceptions short circuit execution and walk up the call tree to the nearest handler. They also have very different optimization in practice (eg in C++)
mrkeen
Then allow partial functions too. Maybe even require them to be tagged as such. (Is that within the capabilities of Zig's programmable type system?)
I don't mind escape hatches - as long as they're visible/greppable in the source code. You can always write undefined/error/panic/trace directives while you're coding, then come back and remove them later.
rienbdj
I would love a language that distinguishes functions (pure mathematical constructs) from procedures (imperative constructs that map in a predictable way to the instruction set).
This feels like the direction Algebraic Effects might take us.
suralind
My stack today is kinda nice but perhaps a bit odd:
- Go - backend + CLIs
- TypeScript - fronted, occasionally zx for more complex scripts
- Nushell as my scripting language (I’ve been relentlessly using it everywhere I can instead of bash/zsh and man it is such an improvement)
I heard so much good stuff about both Zig and Rust and would love to eventually get to know one of them.
crabsand
nushell + 1. After ~20 years of bash+zsh, I'm translating all my scripts to nu.
Yesterday I noticed I still don't know how to write
ls | where modified < ((date now) - 3wk) | each { |fn| rm $fn.name }
hootz
Nushell, from their website, looks a lot like PowerShell's idea of a shell, but less verbose.
suralind
Yup. Which is kinda funny, because back when I was a young dev using Windows I never liked nor understood PS.
stingraycharles
> when I was a young dev … never understood PowerShell
This makes me feel old.
Antibabelic
> Well, I’ve been radicalized. I’ve learned enough performance-oriented programming to be dissatisfied with the common functional languages (Haskell, OCaml, Common Lisp/Clojure, Scheme) because each of these languages are predicated on the existence of garbage collection and heaps.
I would take another look at Common Lisp if I were the author. Manual memory management is very much an option where you need it.
SomeHacker44
I found this funny. I am not sure if it was intended that way!
> Monads are not some kind of obscure math-y thing that only the big brains think are necessary. No, instead monads are a fundamental abstract algebraic description of imperative programming as a computational context.
Yep, as a non-big-brainer, I definitely get it now. :)
FrustratedMonky
You need to write a monad tutorial to really get it.
jstanley
> Noise is anything that must be written for the program to function that is not relevant to the domain.
> ...
> What facilities does the language provide me to create correct-by-construction systems and how easily can I program the type-system.
Isn't programming the type-system orthogonal to the program's domain in the same way that manual memory management is?
rdevilla
No? I don't agree. The domain can be strongly modelled in the types; for instance, declaring kilometers, seconds, etc. instead of using primitive floats/reals everywhere, to statically prevent dimensional analysis issues.
Get the top HN stories in your inbox every day.
These days I just use a few languages:
1. Go, when I first saw code I wrote almost a decade ago still compiles and runs in Go, I decided to use Go for everything. There were some initial troubles when I started using it a decade ago, but now it's painless.
2. Haskell, I use it for DSL and state machines.
3. Bash for all deployment scripts and everything.
4. TypeScript, well for the frontend.
Lately, I’ve been using Go and SQLite for nearly everything.
I don't think I’ve any motivation to look at any other language.
I gave up on Java, Python, Ruby, Rust, C++, and C# long ago.
Fun fact:
Same thing for cloud, I just don't use managed cloud services anymore. I only use VMs or dedicated servers. I've found when you want to run a service for decades+, you’ve got to run your own service if you want it not to cost a lot in the long run.
I manage a few MongoDB, PostgreSQL clusters. Most of the apps like email lists marketer (for marketing, sending thousands of email each day) are simple Go app + SQLite using less than 512MB RAM.
Same for SaaS billing, the solution is entirely written in Go and uses Postgres. (I didn’t feel safe here using SQLite for this for a multi-tenant setup.)
Our chat/ticketing system is SQLite + Go. Deployment is easy, just upload Go cross-compiled binary + systemd service file, alloy picks up log and drops it graphana which has all alerts there.
I don't need to worry about "speed" for anything I do in Go, unlike Ruby/Python.
When something has to be correct I define it model it in Haskell as its rich type system helps you write correct code. Though setup is not painless as Go, decent performance.
I write good documentation, deployment instructions right into mono repo. For a small team this is more than enough imho.
No Docker, no Kubernetes, just using simple scripts + graphana + prometheus + Loki and for alloy/nodeexporter. Life couldn't be any simpler than this.