Hacker News Reader

Comment by thatswrong0 | Hacker News Reader

Ok this is going to sound ignorant, as my only experiences in backend services have been Go and Python. I don't like either. Is there something I'm missing? For simple CRUD apps, both are sufficient. But (in my limited experience), the moment I've wanted to create more complex business logic with stricter constraints, neither has been quite up to the task.

Go doesn't make things easy. It asks you to repeat yourself. I don't like the lack of basic functions like a generic map / filter function.. I know Rob Pike just says "use for loops", but it feels so unnecessarily unexpressive. When I see map, I know what's going on almost immediately. For loops take more reading to understand. Nil pointers shouldn't be, yet still are, a thing (developers aren't perfect - why can't the type system help?). It feels like a straight downgrade from Python from a code clarity perspective. And it's typed, sure, but the type system doesn't let me express constraints that other languages allow me to do that would prevent entire classes of bugs. It doesn't feel worth it compared to Python. Yes, the core language ends up being comparatively "simple", but simple building blocks doesn't guarantee a simple overall system. And my company is very diligent from an architectural perspective.

But then when I look at Python, I'd rather just use Javascript with Lodash, esp. when it comes to the treatment of functions as first class objects[0]. Throw Typescript in there, and you get, in my opinion, a better type system than Go, so unless language performance is a major constraint (which it hasn't been for my company, our DB usage patterns it the biggest thing instead), why would I want to use either of these rather than Typescript?

[0] Edit: Dumb and wrong, I meant its treatment of anonymous functions. I don’t like lambdas.

View on HN

I have a lot of JavaScript history, but if I were optimizing for the things you want to optimize for, I would absolutely pick Kotlin above JS+TypeScript. It's got bunches of language features, including superior concurrency, and runs on a faster runtime to boot. Unlike TypeScript, it doesn't have a 20+ year old dynamic language at its heart.

In backend systems, I think that the overall architecture and management of data are much more interesting problems than the code. I feel like Go helps direct more of the thinking toward the overall rather than creating beautiful abstractions in the code.

We'll see if I still feel this way in a year.

You had me nodding in agreement until the last paragraph. Functions are first class in Python. You can pass them all over the place and use them the same way you would in JS. You don’t have Lodash but frankly it’s not needed. The stdlib, functools and itertools are pretty much all you could ever ask for.

I think I meant the treatment of anonymous functions - lambdas are limited compared to normal functions.

The lack of multi-line lamdas is one of my biggest gripes with python.

If you feel the need to use a multi line lambda you should be using a regular function.

This is a code smell for sure.

This is the silliest thing I see paroted. Anonymous functions are there for one offs. Sometimes a one-off is two lines. Breaking it out into a separate function is ridiculous.

You end up seeing functions declared within functions so that people can work around this limitation and it is grotesque.

Regular functions definitions can't be used as expressions.

You are basically saying that one should never need a multi-line lambda. Obviously, I disagree.

If you need to express something complex enough that you can't do it in a single statement in Python, it deserves to have a name (or more likely, it already has one in the standard library).

But python for loops can and typical do have multiple lines, yet that “block” inside the for loop doesn’t have a name. The fact that the body of a for loop can have multiple lines but an anonymous function cannot is a purely arbitrary syntax limitation, and the principle you stated ought to apply (or not apply) equally to both use cases.

This doesn't follow: for loops are there specifically for cases of the complexity that can't be handled by other constructs (like comprehensions). Anonymous functions are not, for the complex cases you give the construct a name.

It's a very intentional language limitation, much as semantic whitespace is an intentional limitation.

And there is actually a language difference. A for loop is a statement. A lambda is an expression. Python doesn't let you put statements into expressions.

I tentatively disagree with both of you.

I've sometimes wondered whether code would be universally clearer if all you could do in a loop is have a one-liner or call another function/method (mainly when looking at my own code within loops and thinking WTF!!!).

Would probably cause issues when teaching programming though. It would be interesting to have a compiler switch that enforced this...

What comes to mind immediately is that you would lose the ability to `break` unless you had another convention like returning a specific value to indicate you want to break.

