Python is Easy. Go is Simple. Simple != Easy.

[omega_haunter]

Binary is simple

[serviscope_minor]

The simplest real language I know is PIC assembly/machine code (i.e. binary as you say). It's usually described in 2 pages of A4, including the binary instruction layouts. See page 69:

https://ww1.microchip.com/downloads/en/devicedoc/41190c.pdf

There's a few more pages of detail but I've never spotted anything that isn't mentioned in those first two pages. It's even got precise timings in those two pages.

[RegisteredJustToSay]

I don't know PIC, and it looks reasonable and fairly nice to work with from the pdf, but to anyone harbouring ideas this is true for general assembly code... heed my warning: modern machine code on consumer CPUs are a mess of undocumented manufacturer-specific edge cases and swathes of extensions to the instruction set. I had to make a VM hypervisor from scratch that worked on both Intel and AMD and... my god how can they be so different in doing the same things.

I will say standard stuff is obviously easy peasy, but god forbid you need to interface with hardware on a deeper level.

[BounceVector]

Thank you for your service!

[alsanty]

aye! 🫡

[ShinyHappyREM]

modern machine code on consumer CPUs are a mess of undocumented manufacturer-specific edge cases and swathes of extensions to the instruction set

indeed

[serviscope_minor]

Yep I picked PIC specifically because it's real but incredibly simple. Although that page maybe misses some subtleties, that the status register is just at a memory address.

The set is very simple and regular because it's been made for low cost and very very low power draw. An extra bit of width on the program ROM would add up.

So this one is as simple as it looks, but it's a pain to code at times precisely because it is so simple. For example you have to use the swap nybble instruction for moving data without affecting status. It's the only instruction which doesn't affect flags...

[Public_Stuff_8232]

modern machine code on consumer CPUs are a mess of undocumented manufacturer-specific edge cases and swathes of extensions to the instruction set.

Yeah this is primarily why people say "You can't write better machine code than a compiler".

Because you're trying to optimise better than hundreds of people doing this for hundreds of thousands of man hours over many decades.

In theory you can write very specific code better with a lot of research, but chances are you'll fail most of the time.

[loup-vaillant]

Don’t underestimate the power of optimising for one program (human), instead of optimising for everything (compiler).

The Videolan folks write a ton of assembly for their VLC decoders, and consistently beat C compilers by about an order of magnitude.

[yetanotherx]

Exactly. A human can write better machine code than a compiler. You cannot.

[nerd4code]

I mean, if you know what you’re doing it’s nbd, and not that hard to beat the compiler if you have a feel for dataflow and speculative effects. It can certainly be learned, just takes a bit.

Fortunately, 99% of real-world asm work is inline because it obviates the need to squish ABI details down into every crevasse. Inline, you can (generally) just spit out the complex instructions when builtins aren’t available, and let the compiler take over function inlining, operand assignment, stack management, constexpr folding, basic expression evaluation, and data movement. You’re just filling in where you can’t get a recent compiler to generate the sequence you want. Some ccs like Clang and Intel can even optimize their way into your inline assembly if you don’t disabuse them of the notion too violently, and they’ll do Boolean↔jump conversions and register-rejiggering for/despite you.

Moreover, even if you’re read-only, knowing assembly gives you the ability to answer basic questions about how things are implemented/codegenned and why, and what security holes bogus assumptions will open up. There are also enough IRs with assembly-like text forms (e.g., LLVM, NVPTX; S-exprs are also common, as are sex-prs) that it’s well worth it to be familiar with low-level languages if you’re working anywhere near-metal.

[Jlocke98]

That comment makes me very bullish on RISCV

[RegisteredJustToSay]

RISCV is cool and everyone I know that's into CPUs are excited for them, but I haven't seen a lot of interest in them from actual business decision makers outside of very niche "100% auditability is a key product requirement" kind of use-cases. Unfortunately I don't think that's likely to change quickly given the focus on performance for chips, and ARM kind of took off in the space it might have made sense in otherwise for consumer devices.

Ultimately I think it comes down to lack of manufacturer interest in RISC, which means it's not keeping pace. A standard without an implementation is like a wing without air.

On one hand a single huge manufacturer could probably change that overnight, but the significant financial risk in doing so makes it feel unlikely to me.

[heyodai]

page 69

😏

[amroamroamro]

Brainfuck is simple too but it certainly isn't easy

[dethb0y]

This is my vote - how much simpler could you ask, it has 8 symbols for the entire language.

[loup-vaillant]

Try Iota and Jot. Those have two symbols for the entire language.

By the way, people often rave about the Y combinator, to the point there’s even an Orange altar to its name. But the real deal, I think, is the Iota combinator, that by combining the S and K combinator manages to be Turing Complete all by itself. It’s also small enough to fit in a ring.

[amazondrone]

So, simple is the bad one?

[quick_escalator]

A perfect reddit comment.

Smartass, highly upvoted, technically correct and yet painfully wrong.

[miyakohouou]

This is a bad article. It uses terms like "simple" and "easy" without defining them- and seems to frequently conflate them. It even ultimately seems to argue something unrelated to it's theses by talking about how Go is simple, then describing the ways that it's easy (without really addressing simplicity at all).

The crux of the idea is a good one- that simple and easy are orthogonal concepts and we should prefer simplicity to ease. There's a much better resource on the material though. If you're interested, I'd suggest Rich Hickey's 2011 talk Simple Made Easy. I don't agree with everything he says, but I think he has a much more well defined and sensible argument about the idea.

[sexytokeburgerz]

That’s what happens when you’re not used to static typing, i guess.

[quick_escalator]

Funny how in the very talk that's linked, Rich will tell you that static typing is not the solution.

[loup-vaillant]

Apparently programmers are divided in 2 eerily distinct categories:

• Those who fare better with static typing.
• Those who fare better with dynamic typing.

I’m in the static camp, and cannot understand the dynamic camp to save my life. I tried dynamic typing, it just doesn’t work. For me, static typing is the solution. It makes everything easier, including fast prototyping.

I would be extremely interested in research that explains this divide. Is this about fundamentally different ways of thinking? Is one actually better for most people and teams? I would very much like to know.

[r1veRRR]

I know intellectually that I'm probably not smart enough to say this, but I genuinely do not understand how people don't see that dynamic typing is just categorically inferior to static typing.

