[HN Gopher] I Probably Hate Writing Code in Your Favorite Language
___________________________________________________________________
I Probably Hate Writing Code in Your Favorite Language
Author : behnamoh
Score : 21 points
Date : 2024-07-01 18:41 UTC (4 hours ago)
(HTM) web link (lambdaland.org)
(TXT) w3m dump (lambdaland.org)
| echelon wrote:
| > Other languages I enjoy include Haskell, Elixir, and Rust.
| [...] Rust is great because it has a phenomenal type system with
| good type inference; it's metaprogramming story could be improved
| though.
|
| I agree with the author about Rust in that it has a beautiful and
| expressive type system. The fact that it can be used for systems
| programming, has a modern package system, and can be deployed as
| a single static binary are bonuses.
|
| Rust is a perfect little Go/Java replacement for microservices
| and web servers.
| JohnFen wrote:
| Just to prove the thesis of the title, I really hate writing
| code in Rust.
| daghamm wrote:
| Yet most of those are written in Go. In fact, the majority of
| the devops tools themselves (podman, k8s, etc) seem to be
| written in Go.
|
| Why do you think that is?
| Jtsummers wrote:
| > Yet most of those are written in Go. In fact, the majority
| of the devops tools themselves (podman, k8s, etc) seem to be
| written in Go.
|
| > Why do you think that is?
|
| Because time travel, as far as we can tell, is not possible.
|
| At least in the case of Kubernetes, Rust 1.0 wasn't even
| around until the year after it was first released (Kubernetes
| 2014, Rust 1.0 2015). It also came out of Google and Go was
| one of its blessed languages at the time (and today). Given
| Rust 1.0 wasn't out yet, I'd be surprised if it got more than
| five seconds of consideration by the team developing
| Kubernetes, if it was even on their radar at the time they
| started development.
| behnamoh wrote:
| IMO it's because boring, predictable, un-exciting tech
| often gets the job done, while shiny, exciting, enjoyable
| tech gets the job done less.
| Jtsummers wrote:
| It's fair to have an opinion, and that may be why
| Kubernetes hasn't been _rewritten_ in Rust, but I
| answered the question of why it _wasn 't_ written in
| Rust. It wasn't an option at the time (again, time travel
| is not possible).
| jmclnx wrote:
| I fully agree, you will hate my 2 favorite languages. One of them
| has received a lot hate over the many decades from almost every
| academic person. The other one has only started getting hate over
| the past 10 years.
|
| FWIW, I do not like any OO languages at all.
| ocular-rockular wrote:
| What languages are they? As an academic, I am curious because I
| have languages that I hate that blissfully unaware academics
| use...
| jmclnx wrote:
| One is COBOL, worked on that in the 80s.
|
| The other is c, which I went to in the 90s, that seemed to
| have started getting hate from everyone these days :) I
| prefer the K&R dialect is the version I started with.
| JohnMakin wrote:
| > The other is c,
|
| I struggle to take anyone very seriously that expresses a
| profound negative opinion about C - it is still so
| ubiquitous and odds are overwhelming that the person
| expressing this uses somewhere in their stack many
| libraries written in C anyway.
|
| I'd wager this is coming from the Rust ecosystem rising in
| prominence the last 10 years and Rust adherents being
| _really_ passionate about that (cool! I take no opinion
| either way, please don 't savagely downvote me).
|
| I find all such debates tiresome, I am much more interested
| in the _why_ of doing something than the "how." A
| programming language is a tool to me, nothing more. If the
| tool sucks I will choose a different one and probably feel
| zero emotions about it, but acknowledge not everyone is
| this way.
| mnk47 wrote:
| >I struggle to take anyone very seriously that expresses
| a profound negative opinion about C - it is still so
| ubiquitous and odds are overwhelming that the person
| expressing this uses somewhere in their stack many
| libraries written in C anyway.
|
| I like C, and I do think the hate mostly comes from the
| loud zealots in the Rust crowd, but this doesn't make
| sense to me. I hate car-centric planning, the fact that
| it's ubiquitous and that I drive around my city doesn't
| really affect the validity of my opinion.
| TazeTSchnitzel wrote:
| Paraphrasing you slightly:
|
| > I struggle to take anyone very seriously that expresses
| a profound negative opinion about [a language that] is
| still so ubiquitous and [...] the person expressing this
| [probably] uses somewhere in their stack
|
| Are you saying that because C is popular and widely used,
| someone can't credibly hold a negative opinion on it? Are
| we required to think highly of things because they are
| popular?
| whalesalad wrote:
| This is more of a style thing than anything else. Nothing
| stopping you from writing Python in an idempotent and functional
| style. I do it all the time. def
| winning_team(game_log: GameLog) -> Team: team_a,
| team_b = get_teams(game_log) points_a =
| get_points(game_log, team_a) points_b =
| get_points(game_log, team_b) return
| team_a if points_a > points_b else team_b
| IshKebab wrote:
| Well the syntax certainly fights you the whole way...
| jasonjmcghee wrote:
| I would argue (copying your data structures):
| def winning_team(game_log: GameLog) -> Team: return
| max( list(get_teams(game_log)),
| key=lambda t: get_points(game_log, t) )
| spicyusername wrote:
| I see this persona a lot.
|
| Functional programming just has something magical about it that
| really draws certain kinds of people in.
|
| I wonder if it has to do with the fact that, when you play inside
| the boundaries of what a functional programming language can do,
| everything feels so neat. So tidy. Like a game. Or using lego
| bricks. It almost feels insane to do things any other way.
|
| But then again, most problems live in the real world, where
| things are not neat, or tidy, or like a game. I wonder if this is
| why you tend not to see functional programming languages more
| broadly used...?
| DarkNova6 wrote:
| It strikes me that some people think in data, others in
| processes.
|
| Personally, I need transparency and understand everything step
| by step. But there are those that threat a function/process
| like a blackbox and just build pipes based on some defined
| axiomes. The latter also seems to do quite well in math.
| IshKebab wrote:
| My theory is two-fold:
|
| 1. Until now most functional programming languages have had
| abysmal syntax. I'm sure I will get downvoted for this but have
| you seen Lisp? I do not want to program in raw AST. ML is also
| pretty bad. Honestly the hardest thing learning OCaml was
| figuring out where to put the brackets and semicolons. I am
| 100% serious. (Well, that and fighting OPAM bugs.)
|
| Rust is functional but the syntax is 10 times easier to read
| and write. I think other languages will follow.
|
| 2. Functional programming has been synonymous with _pure_
| functional programming due to Haskell. Honestly I didn 't even
| realise there were impure functional languages until relatively
| recently. I thought to be "functional" a language had to be
| pure.
|
| Again Rust is functional and impure.
|
| So I think it's really that most "practical" or "engineering"
| languages just happened to be not functional until now because
| the idea of functional programming was hidden in weird and
| difficult to read academic languages.
|
| There's clearly nothing intrinsic to the functional paradigm
| that would mean it can't be used in the real world (otherwise
| Rust wouldn't be so popular).
| Ancapistani wrote:
| > I'm sure I will get downvoted for this but have you seen
| Lisp?
|
| How much time have you spent writing in lisps?
|
| I'm definitely an OOP person, but I spent a couple of years
| writing Clojure. After a few hours of working in it, the
| syntax just... disappears. I installed two tools in vim to
| help: one colored parentheses to match corresponding pairs,
| and the other inferred parentheses from indentation. After a
| week, I removed the first because I realized I literally
| never looked at them. Ever.
|
| The reason I didn't fall in love with lisps is because it's
| just hard for me to work in them. Yes, I'm _very_ productive
| once I get into flow state - but it took about a half hour
| each session before I got there. There were many days where I
| never got into that state for more than a few minutes here
| and there. It was a terrible experience as a result.
|
| With Python - and other OO languages - I can look at some
| code and almost immediately know what it does. It's just not
| like that for me in lisp.
| bsder wrote:
| > I wonder if this is why you tend not to see functional
| programming languages more broadly used...?
|
| The overarching problem is that functional programming trades
| extra thought _now_ for extra benefit _later_.
|
| Inexperienced programmers hate functional programming because
| they like "magic". They are having a tough enough time just
| getting the task at hand finished and the more stuff done for
| them without thinking, the better.
|
| Inexperienced programmers don't want to think about multiple
| threads. They don't want to think about the event loop or
| sockets. They don't want to think about the state of the
| protocol and why it shouldn't update multiple steps. etc.
|
| The only way for that kind of magic to happen is to have a
| bunch of implicit state that sits invisibly in the background.
| It's either global or part of a single mega-struct that might
| as well be global.
|
| However, if an inexperienced programmer sticks around long
| enough they eventually run into a Heisenbug that is difficult
| to replicate. In order to run down the bug, they start having
| to isolate _everything_. Suddenly, the words of the old
| greybreard start coming back: "Immutable is good" "Time needs
| to be an explicit part of your state" and "bytes in, bytes out
| --putting the bytes on the wire is a different function" and
| ...
|
| At that moment, they become an acolyte of functional
| programming and now qualify as an experienced programmer.
| behnamoh wrote:
| if {"Bjarne Stroustrup: There are only two
| kinds of languages: the ones people complain about
| and the ones nobody uses."} == True &
| {"Your favorite programming language is probably used a lot"} ==
| True then: return {"Must hate and complain about
| your programming language"}
| bazoom42 wrote:
| Two very different things:
|
| The language I would like to write in.
|
| The language in which I would like to debug and maintain code
| written by someone else.
| yr_robot_master wrote:
| > I could tell similar stories for other languages that I don't
| like programming in. These languages include JavaScript, Go,
| Java, and C++.
|
| ...
|
| > The thing I hate about all of the languages I listed is their
| emphasis on mutation. When I call a function and pass it a list
| or object or whatever, I have no guarantees about that thing's
| value when the function returns.
|
| This is not true for C++, where the 'const' keyword allows you to
| disallow mutation. Perhaps the author would complain that this
| behavior isn't the default, but the functionality exists.
| suby wrote:
| I read a lot of articles like this, and it's usually mentioned
| that their preferred language is expressive. Here it's mentioned
| as a dig against the top 10 languages, basically saying that they
| lack expressivity
|
| > make the language and syntax as simple as possible, and then
| even simpler at the expense of expressivity
|
| I understand why people say this because you can write these
| small highly condensed statements which would take a lot of code
| otherwise to do. I think it's probably the wrong word though.
| These languages generally prevent you from manually managing
| memory, which ironically makes expressing some designs or
| patterns impractical. If you want to express say writing a
| performant garbage collected language or something, a language
| like c or c++ is ironically more expressive than these other
| higher level functional languages with a runtime gc.
___________________________________________________________________
(page generated 2024-07-01 23:02 UTC)