If you are limited to one statement you could still do something along the lines of the following (no particular language):

  foreach ( $item in $list )
  {
    if ( 1 == some_function( $item ) )
    {
      continue;
    }
    else
    if ( 2 == some_function( $item ) )
    {
      break;
    }
    else
    {
      another_function( $item );
    }
  }

But I would immediately concede that it is starting to miss the entire point of why it was enforced in the first place...

I actually like this style (or similar if not quite as extreme). I find it's much clearer what's going on.

Thanks for writing this, that clarifies the issue more clearly and concisely than what I had in mind.

I will mention a core aspect of my argument, to add to your point.

When you make a named function and then use it separately somewhere else, there is a loss of locality. The logic is now further from its point of use. This is a cost, and sometimes it is an unreasonable one.

i'd agree with this, except you can have a function within a function in Python to limit scope and keep it local. yeah, you have to define it before the code using it - sometimes this feels like a boon though, especially compared to huge inline lambdas. so over time, my annoyance with this has decreased, and it doesn't bother me anymore.

I've started to use Python type hints, but even with typing I like to label my names things that describe local concerns (types are often more general than what you mean to say), and sometimes I'll deliberately shorten the names to make a Python lambda fit where in another language with bracketing I'd just take an extra 1-2 lines and format the line differently.

I've written snippets or data structures one way or another as I'm sure many have, and in my experience the results have been mixed. This and the fact that reduce has no bearing on your app architecture, I do see this as arguing over a small and vague gain or loss.

Large anonymous functions are very much a thing in JavaScript.

This trend will gradually fade into the history books. Just because it’s a thing doesn’t mean it’s a good one.

Large anonymous functions are a thing in every modern language I can think of except python. It’s the only sensible solution in the case of functional method chaining, which is much more readable than nested comprehensions. Python just got this one wrong.

Large anonymous functions are rarely used in rust, go, python, java (streams instead), or cpp.

Streams and repeated application of short anonymous functions are a much better solution to the method chaining issue.

If js supported better streaming tools, they'd be less common in js too.

> Regular functions definitions can't be used as expressions

I’m having a difficult time understanding what you mean here. Can you offer an example?

I have never felt compelled to write a multi line lambda.

Python can't replicate the structure of this JavaScript code:

  fooBaz(x => {
    // multiple lines of logic
  })

In python, you are forced to move the logic away from the point of usage, which means you lose some locality. This loss is sometimes not worth getting a "name" for the logic.

Of course, sometimes it is better to create a named function away from the point of usage, but I don't think that is always the case.

Multi-line lambda is not code smell.

There are a lot of cases like GUI programming where you need a lot of handlers which are suitable for lambda because they don't have a good name, and should never be called manually, and often they have multi-lines of codes.

If you need more power than a lambda you would use a nested function, e.g.

    def a(n):
      def b():
        print(n)
      return b

Nesting functions like this can have a bad performance impact because functions in Python are objects. Normally, all of those function objects are instantiated once when you load the module. However nested functions will be instantiated at runtime every time their parent is called, even if they aren’t used. This cost is perceptible in hot paths.

A lambda also behaves this way; it’s how it captures the closure scope.

Are lambdas different?

I’ve never seen it create a bottle neck, have you?

It will definitely be a problem if you use JIT interpreter like pypy

That's a lot of boilerplate for a closure…

The trivial lambda case is short, and you can do what the parent said if you want to do something that doesn't fit into the trivial lambda case well.

The "lambda" keyword isn't :(

Where's the boilerplate? "def b():" and "() => {}" are both 8 characters.

It is annoying that you have to give the function a name, though.

On the one hand it’s annoying, on the other it enforces a discipline of thought in the same way that having to name variables does.

That’s an interesting principle, something like “a block of code that is complex enough to be written across multiple lines of code ought to be given a name,” but standard idiomatic Python already violates that principle by featuring multiple lines in the body of a for loop. The fact that the body of a for loop can be multiple lines but the “body” of a lambda cannot is an arbitrary syntax inconsistency.

    def b(x):
      return x + 1

    x => x + 1

    def a(n):
        return lambda: print(n)

That's a couple characters over most languages I normally use. Plus lambdas have a number of strange warts and restrictions (no multi-line lambdas?) that leave me feeling that Python really dislikes traditional functional programming constructs.