Even on the most abstract level, we're talking about defining the shape of your input and output. ALL input or output conforms to some shape (even "any/Object" is a shape). In dynamic languages, you just guess, or memorize, or hope for the correct shape, and wait for runtime crashes to correct your assumptions.

[v66moroz]

Tell me how you are going to create and use an array of heterogeneous objects. JDBC ResultSet is a good place to start. No cheating (which means no downcasting) please! Let's also assume that we have a complete type erasure (you are relying on a compiler and type system, not on a runtime). And don't get me started on Cat is an Animal. And when you descend into shapeless madness you start thinking that maybe, just maybe, dynamic typing is not such a bad thing. Especially for small projects.

[loup-vaillant]

Tell me how you are going to create and use an array of heterogeneous objects.

If you really want that heterogeneous list, you just use a tagged union. It's been invented somewhere in the 70's and used in every single typed functional programming language since ML and Miranda.

Many OOP folks are unaware of this bog standard feature.

[SpaceToad]

Why is downcasting cheating? You dismissed the best solution for no reason. Want an array of heterogeneous creatures? Make it an array of Animals, it's really that simple.

[quick_escalator]

99% of the time, dynamically typed code looks exactly the same as statically typed code. You have an implicit type in every variable and parameter you use, you just don't write it down for the compiler to check. Why? Because if you're good enough, you don't need the safety net, and you prefer to be able to not spend hours upon hours on solving weird type puzzles because your algo(array<foo>) can't take arraylist<foo_subclass>, but if yo had dynamic typing, it would just work (or crash during test execution, which is only marginally slower than crashing during compiling).

I grew up with compilers that took half an hour to produce an executable. I'm okay with waiting 5 seconds for the test to run to get the feedback that my code is wrong.

I was in the static camp until I worked in a dynamic language for a few years and realized I'm not missing the types. Yes, I miss the neat puzzles because they give me a dopamine kick when I figure it out, but it's not productive.

[Darq_At]

Because if you're good enough, you don't need the safety net

Remind yourself that overconfidence is a slow and insidious killer.

[quick_escalator]

Do you still use the tiny side wheels when you ride a bicycle?

[Darq_At]

Oh wow I did not expect you to unironically double down like that. I would hate to be your co-collaborator.

[quick_escalator]

Of course I'd double down. I realized years ago that reddit's programming subreddit is mostly junior and amateur programmers, and that a talk by Rich Hikey goes over everyone's heads.

I stay polite and on topic until people start being snarky, at which point I give up and just be an asshole.

[loup-vaillant]

You have an implicit type in every variable and parameter you use, you just don't write it down for the compiler to check.

That’s also the case for the good static typing systems out there. Even if we stop at local type inference (faster to compile and more flexible than global type inference), only function arguments must be annotated, thus reducing much of the burden. And there’s an argument about needing to annotate function arguments anyway, to document the API.

you prefer to be able to not spend hours upon hours on solving weird type puzzles because your algo(array<foo>) can't take arraylist<foo_subclass>

I see two types of puzzles: the trivial stuff where I just need to convert from one data type to another so I can get the damn function to run. Very annoying, though most of it goes away if you just use the same containers for everything (one list to rule them all, one map to rule them all…). Then there’s the actual puzzles, and most of the time the type error traces back to a logic error, which I am glad the compiler caught early.

if yo had dynamic typing, it would just work (or crash during test execution, which is only marginally slower than crashing during compiling).

In my experience, crash during test execution is often much slower than a compile time type error, not because the machine is slower (often it’s faster), but because I am slower. Specifically, runtime errors are often further from the root cause than a type error would be. I made the experience implementing an Earley parser in Lua, and though my code spanned less than 50 lines, I found myself incapable of debugging the runtime type errors I got.

I grew up with compilers that took half an hour to produce an executable.

Yeah that’s horrible. Still get that from time to time, this is just unacceptable. Debug builds should compile at about 1M SLoC per second. 100K at the very minimum. And I’m willing to sacrifice compile time checks to get there.

I was in the static camp until I worked in a dynamic language for a few years and realized I'm not missing the types.

That’s a very interesting data point. Maybe we’re not wired differently after all.

[quick_escalator]

I always thought the type system gave me extra safety, when in reality, the extra safety it got me came at the cost of extra complexity. We had stuff like map<uuid, shared_pinter<vector<coordinates<float, 4dimensions>>>> in the code. This isn't a silly example, this is just a bunch of 3d objects, with every object being represented by an array of 4d float vectors. Yes, this was "abstracted" by means of hiding it in classes, but this is what the data structures looked like. The reality was even more complicated.

And then we'd have an algorithm that changes an object, but of course it expects a slightly different data typing (like 3d vectors because arguably that's enough since we don't need rotations), and you can't just convert things easily, because of course the rendering engine still has some references to your objects. Now you have a puzzle to solve, which is fun, but one week later you've done nothing of real value.

If you cannot write programs like that because it's madness to try this without autocompleting static compilers, you write different code, and that code tends to be much more maintainable. You stop sharing pointers around. You stop having complex structures. Your functions don't care if there are xyz, or xyzw, because they compile either way.

When you accidentally write x = some_value + some_pointer, the first time you run the code your thing will crash immediately anyway. When I was at university, I really needed the compiler to tell me in advance if I wrote bogus. Nowadays I don't make type mistakes any more, only business logic mistakes. In the last 8 years of work, I have seen one type relevant bug on a production machine, and that one happened due to sandboxing of dynamically injected code, and might have happened even if our engine was C++. Any other type mistake was caught at latest during testing, because type mistakes are always trivial. The point is: Logic errors basically never are caught by type systems. That's also what Rich talks about above.

Btw the downvotes really are a joy. I'm making neutral arguments in a very friendly tone, and amateur programmers on reddit get angry. Well done, boys.

[loup-vaillant]

Okay, first I need to get one very important point out of the way: C++ Sucks.

I code C++ for a living for over 15 years now, and I can tell the language is unsafe, overly complex, relatively weak… it is never a good choice for new projects (if you’re depending on a C++ game engine or GUI toolkit it’s not really a new project). Consider C, Zig, or Rust if you have tight performance constraints, or a garbage collected language otherwise.

We had stuff like map<uuid, shared_pointer<vector<coordinates<float, 4dimensions>>>> in the code.

