111–120 of 313 posts
Earlier quoted context omitted.
F# is basically statically-typed Python (with better performance).
I've been meaning to try it. Isn't F# modeled after Haskell?
Earlier quoted context omitted.
I will spell it out for you: Almost every language in the world has some sort of template-based autocomplete for common boilerplate that is often used, from class definition templates to if statements. If you aren't using one of these, you're probably working unproductively by thinking about all of your boilerplate instead of just taking it off the shelf. Copilot and its ilk just take this one step further by effecti…
> I will spell it out for you: Almost every language in the world has some sort of template-based autocomplete for common boilerplate that is often used, from class definition templates to if statements. Which is very conceptually simple . `sout` in Intellij creating Java `println(...)` is very simple. Completely straightforward. Unlike LLMs. - Go is simple! - Great, but it takes a while for me to produce code in Go.…
Earlier quoted context omitted.
It's very simple. It's explicit and tells you exactly how errors are handled (if you care), and it follows a very common pattern that is easy to ignore when you don't want to know how errors are handled. Simple and concise are two very different things. In comparison, languages with exceptions give you a minefield around every function call.
Ok. Then I will spell it out: using an LLM to generate code is not remotely simple.
Earlier quoted context omitted.
Ok, maybe you can help me figure something out that I haven’t been able to. I’ve got a project broken down into modules. Module A uses module B. These are both checked into GitHub, so the module path is something like guthub.com/distortedsignal/my-project/src/a or whatever. I need to make a change across both of these modules. Will my compilation pick up the changes? What if I need to make a backward-incompatible cha…
> I need to make a change across both of these modules. Will my compilation pick up the changes? Yes, add a replace directive to A's go.mod and point it to B's directory. It'll pick up changes immediately. You can also vendor + disable modules + change stuff in the vendor folder to quickly experiment, though IDEs tend to get moody about this. Backwards incompatible in principle: release a new major version of B. Impo…
What do you do if you’re working in a fork of the project and you need to make those changes?
I'm diving back into python after being mostly away for the better part of a decade having built high scale, highly available systems in Go during that time (including migrating several projects from python and perl to go). Being suddenly back in python is jarring. So much inheritance - abstract base classes and multiple inheritance via mixins, strange coupling in tests via over use of mocking and patching, and a rel…
Python code typically doesn't and shouldn't rely heavily on inheritance. It sounds like you're working on non-idiomatic Python code. Bad luck.
Earlier quoted context omitted.
Don't forget the fact that it doesn't have this overbloated concept of inheritance and polymorphism of let's say Java where you have to look through 6 files to understand what's even going on. Even generics in Go were a heated debate because they make the language more complex. All in all Go was created by geniuses and it shows.
> it doesn't have this overbloated concept of inheritance and polymorphism of let's say Java where you have to look through 6 files to understand what's even going on Several Go codebases I've worked on would like a word. Some Go people really love their interfaces and abstractions and making sure every method is only 3 lines and pretty soon you're 20 files and three type hierarchies deep trying to figure out what a…
Earlier quoted context omitted.
A certain number of developers will be able to complicate any language or mechanism you provide them, it's how they feel important. I've notice the there is a group of people who has their entire identity tied up in being "smarter" than everyone else, except they aren't, so they build extremely complex systems, because they think that's what smart people do. They are interestingly often extremely well versed in their…
You are mistaken if you think that the abundant use of interfaces etc. is motivated by anything along those lines. As someone who often puts basically everything behind an interface and abstracts everything in sight, it's not because it has anything to do with being smart, quite the opposite; it's the only way I can keep any meaningful portion of the code in my head. Give me a 5000-line straightforward / unabstracted…
Another reason for me for having interfaces is simple mocking in tests.
Earlier quoted context omitted.
I mean it's not like MATLAB where a company put in millions of dollars to make these libraries - the entire ecosystem was developed by open source contributors because they liked something about Python - sure, it's probably not as sophisticated as some of the other languages, but it has a low barrier of entry, it has users, and people developed libraries - in some cases because that's where users are and in many case…
> they liked something about Python I think it's simply what they already knew. Very few programmers learn multiple languages to any kind of depth. Is there any evidence that Python is an easy language to learn? I think we've reached a situation where beginners learn Python because it's seen as beginner friendly... because beginners learn Python!
Admittedly, that's just an opinion. I don't know of any relevant studies, but Python wasn't always the preferred language for beginners, and it changed at some point. It feels like there must be a reason for that.
JS is both
Pros:
* Being single threaded makes concurrency simple. No need to think about mutex/semafor/channel/etc.
* Everything is a pointer so no debate on whether to use pointer vs value for variable
* Not to many reserved keywords to learn before being able to write javascript
* I like async/await
Cons:
* Tiny standard library
* Very little standardization between projects
* JS is often compiled/minified which can make debugging painful
* Not so performant. Can't do true concurrency