Python has become less functional over time. It’s also not a particularly good OO language either. It’s really a more descriptive sort of bash that became ubiquitous despite its short comings.

In fact, they're first class in Go too, in fact there's fewer languages where that's not the case than is, I'd imagine.

While functions are first class in Go, the limitations of the type system make them less ergonomic to use, I think. Without user defined generics, many of the common uses of first-class functions become a lot less convenient to use.

Do you have an example where that's the case?

One easy example is map functions.

In typescript, if I have a bunch of "User" objects where each user has an "name" and "age" field, and I want to print a comma separated list of all those names formatted as "name -- age", it's simple. I write:

    let userNamesList = let userNames = users.map(u => `${u.name} -- ${u.age}`).join(", ")
    console.log(userNamesList).

This is possible in no small part because map is generic.

In go, to get the same level of expressiveness, I'd have to write the following stuff around it:

    func mapUsersToStrings(f func(u User) string, users []User) []string {
        result := make([]string, len(users))
        for i := 0; i < len(users); i++ {
            result = append(result, f(users[i]))
        }
    }

And after writing that boilerplate, I can finally write:

    userNamesList := strings.Join(mapUsersToStrings(func(u User) string { return fmt.Sprintf("%s -- %d", u.name, u.age) }), ", ")

That boilerplate, of having to write a specialized map/filter/etc function with a for loop for every combination of types you transform between (mapUsersToStrings, mapUsersToAddresses, mapUsersToAges) is really annoying.

It's harder to point to many other cases because, simply enough, people don't write such cases. The fact of the matter is just that go libraries make very sparing use of first-class functions because the lack of generics prevents it from working well, and so we end up with an entire language ecosystem where code is harder to read and with fewer simple abstractions reused across it.

You can still write any code without good generics or first-class functions, you'll just have more programmers writing more code with less clean abstractions.

map, filter, fold, etc.

If you add in Typescript as he said, is a much better proposition than mypy.

I dislike JS, but love TS. But really, who cares about me anyway?

The big picture is that JS is the English of software languages. It’s not beautiful, it steals from everyone else, and it’s never the best tool, but it’s becoming - more and more - rarely the wrong tool.

I expect this trend to continue. Some genius will get JS to compile to native bytecode (WASM is the intermediate step). And, it too will be neither the best language for the job, nor the wrong tool for the job.

The proof is in the pudding, nothing so wrong (JS) can be so right - and yet it survives, nay thrives.

As an aside, I find English to be a beautiful language. By stealing words from so many origins (Saxon words, Latin worse and Old Norse words), there's so much versatility.

The Saxon words are direct and burly. E.g. oak, brash, death, iron, etc. The Latin words are multisyllabic (e.g. multisyllabic :) ). The Norse words are just plain fun (e.g. Yule, law, heathen, oaf).

It's nice to be able to choose depending on context. Similarly, I find versatility to be nice in JS, as the community goes from embracing OOP to a more functional style.

It’s a shame we stole the spelling rules from all those languages too.

Variety is the spice of life.

And JS is the .splice of life

Go and Python would have to be the two easiest to use and most productive languages I've ever used. Other languages might have more powerful features but Go and Python just get more coding done more quickly and more efficiently. Other people's personal tastes may vary - and obviously do - but you can't dismiss these languages when they're so obviously very effective for many people.

Do you have any metrics to back up that belief?

Python is NOT an easy language at all. Easy to get started with, but when you are deep diving into language features, it's starting to get WAY MORE COMPLEX than Go.

I had similar feelings regarding anonymous functions before, having come from a more FP background.

Ways to make your Python experience nicer:

- almost never try to use map or filter. List/set/dictionary comprehensions are more pythonic and will be easier in the long run

- learn about standard library stuff, especially the methods on dictionaries, as well as the collections package. If you’re thinking about lodash, Python tends to have replacements that end up being better tbh

- if you really want a local function, just creating an inner def statement is fine. But KISS should usually make this rare.

I'm not going to unequivocally contradict you here. However, I feel compelled to suggest something.

What if the end goal is not to do something elegantly, or perfectly, or with superb efficiency?