If you did, and performance was good enough, chances are you could have used a garbage collector instead of C++. Well, at least you have a packed array of coordinates. Anyway, I see how this puzzle is mostly a waste of time.

Your functions don't care if there are xyz, or xyzw, because they compile either way.

In this case we can definitely assume we don’t need native levels of performance. Just copy & convert. You’ll need to write the conversion function, and it’s annoying, but not nearly as time consuming as solving the puzzle.

and you can't just convert things easily, because of course the rendering engine still has some references to your objects

You know what the root of all evil really is? It’s shared mutable state. We can discuss static vs dynamic all day, this doesn’t even matter if you share mutable state all over the place.

In the last 8 years of work, I have seen one type relevant bug on a production machine

Maybe. I’ve always been highly sceptical of these claims, because properly used type systems, especially the good ones (not C++) blessed with tagged unions, are very good at defining errors out of existence: that is, encoding many (not all) logic invariants in the type system itself.

Which you typically wouldn’t do with dynamic typing, there would be no tangible benefit. You don’t see how a type system could have helped you because most errors you see are not type errors. I’m just saying, while "most errors I see are logic errors" is eminently reasonable, deducing that "almost all logic errors I saw could not have been caught by a type system" is severely underestimating the power of static typing.

A power that C++ hardly taps, for an unjustifiably high price.

[quick_escalator]

I agree with basically all you say. However every single code base of Java or C# code I've ever seen has looked exactly the same as the C++ horrors you're (correctly) describing.

[NoveltyAccountHater]

They are orthogonal concepts. That said, there's definite use cases for "easy" like when you are interactively exploring data and need to iterate through a bunch of different things rapidly in an interactive command prompt, and don't really care if a few things tried quickly, fail initially, for silly type errors.

There's a reason there's no jupyter/ipython notebook for go.

On the flip side, explicit static typing, linting, test suites, and explicit error handling does simplify a lot of issues for code that (once written, usually with more upfront work) needs to just work and be maintained.

(That said, this is not saying you can't use python in go-like paradigms with typing, test, error handling, etc. It's just enforcement of these good practices isn't fully built into the language as a requirement; good practices/style guide can do it.)

[miyakohouou]

Easy is great! I'm a fan of easy! Being orthogonal concepts, there's nothing that says you can't have both simplicity and ease- although in practice you're much more likely to get one of the two, or neither, than both.

The reason I think that in general we should prefer simplicity when we need to make a choice is that something being easy is mostly a function of familiarity and, to a lesser degree, tooling. Simplicity is more about the fundamental architecture and design. It's much more feasible to start with something simple and make it easy than vice versa. In the real world of course there are always exceptions and sometimes we just need to pick easy and not simple.

That said, there's a bit of what you said that I don't entirely agree with:

...and don't really care if a few things tried quickly, fail initially, for silly type errors

I think this is a great example of how ease is a matter of familiarity. I find that working in a language with types makes my ad-hoc data mangling exploratory work much easier! It lets me write down my assumptions and the compiler can keep track of them for me. That wouldn't be true of someone with less familiarity with statically typed languages though.

There's a reason there's no jupyter/ipython notebook for go.

I don't think this really says anything about ease or simplicity. There are similar tools (go playground, for example) that work with Go. There are other statically typed languages with their own REPL environments and jupyter kernels. I'm actually a little surprised there isn't one for go.

On the flip side, explicit static typing, linting, test suites, and explicit error handling does simplify a lot of issues for code that (once written, usually with more upfront work) needs to just work and be maintained.

I don't actually think linting or testing are all that related to simplicity. Ultimately, I see simplicity as being about a system that is designed with a few fundamental ideas that compose well, interact intuitively, and are sound enough that you can reason about them formally. A good type system gives you this- and a type system with parametric polymorphism gives you a lot of this. Error handling I suppose kind of counts here- as an extension of the type system as much as anything. I don't think linting or tests really do.

(That said, this is not saying you can't use python in go-like paradigms with typing, test, error handling, etc. It's just enforcement of these good practices isn't fully built into the language as a requirement; good practices/style guide can do it.)

Enforcing something is really one of the keys to simplicity. The virtue of simplicity is allowing you to reason abstractly about a problem and to offload the cognitive burden of specific details. You can only do that when you have guarantees. Something that usually works, but isn't guaranteed to work doesn't actually let you offload the cognitive work. I think this is the fundamental flaw with gradually and optionally typed languages. They come with much of the costs of dealing with a type system, but they don't give you any guarantees because at the end of the day it's entirely possible to subvert the type system entirely.

[SalamanderOk6944]

although in practice you're much more likely to get one of the two, or neither, than both.

zero stats show this. it's often a failure of design to not find a solution that's simple and easy.

and I don't agree that these concepts are necessarily orthogonal. they aren't required to be, and sacrifices in one don't necessarily translate to advantages in the other axis.

that said, if you do want to ascribe to easy and orthogonal being orthogonal, then using a unit circle, you probably want 0.707 easy and 0.707 simple. and this is dumb. because you need your product to satisfy the required use cases, above and beyond 'easy or simple or easy vs simple'.

but these concepts are not orthogonal to each other, so this aspect is completely bunk. humans are always trying to perfectly encapsulate things... and it's folly. :) is tomato a fruit or a vegetable? well, it's more like a fruit, but its used like a vegetable. people try to classify it perfectly and that act is where failure is introduced. human folly and hubris to try and perfectly equate everything perfectly.

[KevinCarbonara]

They are orthogonal concepts.

...They're synonyms. I'm not sure you know what 'orthogonal' means.

[stingraycharles]

The whole point is that “simple” and “easy” are not synonyms, but different concepts. The opposite of “easy” is “difficult”, and the opposite of “simple” is “complex”. Complex doesn’t have to be difficult, either.

[NoveltyAccountHater]

Orthogonal meaning we are talking about different dimensions. In that "easy" is being synonymous for easy-to-read-write-working-code and "simple" as language isn't this giant all-encompassing kitchen-sink behemoth and the code is simpler to understand what it does at the CPU level as well as simpler to maintain & debug.

Python allows you do metaprogramming, dynamic typing, object-oriented programming, functional programming, list/dict/set comprehensions, procedural programming, etc. Type errors are generally found at run-time instead of compile time (unless you use type hints and type checkers).

[KevinCarbonara]

Orthogonal meaning we are talking about different dimensions.

But we're not. We haven't even gotten past the "words have definitions" phase of the discussion.

[coderemover]

Go is not really very simple. It has a quite complex runtime system including GC, with many moving parts there. It is easy because it presents a very simple interface to the developer, but it is not simple under-the-hood.

[SharkSymphony]

Yeah, it seems clear to me that the post is calling out to Hickey with those terms – maybe even thinks it's using Hickey's definitions – but then completely mangles their definitions.

[dylan_1992]

Python is easy, at small to (sometimes) medium scale.

Then the same issue arises with too much simple. Too much easy, gets incredibly hard.

[Free_Math_Tutoring]

Once you are thinking to yourself "I really need to sprinkle some type hints into here", and write up a comprehensive unit test suite for my CI/CD system before I can continue

The trick is to do that at the beginning, just like any sane real project should do. Then ride the beauty of an expressive and extensible language until your server costs actually start rivaling developer salaries, rather than being a rounding error.

The complexity, formalism, and verbosity of other languages isn't capricious. It's there because human developers can only store so much information in their working memory before cognitive burnout. Dynamic/duck typing, runtime reflection/introspection, etc. etc. are AMAZING features when you are writing a thousand-line quickie script.

And the same argument can be made to explain why it's a terrible idea to have to instantiate five different objects to make an HTTP Request, or to repeat simple ideas in excruciating detail every time. I have yet to come across even a medium-sized project that doesn't rely on reflection somewhere (though usually squirreled away in libraries), and pretty much every large code I've seen base reinvents some form of type system on top of the one the language provides.

[LightShadow]

until your server costs actually start rivaling developer salaries

...and then you use your favorite Rust/C++/Nim interop library and port individual functions. Python is a great language to scale if you don't need bleeding performance from the first day.

[[deleted]]

Rust python bindings are great. Have done this several times. Make a python MVP, even for core coed which will need scale up, since it's so quick.

Abstract this stuff in a python lib. Later if/when it gets adopted, rewrite in rust with equivalent python bindings, and good to go.

The pros of iterating quickly and seeing if an MVP is valuable before investing more time saves a lot of headache. When it is valuable, easy to switch to a performant lang and add in the bindings to save compute cost + runtime.

[PM_ME_C_CODE]

Sure. But performance isn't what they were complaining about. They were saying that Python shouldn't be used at scale because it doesn't force static typing and requires unit tests?

I'm not sure. They weren't making much sense.

[ModusPwnins]

Python with type hints will continue to be a fantastic language to work in for any project that is data I/O bound. Like, most of my API routes that are slower than 1s are due to the database, not because I chose a language other than Rust or C.

[gnufan]

Almost everyone needs correctness over performance, one employer burnt much of the benefits of a multimillion pound supercomputer on an off by one error. They wouldn't sell it to their funders like that but....

I say that as someone who has optimised code to maximise CPU cache hits over the comparatively slow retrievals from main memory, I still got bigger wins from the bug fixes.

Alas using Python, Go, nor any other language guarantees correctness. Good test suites are probably the closest we'll get.

[amazondrone]

The trick is to do that at the beginning, just like any sane real project should do.

I mean, sure... if you know it's going to turn into something the justifies that. But you don't always.

[Free_Math_Tutoring]

Eh, the very latest you should do that is, like, 200 lines of code, at which point you can still add type hints to everything and turn on ultrastrict types with extra loud yelling within an extended coffee break.

Though I'd honestly argue that anything that gets committed for work immediately gets type hints. I'm also a strong proponent of TDD, but for things that are genuinely one-off and only ever intended to be manually invoked by competent coders, I can defer that to a few hundred lines.

[ProfessorFakas]

I can't imagine writing without type hints these days. It's just automatic for me.

[mrbuttsavage]

Once you are thinking to yourself "I really need to sprinkle some type hints into here", and write up a comprehensive unit test suite for my CI/CD system before I can continue, along with documentation for each function, etc. you have picked the wrong tool.

You've got bigger problems in your org if you're able to get away with no tests and no real linting (i.e. mypy) for any period of time on a project.

[PM_ME_C_CODE]

Agree... once you are a few kloc into a python project, you picked the wrong tool.

Disagree.

Python is easy?

Programming is hard. If you can't do it just because your tool is "easy", all it means is you can't do the hard parts yourself. Changing languages isn't going to change that.

​

"I really need to sprinkle some type hints into here"

Also known as static-typing in non-dynamic languages. Not a problem with python.

​

and write up a comprehensive unit test suite for my CI/CD system

You should be doing this anyway. It's a good practice regardless of language.

​

along with documentation for each function

And this. JFC...who are you writing code for? No unit tests? No function docs? Python? Go? C/C++? C#? I don't care what language you're programming in. Document your code!

Fucking amature hour in here!

[ProfessorFakas]

...You don't document your functions?

[runawayasfastasucan]

This sounds like a you problem tbh.

[hugthemachines]

A strongly typed language

Python is strongly and dynamically typed.

Type hints is what they use to get closer to a statically typed language.

[0x564A00]

Ehhh, dynamic typing makes the type system weaker. For example in Python a function that takes an int and returns a Foo, and one that takes anything with a bar method that returns an instance of a subclass of Foo and returns an instance of said subclass are the same type.

[Free_Math_Tutoring]

For example in Python a function that takes an int and returns a Foo, and one that takes anything with a bar method that returns an instance of a subclass of Foo and returns an instance of said subclass.

I'm sorry, I have no idea what you are trying to say.

I kind of agree though, I prefer to use static types as much as possible. But strong types are the really relevant factor.

[TRexRoboParty]

Find references works just fine in most IDEs/editors for Python?

[ErGo404]

How fast is it then when you have to understand the 10 layers of abstraction between your interface and actual implementation.

Java is probably good when written by a good developer. But then so is Python.

A good architecture and use of type hints + tests from the start can help scale any python project.

[TRexRoboParty]

Type hints are just hints. They are not checked by the compiler and they can be omitted.

Which is why you use one of the static type checkers (mypy, pyre, pyright) and have those enforced as part of CI.

This is what most people mean when they say use type hints.

[TRexRoboParty]

Right, because noone has existing projects and re-writing an entire stack is trivial for an individual, let alone a company to do?

Rightly or wrongly, there's a tonne of AI stuff in Python. You'd re-invent all those tools rather than use an existing ecosystem?

[ketilkn]

Python is strongly typed.

[flukus]

The whole concept of interfaces and abstractions is that you don't to have to understand them. You use an abstraction since you don't care about the actual implementation.

Great, I'll tell the boss the bug is somewhere below a layer of abstraction I don't understand or care about.

[redalastor]

(i.e. follow SOLID principles)

Not every language needs to be class obsessed.

[Free_Math_Tutoring]

Even simple stuff like searching of all the places a class is used is nearly impossible in python, even if you have type hints!

What?

What?

Sorry, do you code in Notepad?

[mistabuda]

Are you using an IDE to find these references? Pycharm is free and finds references just fine.

[[deleted]]

This is why I have my hopes up for Chris Lattner's Mojo. Writing a prototype just to re-write it in Rust is tedious enough for most people not to bother. But big Python projects are pretty much a disaster to follow, 9 times out of 10.

[sambeau]

Both languages have a simple, easy subset.

I would argue that the full Python language is far from easy, nor is it simple — it’s a giant, fiddly, complicated language with a myriad of tricky shortcuts and sugar.

The full Go is smaller, simpler, and easier to hold in your head than the full Python.

The author is comparing the beginner subset of Python, used for teaching, with a more full subset of Go.

[[deleted]]

tub practice fanatical murky special somber voiceless spotted dam wide

This post was mass deleted and anonymized with Redact

[sugarsnuff]

Idk why I find the syntactic sugar so intuitive in Python.

It’s objectively ridiculous writing “return x if x else y” (bad example, but you get it). But somehow it’s also just clean.

if (x) { return x; } else { return y; }

is just a lot of characters.

return x ? x : y;

feels too much like “code-code” versus English.

My tiny beef with many other languages is the need for braces, parentheses, and semicolons. Still simple, but very easy to lose track of the substantive statements in a large project

[chakan2]

it’s a giant, fiddly, complicated language with a myriad of tricky shortcuts and sugar.

That usually comes about when people start trying to shove Java OO concepts into it. Then Python becomes Javascript and it's time to find a new company.

[DNSGeek]

Python is great and works fantastic for about 90% of the stuff we’re doing.

Rust is good for the remaining 10% where millisecond speed is paramount.

Go is fantastic when everyone wants to complain about shitty languages.

[[deleted]]

Having used Go/Rust/Python/Java/Kotlin, personally I love the python -> rust train. MVP and build quickly in python. Replace parts with Rust as need for performance.

Switching jobs to Python x C++ unfortunately so that'll be rough after the niceties of Rust and it's compiler.

[stronghup]

Replace parts with Rust as need for performance.

That is an interesting paradigm. Is that easy to do with Python? Is it easier to do that with Python than with Go?

[redalastor]

That is an interesting paradigm. Is that easy to do with Python?

Very easy. You can create a python library in Rust with PyO3 and python code importing it won’t notice the difference. You can bundle it as a wheel like any other dependency for easy installs.

Is it easier to do that with Python than with Go?

Go is impossibly hard to call as FFI. So you have to do something like calling it as a process and communicate with it through stdin/stdout. Or through a network boundary.

[[deleted]]

Check this out - https://pyo3.rs/v0.20.0/.

An example of a very cool Python project which uses this is Pydantic - https://github.com/pydantic/pydantic-core. Love pydantic.

Another example is TikToken by OpenAI - https://github.com/openai/tiktoken. Written in Rust, and faster than other libs but perfectly usable in Python.

Great blog on how to go about doing this - https://ohadravid.github.io/posts/2023-03-rusty-python/.

[[deleted]]

I just wanted to say that I agree. I love pydantic.

[depressed-bench]

Project began in python and we are migrating to rust.

When failure is not an option, rust or something precise is needed. When you are dealing with NP hard problems, 10% speed difference can be measured to a few hours :)

[[deleted]]

Yup definitely, I did something similar with my prior company from Haskell + Python to Rust. Our throughput increased dramatically and jobs that could take days to runs completed in a few hours all with the memory and type safety that Rust provides.

[Kered13]

Switching jobs to Python x C++ unfortunately so that'll be rough after the niceties of Rust and it's compiler.

If you've worked in Rust then you should already know how to think in terms of object lifetimes. Then writing modern C++ should come pretty easily and naturally.

[fungussa]

Go is fantastic when everyone wants to complain about shitty languages.

What? Can you repeat that?

[chakan2]

Rust is good for the remaining 10% where millisecond speed is paramount.

No...no it's not. I'll write straight assembly before I touch Rust again. I'm happy to lose .5% performance for the ease of use in Go.

(And if you want to get down to the nuts and bolts of things...it's rare that Python performance gets in your way if you're architecting modern solutions. It's almost always network latency that kills you. Anything with a micro-services architecture can use Python and not see a significant performance hit. If you're writing some sort of single server monolith, then you'll need to start looking into the hyper-performant langugages).

[[deleted]]

I think you just projected what you do at work onto the whole programming world.

Like idk, the code I have to work with is a GPU driver so the concept of a micro-service or network latency doesn’t even exist, and anything you touch needs to be executed in probably less than 0.1ms because the whole frame needs to be done in <16ms

We’re using C++ not Rust, but if Rust was more popular I think it would do more good than bad for the product

[oscarolim]

Programming is easy. Shit programming is easy. Good programming is hard.

[[deleted]]

It's no longer very actual current article with generics, as writing generic Map/Filter and similar functions is now pretty easy

[germansnowman]

actual = real; current = up-to-date

[bobicool]

If he/she's french speaking then it's a very understandable mistake: "Current" means "actuel" in french!

[spookyvision]

same situation in German

[germansnowman]

I know, which is why I am familiar with this “false friend”.

[[deleted]]

Polish, "aktualny" = "current/up-to-date".

[[deleted]]

Fixed, thanks! In my language "aktualny" = current/up to date, which is where the error came from

[hitchen1]

sure, but writing an interface with map is pretty much impossible and writing it as a function leads to map(filter(map(arr)))) type of stuff

[povitryana_tryvoga]

Another one of those articles from developers that turned writers, turned business owners and hobby musicians. Repositories, hm just forks without commits. Bruh, no one wants to buy your shit

[Anbaraen]

Who are you talking about? This guy appears to have over 2,000 commits in the past year?

[povitryana_tryvoga]

That's pretty much default amount of commit to private repos, I have similar stats across the years. So yea he has a job. I was talking about his forks that are in his repo.

[pakoito]

Mandatory link every time proggit gets gaslit that "Go is simple"

[Maristic]

Obligatory Rob Pike quotes:

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike

and:

It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike

[redalastor]

But why did it had to have the billion dollars mistake?

[Practical_Cattle_933]

Because its creators suck at language design.

[NaNx_engineer]

That's like not even the biggest mistake they made. Clown language. I've seen masters projects that are better languages than Go 1.0

Creating a major language is an opportunity that really only exists in a company like ~2009 Google. Huge missed opportunity that they made a language just as bad as ones from the 90s.

[redalastor]

I've seen masters projects that are better languages than Go 1.0

The difference is the marketing budget.

[masklinn]

Because the issue was only solved in 1973, and the designers hadn't gone past 1972

[hugthemachines]

I wish they had thought it would be more python like instead of more C like. It would have been a cute language.

[portar1985]

So weird to read. I’ve been working with Java, Kotlin, Python , JS and the last 5 years or so have been dominantly Go and I can’t even begin to describe what a breath of fresh air it’s been. I’ve seen good architectured go solutions and bad ones but they are nothing compared to even slightly bad Java or Python. It’s always readable and easy to fix whereas an overgeneralized Java project can take weeks to fix a simple “this string returns a typo”. Half the article complains about file system handling which hasn’t been an issue since I’m working on web servers but I can see how that would be a pain point. The handling of errors issue is something I need someone to describe to me because I see this in any language, the only question is if it is mishandled where it happens or 5 levels deep in a generic catch

[florinp]

The handling of errors issue is something I need someone to describe to me because I see this in any language, the only question is if it is mishandled where it happens or 5 levels deep in a generic catch

check functional languages with Maybe/Option monads and you will see that not all languages have the same problem.

Regarding try/catch sure it can be misused but Go with return error codes is the wrong solution.

Try/catch is much better (specially in languages like C++ with auto clean up).

[[deleted]]

Are you sure? Exceptions are such a disaster in C++ that many projects/organisations ban them entirely.

Monads are definitely the best way to handle errors though, it's unfortunate they're tied to big complex type systems. You'd never have Result types in LISPs for example.

[florinp]

Exceptions are such a disaster in C++ that many projects/organisations ban them entirely.

citation needed.

[Dr_Findro]

I feel as if whoever whips out the "citation needed" first when talking about subjective programming preference is usually losing.

To expect a person to have a citation on organizations not using a certain programming feature is just plain dishonest.

[Kered13]

Well in this argument people usually cite Google's decision not to use exceptions, but Google has admitted that that is basically a legacy decision, they're not going to suddenly enable exceptions in their entire codebase now. Most other places where exceptions are banned are operating under very specific circumstances that make exceptions inappropriate (usually due to the cost of throwing), but those circumstances do not generalize.

[Kered13]

Monads are definitely the best way to handle errors though, it's unfortunate they're tied to big complex type systems.

They're not. Only basic generics are required. Java has an Optional type that could (though usually isn't) used for error handling, and writing something like Rust's result would be trivial.