What if the goal is just to solve a problem in a way that's a little better than what came before?

Just write an implementation of map/reduce/filter for every type in your go program!

Maybe you could create some text macros to simplify the process, and then run a preprocessor on your program, and then.... uh oh.

You joke, but source code generation is the standard way to generics in go. They even have some standard hooks for it in the build system.

I still consider weird that results of go generate are supposed to be committed. Since when does generated code belong to the repository :/

People here don't like C# for some reason, I write really complex business logic with it every day and it is not only easy to write, it is maintainable as well. My own JS code with lot less complexity is way harder to understand after a while.

Java can do almost all of that now, and offers excellent runtime performance.

Yes but hipsters won't be seen dead using it. It's soo not cool. Our industry is much less rational than we think.

Go seems to be optimized for onboarding new developers (particularly straight out of school) quickly, rather than for the long term comfort of developers using it. There are Rob Pike quotes that speak to the first part of that at least.

If I was a business owner, I'd love Go. But what I can't really figure out is why so many devs love it. It's far from the worst thing in the world, I don't hate it, but I just can't get excited over it either.

From what I can tell by reading what Go developers write, they like it precisely because it's not something to get excited over. It seems like the kind of language where once you learn it, you don't have to keep up with a bunch of blog posts detailing all the cool new things being added to it, and decisions over stuff like formatting are made for you. I primarily use Rust for hobby projects, and the steady stream of new features/libraries can get tiring. You don't have to use the new stuff in your own code, but if you want to use popular libraries, you'll probably be stuck using the new features. Making everything async seems to be the new hotness, and sometimes I wish the language would be nothing to get excited over.

100% agreed, and you made me realize something.

As someone who writes — I mean prose, whether fiction or not (mostly not: essays, technical, etc) — I had to come to terms quite early with the dichotomy you explain here.

There is a place for the "beautiful language", the parts of it and the ways of using it that make it a pleasure, as a writer and as a reader. This, unsurprisingly, usually demands a whole lot of additional work on top of the 'direct meaning'.

Then there's a place, in casual communication, in business, in marketing, in essays as well, in technical docs, in speeches, in a lot of places, for the 'direct meaning', or close to that. The efficient use of language, when all form recedes in favor of meaning, of concepts, of getting that 'other' to get what you mean.