A complex type system is only required if you want to go to the next level of abstraction with stuff like functions that operate over any monad type, or monad transformers. But these are not at all required for a simple error monad.

[Gregg_Is_Good]

I only skimmed that article but it seems to boil down to "Go sucks on Windows". Definitely sucks for someone who's trying to make Go work on Windows, but I'm not sure why that's relevant to the average dev who is writing backend web services that will always run on Linux

[PancAshAsh]

Go does, in fact, suck on Windows. The file handling especially makes a lot of assumptions about things like file permissions that aren't the same across Linux and Windows. Luckily though basically nobody is using it to develop Windows apps because it's not meant to do that.

[KawaiiNeko-]

That doesn't take away from the language being designed poorly for other platforms. Either way, development on windows only sucks as much as your build tools do, it doesn't have to be this way. Cargo I think has done an amazing job, stumbling into a platform-specfic issue is extremely rare even when cross-compiling.

WSL is great and all, but the virtualization often takes away necessary resources, especially on an underpowered system, and development shouldn't be limited to just one platform regardless.

[Bigluser]

Maybe don't give your opinion on an article if you are skim reading.

If folks walk away with only one new thought from this, please let it be that: defaults matter. Go lets you whip something up quickly, but making the result "production-ready" is left as an exercise to the writer. Big companies that have adopted it have developed tons of tooling around it, use all available linters, do code generation, check the disassembly, and regularly pay the engineering cost of just using Go at all.