It's just that, in human language, you do it all with the same tools, we use formal or topical subsets of a vastly larger ensemble. In programming, we're more likely to use different languages [themselves subsets of human language if you think about it, but let's forget that for the sake of simplicity].

And there are programmers among us who love to dabble in the form, like some writers would spend 10%, twice, ten times the effort crafting just "better form" over an already well-defined idea/story. While other programmers, or at other times, just focus on getting things done. Cue the spectrum in-between.

So it all depends what we put in our code, as programmers, as human beings I guess. Is that thing a personal statement? Or is it just garbage code to temporarily expedite some roadblock? How do we approach complexity, bottom-up from the simplest elements/code, or top-down with the most expressive almost-meta entities? Maybe some side-line out-of-the-box angle? See how we'd word all of these, in human languages, as in code. We just wouldn't say the same, nor code (select languages) the same.

I don't know if I explained it well. But looking at it from a human language writer, it all seems clear now. The whole rat race of languages, the churches, the sheer effort put into form when meaning has already been solved 10 times by others, the strong NIH syndromes... it's all so common in traditional writers circles. We're all just writers, really!

I think there can exist a happy middleground between constant churn and what Go currently provides. Some nice quality of life features like pattern matching and list comprehensions would go a long way towards making it a more pleasant language, without making developers feel like they're in a constant struggle to stay current.

It also lends itself to patterns in code. One thing that learned about Python coming from Perl was there was a “Pythonic” solution. Go seems to take that idea further with gofmt and a small but powerful std lib. I can typically glance at how someone is configuring their http.Server and understand the intention of the code.

The "pythonic" way was a mantra that has been obsolete for a long time. With Python, there are many (unsatisfying) ways to declare dependencies, many ways to format code (I hope "black" will prevail), many ways to format a string, many ways to create a struct/record...

The lack of quality batteries included also leads to "there is more than one way to do it" through the choice of unofficial libraries. My experience is that the extensive standard library of Go brings more normalisation.

> But what I can't really figure out is why so many devs love it.

I think, in order to understand why so many people love Go, you first need to understand why so many people love C.

Go is C with most of the warts removed (for application development). GC, easy strings, maps, easier first-class function syntax, code formatting, modern standard library, easy concurrency, etc.

Yes, there are plenty of places that C can go that Go cannot - operating systems and embedded devices are high up on that list. But for back end application development, it's great as long as your application is of a moderate size and you don't need specialized data structures.

That covers quite a bit of ground.

I have so much to agree. There is a reason, why still a lot of software is implemented in C. There are historic reasons of course, but also, because C is just powerful enough to do so, and that gives you a small language, which removes a lot of complexity. Of course, in the case of C, this comes along with the warts of lacking memory safety and limited type safety, which are responsible for a lot of bugs. Other languages like Pascal and Modula-2 did improve a lot in these respects. Yet, all of those languages remain simple.

That is the reason, I like Go so much. It is still a very simple language, but improves in the key parts of memory safety, having a GC, better type checking, and a few high level constructs, most of all having first class functions and closures. These enable many of the features of "higher" programming languages. You can do mapping functions over lists in Go quite fine.

> GC, easy strings, maps, easier first-class function syntax, code formatting, modern standard library, easy concurrency, etc.

So what part of C is not in the list of warts averted in Go?

> So what part of C is not in the list of warts averted in Go?

A simple language with only a few things to learn. Everything built up from those few things.

Huh. "A simple X" is a wily phrase, because everything is exceedingly "simple" in the aspect its designer had in mind[1], but complex from other perspectives. C may be simple in terms of how you would describe it building on the interface provided by a typical CPU, but to someone who only knows Scheme or Haskell learning the machine model is no small task--I don't think the 683-page length of the C11 specification can be attributed to its authors being long-winded. I don't really see Go as having inherited C's simplicity-in-terms-of-differences-from-a-machine-model. If they were optimizing for the same kind of "simplicity" that C has, they'd have to be out of their minds to add garbage collection, strings, maps, lambdas, and goroutines. Go, like Scheme, Haskell, and python, is a different "simple" from C.

1: unless designed by a committee with no such single-minded aim

Defers, channels, inexpensive goroutines, a mostly consistent standard library, very good performance, garbage collection, being similar to C, strongly typed, and readability are the reasons why I've enjoyed writing Go exclusively for the past couple of years. Almost none of these is exclusive to Go, but the intersection of all these certainly is.

You might want to try Ocaml.

There's a class of problems (servers running a simple protocol) for what a basic type system, convenient green threads, and a lot of optmizations are all that you need for great results.

For those Go would beat anything that lacks convenient green threads (Type Script included, also Java, C#, C++), anything that is dynamically typed, and anything that is interpreted.

Go is mainly loved by devs who love to build products over to write beautiful code. Go is for product builders who use coding as a mean and not an end.

Most of the "means vs. end" dichotomy occurs at a level above choice of language. Every language permits both beautiful code and ugly code. Every language allows you to optimize. I write Go every day and I strive to write beautiful and performant code, for the sake of writing beautiful and performant code. Go may not allow you express e.g. quicksort as beautifully as in Haskell, but its simplicity and pragmatism lend themselves to a different kind of beauty.

I find the tooling to be very attractive, especially since modules came out. go test, go mod, go vendor, etc... Working in the Go ecosystem is mostly pleasant and easy.

There are two kinds of devs: Devs who mainly like the feeling of wll writing code, and devs who mainly like building products. Go is by the latter for the latter.

It's bit meant to be exciting, it's meant to be effective, efficient, and reliable.

The performance of Go is not particularly impressive. Especially when it is used to write busy servers with many simultaneous requests. And as a language it is not inspiring either.

Not sure why business owners should love it either. Not enough features in the language coding productivity suffer in a long run. Also if the developer needs Go because other languages are "too complex" maybe said developer can't produce proper code anyways.

Complex languages don’t result in better programs. Else we would see Scala and C++ everywhere instead of them being relegated to narrow niches.

C++ is not a narrow niche. We do see it pretty much everywhere and it continues to be the most used language for systems programming, games, embedded systems, and pretty much anything else where performance is critical.

That is a niche, because most applications are IO bound and not compute bound. What even qualifies as “systems programming” is ill defined. Far more critical business systems run on Java and C# servers than C++. If there are C++ components they tend to be small parts along the critical path and not the primary implementation language.

"most applications are IO bound" - there is a whole world of not IO bound software running on cars, toasters, airplanes, desktops, hospital equipment etc etc. I do not think it is any smaller then that niche of web spaghetti being churned out by undergrads

I disagree with the notion that most applications are IO bound only. This is something people often say uncritically, but in my experience is false. Just using a non-native Electron or even Java application feels very sluggish and when you look at the Waterfall on slow web pages, what's slowing it down is very often unrelated to "I/O".

Secondly, C/C++ is like the third or fourth most commonly listed programming language in job listings. If you think all but 2 or 3 languages are niche, that is not what the word means.

C/C++ is not a language. I am also someone who has use C and C++ for years as part of my work and have mostly moved on to TypeScript because there isn’t much reason to use C or C++ anymore unless you are in one of those niches where you need to still program at that level.

Most software problems are not about solving them faster, it’s about combining existing components in new ways and figuring out to orchestrate it all.

I don’t care about copy elision, heap fragmentation, perfect forwarding, when my performance is being lost in the communication between services. What I need is a better architecture and more scaling, not concerning myself with if this loop is being vectorized, or that object is being moved instead of copied, and other minutia which inevitably ends up wasting your time when writing C++.

I don't necessarily disagree that not everything needs to be optimized for performance, but I would just argue that the use cases for Typescript are far more niche than the use cases for C++. There's more to software than just web stuff

Most stuff is web stuff now. And I’m not talking about front end, we do a lot of back end work in TypeScript because node is lighter than the JVM which makes it a better choice for lambdas. I’d say it also has more sophisticated static typing than Java or C++, while also allowing dynamic typing in the few cases where it is convenient. Having the front and back end written in the same language also reduces impedance between teams. A lot of our tooling is even written in it now, deprecating many Ruby scripts.

Most stuff is not web now. There is software in everything everywhere not just web sites.

Niche does not mean "stuff I don't personally use at my job", but that is the only definition under which Typecript is not niche and c++ is. C++ in 2019 had the 4th most job listings according to Indeed. Calling that a niche is absurd especially in comparison to Typescript.

The thing about C++ is that you need to recruit specifically for C++ programmers in a way that you don’t need to recruit for programmers in many other languages. The barrier of entry for C++ is high enough that you can’t just take your typical developer and ask them to write good C++, it’s a language which requires far more effort to become competent in.

There are also many places which just ask for Java/C++ experience for no apparent reason. Amazon is like this, all of their job listings mention C++ but only a very small percentage of the code base is in C++. There is at least 10 times as much Ruby code and it is part of systems that most engineers will have to work with, but no job application mentions that.

You know, there are things in between. As for being niche - not sure bout Scala as I have zero experience with it, C++ however is anything but.

c++ is in narrow niches?!

Java killed it for general purpose use in the 90s. It’s never your first option unless you are in areas like games, graphics, some embedded work, or quantitative trading.

"All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health, what have the Romans ever done for us?"

The Romans or the Chinese?

For reference this is just a silly quote from Monty Python's Life of Brain.

Please send an email to Rob Like explaining to him how he's not mentally capable of producing proper code.

Go and Python are for getting things done effectively, not nitpicking beauty of code.

That's why the authors of YouTube built YouTube in Python, and the authors of Khan Academy (re)built Khan Academy in Go, instead of bickering about nitpicks on HN.

Can you elaborate your criticism of python? Other than the incorrect mention of functions not being first-class objects, there isn't much I can extract in order to respond to?

> For loops take more reading to understand.

A short comment would help here.

A for loop could mean anything, and not necessarily what the author intended. https://en.wikipedia.org/wiki/Rule_of_least_power leads to list.filter(p) always calls p O(n) and returns a list of the same type with some or all of the same elements. list.map(f) always calls f O(n) times and returns a list of the same length. p and f can be reused and only depend on a single element. A good platform will inline list.filter(p).head into machine code that exits a loop early, that you don't have to write or review.

They could also improve the language. Map, filter, and reduce are such fundamental concepts.

Making them work with strong types would require generics which would introduce a lot of complexity to the language though. It's being debated for years.

It's pretty trivial to write your own custom map/filter/reduce though.

No, Go does not need this and I do not want it to get these useless "features". Go is simple and it gets things done with an amazing standard library. Use a different programming language if this does not suite you. Every programming language ends up with its own implementation of these "concepts" that it is hard to keep track. What is so difficult about for loops? It's simple for everyone and you don't need to learn new concepts because it works.

Thing is that simple != easy

But oh man it's the same discussion every time when Go comes up here

I think Go is pretty refreshing as it is. If it isn’t to one’s taste there are 3712 other languages to choose from.

Fundamental? IMHO, they are just syntactic sugar on a foreach loop. Which in many ways is bad because it provides yet another way to express the same concept, without a significant difference in the method of execution. What am I missing?

I mean a for loop is just a syntatic sugar of a if and a go-to, but go-to is easier to mess up.

Same with map, they are a constrained for each that is guaranteed to be a correct implementation.

Map and filter allow for a very concise and clear indication of the intention of the code, so it is much quicker for the reader to parse what it is doing.

Edit: Also, for loops are just a way of implementing a mapping, where you have data A that you want transformed into data A*. The map is the fundamental concept here, not the for loop.

Which is more generic, the 'for' or the 'map'? I think its the 'for' because it has additional capabilities contained in the base concept, which is why I would call it more "fundamental".

In fact in many languages much of filter() can be implemented in the for construct rather than its body.

There are two sorts of 'fundamental'. You are correct that the 'for' is just syntactic sugar for 'goto' which is more fundamental than map/filter in the sense that it translates into assembly/machine language, upon which all programs are built. Then you can say the silicon logic gates are even more fundamental, you can do even more things with them, etc.

The map/filter is more fundamental in a mathematical sense. If you turn a list of A turned into a list of A*, the 'mapping' is the fundamental concept, the 'for' loop is just an implementation detail. Maybe the computer did it in parallel, or in random order, or I asked you to turn a pile of towels into a folded stack of towels. The same way if I say 'want to watch a movie' - the movie the fundamental concept, whether it's digital, film, etc. is irrelevant.

They don’t have to be glorified for loops, even if they usually are. Map and Filter should be capable of running in parallel or asynchronously, and some languages provide this.

And many languages, have parallel for constructs. The openmp #pragma parallel extensions in C/C++ for example. Of course its possible to create constructs which provide the messages passing for clustered environments too.

And maybe that is part of the problem with a generic 'map' your not really sure the underlying implementation, is it parallel, clustered, serial, etc? So you end up with map(), parallel_map(), mpi_map(), etc, and how to you control the parallelism. Do you just let it default or do you have levers to control the batch & interleave. Pretty soon, its not such a simple construct anymore.

In a functional language those details should be irrelevant. But of course they are relevant in practice, and map is usually just a for loop.

Why isn’t the foreach form the syntactic sugar?

Do you mean a code comment could help the reader understand, or you want a comment about why for loops are less obvious than other more functional approaches?

Code comment

Check out rust. Everything about the language is sturdy.

>I'd rather just use Javascript

Not a phrase you hear every day.

Most people who hate things can recognize that other people don't hate them.

For some reason, JavaScript haters always seem baffled when confronted with a person who doesn't hate JavaScript.

Typescript is a hack on top of supposly server side language that is aweful. ( Node doesn't even support int64 )

I'm sorry, what were you trying to say here? I've been staring at it for a few minutes and can't decipher it.

As I read it:

> “Typescript is a hack on top of [a] [supposedly] server side language that is [awful]. ( Node doesn't even support int64 )”

"supposedly" in this context meaning Js is not worth being called a "server side language", in the commenter's opinion (citing lack of int64 support for example). This also implies in subtext that "server side languages" would be of a higher category/value than languages for whatever other use-cases.

I personally don't agree with any of that, just helping communication here.

Node supports BigInt now (integers of arbitrarily high precision).

Reply on news.ycombinator.com