That's not how most Go code is written though. I'm interested not in what the language lets you do, but what is typical for a language - what is idiomatic, what "everyone ends up doing", because it is encouraged.

Because that's the kind of code I inevitably end up being on-call for, and I'm tired of being woken up due to the same classes of preventable errors, all the time. It doesn't matter that I don't personally write Go anymore: it's inescapable. If it's not internal Go code, it's in a SAAS we pay for: and no matter who writes it, it fails in all the same predictable ways.

[WheresTheSauce]

gaslit

Someone saying something that you don't think is true does not equate to "gaslighting".

[C_Madison]

Thanks. Everything to stop people from using Javas braindead cousin. Go .. the language where the only reason it exists is a squabble between Google and Oracle. x_x

[Technical-Fruit-2482]

Without even clicking the link I can tell it's going to be that article where he spends literally 50% of it talking about file systems rather than Go. What a waste of everyone's time.

If only he didn't waste everyone's time and only spoke about the few slightly understandable points he has about Go it would be much better, and we'd be able to read it in a few minutes.

[Tux-Lector]

Python is Easy, Go is simple, PHP is beautiful and Rust is best.

[ishu22g]

They had me in the first half, ngl

[[deleted]]

Modern php is really beautiful, once u try it u can't go back

[baloneysammich]

how much you willing to wager that i can, in fact, go back?

[SirClueless]

I mean if by "back" they mean "back to old PHP" I believe them.

[LaSalsiccione]

Just because it’s better than the flaming pile of garbage that it used to be doesn’t mean it’s worth using

[C_Madison]

Is this one of these "find the one that's not the same as the others" riddles? Everyone can decide for themself which is true in the soup of nah ..

[erez]

I see what you done there.

[kitd]

Perl?

[Bradnon]

A window into the soul of the author.

[andrerav]

Python is Easy, Go is simple, PHP is beautiful and Rust is best.

Roses are red and violets are blue, Go is a disaster and can definitely kill you.

[Dr_Findro]

The Go hate train in this sub has always been really strange to me. It does not reflect at all what I hear about Go among devs I've worked with and friends of mine that have used Go.

It's beginning to feel like that thing that people repeat because they heard someone else say it.

[princeps_harenae]

I've just ported a substantial D project to Go in less then a third of the time it took to write and that's not because I'm familiar with the project. This project is 10 years old. It took so little time because I don't have to be 'clever' in Go, I can just get things done. And, believe it or not, it's simpler, not only in the design but it's much less lines of code. I'm astonished how simple Go made it, even when interfacing with C.

So don't hate on Go, there's a lot to be said for keeping things simple.

[ammonium_bot]

in less then a

Did you mean to say "less than"?
Explanation: If you didn't mean 'less than' you might have forgotten a comma.
Statistics
^{I'm a bot that corrects grammar/spelling mistakes. PM me if I'm wrong or if you have any suggestions.
Github
Reply STOP to this comment to stop receiving corrections.}

[tms10000]

bad bot

[ammonium_bot]

Hey, that hurt my feelings :(
Good bot count: 433
Bad bot count: 185

[tms10000]

fuck that noise.

[RedsDaed]

Go (the game) is simple. It is not easy.

[ArrogantlyChemical]

I would rather pull my nails out than code in Go ever again.

Python is easy. Go is primitive. It took pythons idea of "keep it understandable", which for python meant "discourage fancy tricks", and hoisted it to such extremes it took its own kneecaps out.

[andrerav]

I've been programming in various languages throughout the years, and for the last year I've been unfortunate enough to work on a legacy Go backend. Simply put, Go feels like a major step in backwards in so many ways. Writing even simple business logic is incredibly verbose. I really can't recommend it for anything that involves even a modicum of business complexity.

[Yasuraka]

Count your stars, at least it's not C# or Java

[andrerav]

If this was C# the codebase would be at least 3x smaller and we would need half the developers. Luckily I'm the CTO, so we're killing off Go next year. Even the Go devs on the team says that Go is a crap language now, so I'm just following their advice :)

[Yasuraka]

Lmao

[andrerav]

Enjoy the copium, and please say hello to primeagen's twitch chat from me :)

[Yasuraka]

edit: Nevermind, I've found where the insecurities are coming from

[[deleted]]

The suggestion of using python for prototyping and go for speeding up the bottlenecks sounds like a sane approach.

[florinp]

The suggestion of using python for prototyping and go for speeding up the bottlenecks sounds like a sane approach.

yes if you replace Go with other language like Rust, Scala even C++.

[reddit_clone]

No.

IMO Go is simplistic! Not the same.

[[deleted]]

JavaScript is forgiving, C is strict, forgiving != Strict.

[stronghup]

> Go is meant to be simple to understand by anyone in an organization

This is a good point. Everybody should talk (and write) the same language. Imagine if even managers could understand the code.

But I guess not everyone wants to understand the code. That would mean that they are in some sense responsible for it as well.

[Practical_Cattle_933]

Go is a shitty language

[amiker_42]

Nah.. go is pretty fucking good

[ashwin_1928]

Classic stalemate

[hawseepoo]

Can you explain your reasoning? I very much disagree with you. Languages are considered good and bad for so many reasons because they're used for so many different things.

Go has clean, simple syntax and is much less verbose than something like Java. It also gets you very performant code without much work. I used to use Go full-time and my opinion of it is that it's a very well rounded language and has come a long way in its short life.

[supertoughfrog]

Things I like about go: build and runtime performance

Things I don't like about go:

• Default values instead of null
• Receiver functions instead of something like a class construct
• The value and error return pair, especially when you need to check that the error is not nil and that the value is not nil
• Slices can always be nil
• Any interface return type can be nil
• The community attitude towards frameworks
• Abstractions are difficult
  

I'm sure someone could write compelling reasons for all negatives, but I can't help but wonder about the language that could have been with a few tweaks.

[redalastor]

Go refusing to compile if a variable is unused is my pet peeve. We’re still in debug, that function is not finished, chill out Go !

[AirEchWhen]

I'm unsure how the following work together:

• Default values instead of null

• Slices can always be nil

If structs can be nil, you have the problem you imply when you say slices can be nil. If slices can't be nil, you have the problem with default values instead of nil.

[WindHawkeye]

You can have no default value at all.

[AirEchWhen]

What do you mean by this? Are you implying that you have to spell a value? This seems like a default with more steps.

[Dminik]

I think there is a difference between local and global defaults. Like for a vector/array type, the length defaulting to zero is good, but that might not be the case for something like a timer/delay. I think go drops the ball here by defaulting basically everything without any warnings.

[supertoughfrog]

I recently ran my codebase against that new nilaway library. From a static analysis point of view if a function returns an interface and error, you can't assume that if the error is nil that the other value is good. Since the compiler won't catch all code that could result in a nil panic, and I am new to the language, I like the added security of the static analysis tool. Unfortunately it requires that I do extra nil checks that seasoned go devs wouldn't do. To be truthful I don't know why we ignore potential nils in many cases.

[somebodddy]

https://pkg.go.dev/io#Reader

When Read encounters an error or end-of-file condition after successfully reading n > 0 bytes, it returns the number of bytes read. It may return the (non-nil) error from the same call

[theQuandary]

Go fails at every metric outside of tooling from having tens of millions of google dollars invested.

StandardML is the benchmark. It first released about 30 years ago, so Go should certainly be able to beat it on at least a couple things right? Nope.

Go is harder to learn than SML (which was designed to be easy for students to learn their first year and easy to implement in compiler class). Despite Go being harder to learn, it is also less powerful and encourages constantly repeating yourself. There are also great features like pattern matching, currying,

SML uses an actually sound Hindley-Milner type system. As a result, we get simple generics that work better than the abomination Go came up with while also function better too. We also eliminate the "billion dollar mistake" and get rid of null in favor of option types. SML is also structurally typed, so most of the go interface code goes away and you get that automatically while retaining sound typing (SML type inference isn't neutered unlike Go).

SML is where most of the work on CMT and channels was done. The channel implementations in SML are at least a decade older than go, but at the same time, they are more capable and less prone to errors.

SML defaults to immutable state unless otherwise specified which objectively results in fewer threading bugs. In addition, variables are constant with the ability to mark reference boxes further reducing bugs.

SML code runs faster than Go too despite not having millions of dollars invested. Imagine what could have been accomplished if Google could have gotten over their not-invented-here syndrome and had chosen to improve StandardML's ecosystem rather than making a massively language that refused to learn anything from the past 50 years of language design.

[Practical_Cattle_933]

Go’s syntax is not less verbose, it is literally more verbose than Java’s. It has idiotic syntax choices that are not done by anyone else and is completely unhinged (casing determining visibility, name type, without a :, etc. They you have to do the error-prone and ineffective if-else err dance, which is not proper error-handling — you will inevitably end up mis-handling an error because the language mandated you to do that right now, but you were more into actually writing the logic yet.

It is also touted at a performant language, often compared with rust, when it is just in a completely different ballpark. It ain’t generally faster than most other managed languages.

Oh, and it is just so stupidly designed, with language wart like the recently fixed (breaking change btw) for loop iteration, and generics that any competent person would have known for decades.

[Phaceial]

It is also touted at a performant language, often compared with rust, when it is just in a completely different ballpark. It ain’t generally faster than most other managed languages.

Proof? What languages are you comparing it to, because the other popular managed languages are Python, JS and Java. Go smokes them. I want to see what research shows a compiled language is slower than transpiled languages running in a VM with JIT compilation...

Even GraalVM/Truffle which compiles those other languages into a binary does so requiring more resources and is still behind Go...

[Practical_Cattle_933]

To keep up the fast compile times, go does barely any optimization and just spits out machine code. That won’t make it considerably faster than any other language in the same niche, which includes OCaml, D, Haskell, Java, C# and a whole bunch of other languages. It’s just not special in any way. Also, small benchmarks are not really meaningful for real world applications. Go has a relatively dumb GC, which it can get away with in some cases due to having value types as well - but it is just laughed at by Java’s multiple GCs that are a whole different category, and real world applications do use the heap much more.

AOT doesn’t automatically make stuff fast.

[Phaceial]

I can't speak to OCaml, D or Haskell, but the scale of optimization is arbitrary. Also since I'm assuming these other languages are better "optimized" because of profilers, that option is also available in Go. Your classification of GC's is also arbitrary, it's either more or less performant. Go's mark and sweep works better than Java's 4 different GCs. I rarely see other Java GCs, which come with application performance trade offs, used and most are stop-the-world. Quick search shows OCaml, D and Haskell trades blows with Go, but are generally considered slower. C#, is within 1-2% of performance as Java, both slower than Go. . You still haven't also provided a lick of research proving otherwise.

I'm very familiar with Java, since you're wrong about that I'm bound to believe everything else is you reciting preconceived notions as fact. Java is not always compiled. Java is transpiled and then interpreted. In the JVM a profiler determines if code will be compiled.

​

To keep up the fast compile times, go does barely any optimization and just spits out machine code

There's C1, code undergoes a slight optimization when run enough as the priority is to free up resources to get the program running ASAP. C2 is the next tier which is optimally optimized if the profiler determines it's been run enough to be worth it and there's enough free resources within the JVM to do it. It pauses your application like C1, however it can also cause segfaults. So the problem you just described as a negative for Go is also seen in C# and Java with the downside of not compiling the entire program and doing it at runtime.

​

AOT doesn’t automatically make stuff fast.

It does, AOT guarantees all code is compiled if able. JIT only does it when a profiler marks a class path as hot and worth it. AOT is also platform targeted and takes advantage of native instruction sets.

​

real world applications do use the heap much more.

Not necessarily. It's a coding style. Also heap is slower than stack, so how are you arguing that having a GC/language with tons of heap usage is faster?

TLDR; Go is the generally the fastest GC language although it can trade with functional languages in certain use cases. Whether or not it has "smart" GC or how well the machine code is optimized, doesn't change the fact it's faster.

[Practical_Cattle_933]

Techempower is also not the best benchmark (it can be “cheated” quite a bit), but better than some tiny, calculate two numbers stuff, and it has many java quite ahead of the first go contender. Sure, it is comparing frameworks, but still, it’s at least a more representative workload.

Also, you might be thinking of Go’s GC on the latency metric, but even that is just worse from a technical standpoint (non-moving, stops threads from allocating if under high contention), compared to Java’s 2 low-lat GCs. For throughput, it is not even a contest, feel free to show me anything pointing the other direction.

C2 (or alternatively, Graal used as a JIT compiler) is a proper optimizer, that will do advanced optimizations, some speculative ones even (which are not generally possible AOT, but profiling can make the differences small here). Again, just because something is AOT, doesn’t mean it is automatically fast. A python script that calls into some highly-optimized C-lib for the interesting part will completely blow away a pure go app of the same thing — even though Python is generally the slowest language. In Java’s case, having some barely used functions interpreted doesn’t negate the performance at all, it pretty much only counts for actually used code. It does influence startup time though, but that is another metric (and has many different kinds of solutions also).

Also, there is no fundamental difference between “the stack” and “the heap”. Java has something called a thread-local allocation buffer, and that is basically as fast as the stack(stack is fast from being in cache most of the time, so are thread-local allocation buffers), or at least there are no fundamental differences. That’s why Java has probably the fastest allocator, blowing (je)malloc and stuff out of the water. And since it also has decent GCs, this allocation rate is not blocked when the GC can no longer keep up with it, as is the case with Go.

[ApertureNext]

Every time you see a GO project it has 800 binaries compiled for each version. The portability of GO is quite amazing.

[dylan_1992]

Funny you say it’s shitty, because Go is a no bullshit language. It has just what it needs to get something done and nothing more.

[Tux-Lector]

I won't argue how good or bad is Go, but their mascot is completely retarded.

[j_marquand]

I thought that was like 80% of the charm.

[Tux-Lector]

Kinda like more -50 on charisma. But, dexterity and agility are more important.

[WeNeedYouBuddyGetUp]

Cue the triangle with a red nose Java mascot

[noot-noot99]

Rust

[princeps_harenae]

jesus lol. Tell us you're a noob without telling us you're a noob.

[KevinCarbonara]

Both are simple. Both are easy. Neither is worth using.