| ▲ | TheChaplain 11 hours ago |
| It's not a bad thing to realize that one can be wrong and then strive for change. |
|
| ▲ | a-french-anon 11 hours ago | parent | next [-] |
| Maybe, but personally I've become quite tired of programming languages "organically grown" as opposed to properly designed the first time. After a good decade of C then C++, I found ANSI CL (despite being a massive compromise and unfinished) much more coherent and complete than both. |
| |
| ▲ | bbkane 10 hours ago | parent | next [-] | | I know Go is justly criticized for many of its design decisions, but it still feels well-designed and "small" to me in day to day usage when many other languages don't. | | |
| ▲ | a-french-anon 8 hours ago | parent [-] | | Eh, the thing with generics coming late is pretty much what I meant by "organically grown". My best litmus test these days is support for multidimensional arrays because it's always needed at some point in general purpose languages. CL and Ada had it right from the start while C++ needed C++23/26 to get std::mdspan and we still need to wrap it to pass the underlying/owned memory pool around (https://rosettacode.org/wiki/Multi-dimensional_array for more). | | |
| ▲ | nish__ 8 hours ago | parent [-] | | Doesn't every language support multidimensional arrays? It's just an array of arrays, no? What am I missing? | | |
| ▲ | umanwizard 7 hours ago | parent [-] | | An array of arrays is an extremely inefficient and error-prone way to represent multidimensional arrays. If I want a 1000x1000 array, representing it physically as a single 1000000-element array requires one allocation, and processing it element-by-element (assuming it's stored in the same order we're iterating over it) is sequential in memory and therefore very efficient. Representing it as 1000 separate 1000-element arrays requires 1000 allocations, and pointer-chasing every time we move from one row to the next. | | |
| ▲ | j_w 5 hours ago | parent | next [-] | | Isn't an array of arrays by definition the sequential implementation? Otherwise you would have an array of pointers to arrays. The usage (syntax) for them would be the same but the performance would not be. They also have different uses. You would expect an array of arrays to be an array of arrays which share the same length. For an array of pointers to an array you would expect dynamic length arrays contained within the original array. Even in c++ could you not just define some int [1000][1000]foo? I've never really used C++ but my C knowledge assumption is that is 1000000 continuous elements. | |
| ▲ | nish__ 6 hours ago | parent | prev [-] | | I see. That makes sense. |
|
|
|
| |
| ▲ | xscott 10 hours ago | parent | prev | next [-] | | Scheme is (or at least was) coherent. You don't need to look any further than set/setf/setq to see that Common Lisp is "organically grown" from the fertilizer of a committee. CL does its best to make every other lisp more attractive. | | |
| ▲ | rootnod3 10 hours ago | parent | next [-] | | Which Scheme are we talking about? R5RS? R7RS-small? R6RS? With SRFIs? Without? Which scheme? Is it `(library...)` or `(define-module...)`? | | |
| ▲ | xscott 10 hours ago | parent [-] | | Heh, I'd probably take R4RS with define-syntax :-) | | |
| ▲ | rootnod3 6 hours ago | parent [-] | | I mean, good choice, but you see the point, right?
As much as ANSI CL has it's flaws, it has a standard, as much of a mixed bag it might be. Scheme is just a general potpourri of "we kinda have a guideline, but do whatever". I would very much prefer scheme if the different implementations had a working standard. But I can't take my Chez-scheme code and throw it into Guile-scheme. But pretty good chance I can take my ECL code and throw it into SBCL or LispWorks. | | |
| ▲ | xscott an hour ago | parent [-] | | > you see the point, right? Bah, I think this debate was already old when I first saw people arguing it on comp.lang.lisp in the 90s. I don't have a dog in this fight other than to reject the notion that Common Lisp is "coherent" and not "organically grown". The original Scheme belongs in the category of languages like Standard ML and SmallTalk, where a small, careful, and talented group designed them with focus. Common Lisp seems like a bunch of smart people with competing interest and legacy baselines tried to meet in the middle. To the extent CL is more pragmatic, it's another example of "Worse is Better". |
|
|
| |
| ▲ | rahen 9 hours ago | parent | prev [-] | | Scheme has a coherent and minimalist design, but its ecosystem and abstraction facilities feel too sparse for large applications. When I started building a Lisp-based machine learning framework, Guile seemed like the right choice because it provides GOOPS and generic functions, yet I still ended up with a lot of boilerplate to compensate for the lack of a strong type system. Scheme feels to me like C is to C++: not ergonomic for large-scale application development. Go is one of those languages that has both minimalism and productivity. |
| |
| ▲ | ndr 10 hours ago | parent | prev | next [-] | | "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." -- Greenspun's tenth rule He had some lack of conviction to scope it so narrowly. | |
| ▲ | ramon156 11 hours ago | parent | prev | next [-] | | So which language had it right from the start? is there a language that has a very low rewrite status? | | |
| ▲ | poncho_romero 8 hours ago | parent | next [-] | | I think Elixir is a good candidate here. It's small, coherent, and composes well, and (at least to my understanding) the authors consider the language finished, with no new major features planned. | |
| ▲ | bbkane 10 hours ago | parent | prev | next [-] | | I'd particularly like examples of statically typed languages that "got it right" (since I love me my types) | | |
| ▲ | galangalalgol 10 hours ago | parent [-] | | Ocaml maybe? Multi threading didn't seem necessary and introduced the possibility of data races. |
| |
| ▲ | maccard 10 hours ago | parent | prev [-] | | That’s whataboutism - no language is perfect, but given when go released it’s fair to hold them to a higher standard than languages what were designed 25 years earlier. As an aside - D, Zig, Rust, even typescript got most of the lessons learned from C right | | |
| ▲ | blanched 9 hours ago | parent | next [-] | | I'm not familiar with D, but Zig and Rust are well-known for continuously evolving. Zig has the (in)famous "Writergate": https://github.com/ziglang/zig/pull/24329 And besides Rust's high count of RFCs, there are things like async (I'm not complaining about it, but its an obvious large-scale "change"), module system changes, etc. (To be clear, I like both languages a lot. But I wouldn't call them slow moving or right from the start.) | |
| ▲ | Maxatar 8 hours ago | parent | prev [-] | | D literally can't even maintain backwards compatibility between minor version updates not to mention a big part of the D community left when D reinvented itself with D2. Among languages it's probably the one that is constantly in a state of flux. |
|
| |
| ▲ | rootnod3 10 hours ago | parent | prev | next [-] | | ANSI CL is such a breath of fresh air nowadays. Does what you need, doesn't get in your way, comes with batteries included. And conditions are just god-tier. | |
| ▲ | pizza234 8 hours ago | parent | prev | next [-] | | It isn't realistic to expect a design to be "proper in first place" because requirements change; my opinion is indeed the opposite - I find it natural for programming languages to have a (sort of) lifespan, and for new ones to (sort of) take their place. | | | |
| ▲ | iosjunkie 9 hours ago | parent | prev | next [-] | | "properly designed" - ah yes, programming languages are famous for universally agreed upon design philosophies. | |
| ▲ | skywhopper 7 hours ago | parent | prev | next [-] | | You may be tired of languages evolving over time, but there is no other way to build a rich and useful language. | |
| ▲ | boxed 10 hours ago | parent | prev | next [-] | | I liked Objective-C (except the C parts). Such a breath of fresh air coming from C++ which was grown like a cancer with tons of features and you felt trapped by every one of them. Objective-C in contrast was a very few additions thoughtfully added that composed cleanly and freed the programmer to actually get things done. | |
| ▲ | fhn 8 hours ago | parent | prev [-] | | so make your own and let's see how you do | | |
| ▲ | chlorion 5 hours ago | parent | next [-] | | I am actually working on my own language, and getting something better than Go is actually not that difficult! The hard part about making a language is creating the stdlib and tooling and support for the language, but actually creating a language itself that has more features and better features than go can be done by a single person in a few months or a year probably, depending on how much experience they have. Generics specifically are a great example here. A single person can implement a language with go-level generics fairly easily. | |
| ▲ | rootnod3 8 hours ago | parent | prev [-] | | Have you? |
|
|
|
| ▲ | maccard 10 hours ago | parent | prev | next [-] |
| There’s a fine line between being willing to change your mind and getting the basics wrong. Go has repeatedly gotten the basics wrong. |
| |
| ▲ | whoiskevin 10 hours ago | parent | next [-] | | Declaring a highly successful language as having the basics wrong means that you are not correct about the basics that were needed. | | |
| ▲ | maccard 10 hours ago | parent | next [-] | | Something can be highly succesful in spite of having glaring design flaws. Nobody is claiming go isn't wildly succesful, but it's _in spite_ of these issues. It was clear over a decade ago that iota, gopath, and lack of generics were massive kneecaps to the language; go changing it's mind on those things isn't progress it's just getting the fundamentals wrong. A good example of where they're kind of stuck is date formatting - it's stupid, unclear, and likely a mistake, but it's not a fundamental flaw; it's just a quirk. | | |
| ▲ | 9rx 9 hours ago | parent [-] | | Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript. The trouble is that Rust is older than Go and it was already confusing people into thinking enums and sum types are the same thing, so by using slightly different syntax, iota, Go avoided the whole confusion of users thinking that enums would behave like sum types instead of actual enums. Is your attempt at making a point that not having sum types is the massive flaw? Sum types are a useful construct, to be sure, but there are plenty of good languages without them. That's more on the design quirk end, realistically. | | |
| ▲ | maccard 9 hours ago | parent | next [-] | | > Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript. iota is a massive kneecap _because_ it's semantically identical to enum in C and Typescript. > Is your argument actually that not having sum types is the massive flaw? Sum types are a useful construct, to be sure, but there are plenty of good languages without them. That's more on the design quirk end, realistically. In a dream world sure we'd have full blown sum types (and that would give a result type which would also solve a lot of the nil-interface-combined-with-error-handling issues that I've ran into when working with go), but I can forgive that. The problem is this - https://www.zarl.dev/posts/enums | | |
| ▲ | 9rx 7 hours ago | parent [-] | | > The problem is this - https://www.zarl.dev/posts/enums The only case I see made in there is that it doesn't like how Go implicitly converts consts. While that may be a reasonable criticism, it doesn't have anything to do with iota. It is related to the type system and applies in general. Consider the same problem exhibited here: type Email string
func Send(email Email)
func() { Send("invalid") } // Converted string const does not satisfy Email type expectations
Perhaps you accidentally offered the wrong link?It was made abundantly clear when Go was released that it was intended to "feel like a dynamically-typed language". Being able to pass arbitrary values is perfectly in line with a dynamically-typed language. Realistically, the type system in Go is there to give the compiler optimization hints, not to offer type safety. Go was targeted at those wanting to use Python, without the programs being painfully slow to run. How much of a kneecap is implicit type conversion, really, when it is already in line with what the target audience is accustomed to? It is a quirk at best. | | |
| ▲ | maccard 6 hours ago | parent [-] | | > It was made abundantly clear when Go was released that it was intended to "feel like a dynamically-typed language". If I google this quote a comment from you comes up here on this exact topic, where you seem to have completely missed the point there too. If I link to the docs [0], the full quote is "It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language. " So it is a statically typed language first and foremost. If you want to rehash the discussion and tell people that a flawed type system that people have been asking for a solution to for close to a decade [1] you can just re-read the last time the arugments were made as I don't think I'm going to make any headway there. [0] https://go.dev/doc/
[1] https://github.com/golang/go/issues/19814 | | |
| ▲ | 9rx 6 hours ago | parent [-] | | > So it is a statically typed language first and foremost. Right, because that is primarily how it makes things fast. Python is slow largely because it spends an inordinate amount of time trying to figure out what things are. Go knows what things are at compile time because the static type system tells it what things are and thus doesn't have to waste runtime compute on figuring out what things are, aside from when you use the reflect package, like Python does. That was its value-add — that it is kind of like Python, but faster. We already went over this... > If I link to the docs [0] I said original announcement, so I'm not sure why you wouldn't look there? Trying to be obtuse on purpose? Regardless, performance was indeed considered more important than being dynamically-typed. After all, if performance wasn't a concern then you'd just use Python. Go exists only because it was solving a problem that wasn't already solved. Slow Python was already solved. Type safety was already solved. It didn't need to go into those territories. |
|
|
| |
| ▲ | jolux 9 hours ago | parent | prev | next [-] | | Rust is technically older than Go, but who was actually using it when Go 1.0 came out in 2012? Rust 1.0 wasn’t until 2015. | | |
| ▲ | 9rx 9 hours ago | parent [-] | | The social landscape doesn't depend on anyone actually using it. However, 1.0 isn't a significant milestone like you suggest either. For a current example, Zig is relatively popular today despite not yet reaching 1.0. | | |
| ▲ | stouset 5 hours ago | parent [-] | | Do you just forget the things you write in earlier comments? > Rust is older than Go and it was already confusing people into thinking enums and sum types are the same thing Of course the social landscape depends on people actually using it. None of the people who weren’t using Rust at the time were magically confused about enums and sum types by the mere existence of some new and experimental language. Rust barely existed at the time Go was first being developed. And given the history of Go and the notoriety of its core team for flatly ignoring prior work in programming languages, it’s extremely unlikely that Pike et al gave more than a cursory glance to what nascent Rust was doing at the time. But even if they had, to suggest that they intentionally replicated a dumb thing from C but gave it a different name to avoid users being confused by a different thing from a language that roughly nobody knew about at the time is bananas. | | |
| ▲ | 9rx 4 hours ago | parent [-] | | > Of course the social landscape depends on people actually using it. That's nonsense. Brainfuck has shaped the social landscape despite effectively nobody using it, and absolutely nobody using it for any real work. The social landscape is not at all dependent on use. > And given the history of Go and the notoriety of its core team for flatly ignoring prior work in programming languages Huh? Go comes straight out of prior work. It is nearly indistinguishable from Alef. What the Go language flatly ignored was being innovative. Reasonably so, of course. It wasn't trying to innovate in programming languages so that we'd have another to throw on the heap of languages nobody uses. It was trying to solve a specific business problem using well-established methods. |
|
|
| |
| ▲ | stouset 6 hours ago | parent | prev [-] | | > Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript. So is nil. Care to make the same argument? | | |
| ▲ | 9rx 5 hours ago | parent [-] | | Typescript has something resembling nil as inherited from Javascript, so presumably that's what you are referring to. C and Javascript are the most widely used languages in existence. Clearly they weren't kneecapped. It mightn't be to your preference, but "I don't like it" would be an atypical use for the word "kneecap". There is a stronger case to be made for the other two. Calling GOPATH a design mistake is a stretch as it was perfectly suited to use within Google, but it didn't fit the typical solo developer's environment. Lack of generics made writing certain types of code difficult. You could be convincing in suggesting that Go did end up being used less than it otherwise would have because of those choices. iota? It's just a construct that generates numbers (an enum). How does that kneecap anything? If it really bothers you, you can manually number the values by hand instead. Why would anyone reject a language because it allows you to optionally choose to have the compiler assign numbers automatically instead of forcing you to do it manually? The answer is nobody. In fact, most popular languages have something equivalent to iota. | | |
| ▲ | stouset 5 hours ago | parent [-] | | Nil exists in C and is widely considered to be a massive mistake in the language. An understandable one at the time, but a mistake nonetheless. Thus “go borrowed it from C, therefore it can’t have been a mistake” is a pretty lame take. The whole point of a new language is to make improvements on what’s out there already. Go missed an opportunity to fix one of C’s most notorious mistakes. So yes, they kneecapped themselves by forcing all of the users of Go to continue dealing with this well-known footgun. Does it mean Go isn’t popular? Of course not. C was popular. PHP was popular. JavaScript is popular. Go is popular. This is always in spite of their faults. But Go could have been better. | | |
| ▲ | 9rx 5 hours ago | parent [-] | | > Nil exists in C and is widely considered to be a massive mistake in the language. You're almost there, but it is wildly considered to be massive mistake in context of arrays. C has weird array semantics that are confusing and hard to get right, even for seasoned developers. That is where NULL comes to bite people time and time again. Go did not inherit C's arrays. Neither did Javascript. They go out of their way to avoid what C did. In Go, you can come close to the same semantics if you use the unsafe package, but take note the name. Yes, they still have nil, but the scope is tightly constrained and while it is technically possible to misuse, you have to try pretty hard to do so. There are many other things that are more likely to end up being misused. Those would be the more massive mistakes. > But Go could have been better. Obviously. Every language ever created can be better. | | |
| ▲ | stouset 5 hours ago | parent [-] | | > You're almost there, but it is wildly considered to be massive mistake in context of arrays. From Tony Hoare: "I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object-oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years." Odd that he wouldn't mention the word "array" anywhere in that quote. > Yes, they still have nil, but the scope is tightly constrained and while it is technically possible to misuse, you have to try pretty hard to do so. Like by not remembering to check if a pointer is nil? Or actually comparing one typed nil to a different typed nil? > Obviously. Every language ever created can be better. Only one of us is arguing that reimplementing C’s mistakes is actually a good thing. | | |
| ▲ | 9rx 5 hours ago | parent [-] | | > Like by not remembering to check if a pointer is nil? Rule of thumb is to not introduce values that aren't valid. Equally, don't put in -1 for an age value, even if the language allows you to. You might later forget to validate that the age value is valid. Yes, mistakes are possible, but these types of mistakes are pretty rare. There is some value in eliminating the possibility of those mistakes, sure, but we cannot pretend that it comes cost-free. There is good reason why almost nobody uses Rocq. > Or actually comparing one typed nil to a different typed nil? This is something that is likely to confuse, but not a facet of nil. It is related to interfaces. Let's not flail around like one of those wacky blow up things at the used auto lot. | | |
| ▲ | stouset 3 hours ago | parent [-] | | Ah the good old “just be a perfect programmer and you won’t run into any issues” argument. Haven’t heard that one in awhile. | | |
| ▲ | 9rx 2 hours ago | parent [-] | | If only you had made it to the second paragraph. Hey, at least we can now understand why you have such a hard time with nil, so that's something. |
|
|
|
|
|
|
|
|
| |
| ▲ | jeswin 10 hours ago | parent | prev | next [-] | | It's a highly successful language because (1) it was backed by Google, and (2) created by Robert Griesemer, Rob Pike, and Ken Thompson. If it came out of anywhere else, it might have struggled even to hit the homepage here. | | |
| ▲ | amazingamazing 10 hours ago | parent [-] | | This logic is easily shown to not hold. Why isn't Carbon, Dart, etc. not really popular then? | | |
| ▲ | doodpants 8 hours ago | parent | next [-] | | I can't speak about Dart, but Carbon had just barely started development when it was first announced 4 years ago, and is currently presented as an experimental language that is not yet ready for use [0]. 0: https://github.com/carbon-language/carbon-lang#project-statu... | |
| ▲ | no_wizard 6 hours ago | parent | prev | next [-] | | Dart was relegated to effectively being Flutter. It was originally intended to supersede JavaScript but no other engine would commit to that. It failed at its initial goal and hasn’t really found a footing outside of Flutter. Carbon is by its own admittance not ready to use and I think mostly relegated to solving Google’s problems with C++ right now. Both of them didn’t ship with a standard library as robust as Go’s. One thing that made Go popular out of the gate is it is extremely good fast to build out robust HTTP services and infrastructure. This is a very common use case and they tailored Go to be a great fit for it. You can build your entire backend without a single third party module if desired using Go’s standard library and it isn’t terribly complicated to do so. | |
| ▲ | voidfunc 9 hours ago | parent | prev [-] | | Its just bitter dorks bitter their pet language with cutting edge programming abstractions didnt make it to the big leagues. |
|
| |
| ▲ | n6242 9 hours ago | parent | prev | next [-] | | By that logic Windows would be the best operating system ever and perfect in every way, and anyone who disagrees must be wrong about how an OS should be. | | | |
| ▲ | ivanjermakov an hour ago | parent | prev | next [-] | | https://en.wikipedia.org/wiki/Worse_is_better | |
| ▲ | someone_19 7 hours ago | parent | prev | next [-] | | So you mean to say that PHP5 and Js from 2007 had a well-founded design? | |
| ▲ | boxed 10 hours ago | parent | prev | next [-] | | The basics of a programming language were wrong. The basics of marketing were very right. Those are not the same. | |
| ▲ | 9rx 10 hours ago | parent | prev | next [-] | | An engineer, of course, understands that there is no such thing as "wrong", only different tradeoffs, but with the rise of "vibe coding" you don't need to be an engineer to play in the world of programming anymore. | |
| ▲ | OtomotO 9 hours ago | parent | prev [-] | | cough JavaScript cough |
| |
| ▲ | Jleagle 10 hours ago | parent | prev | next [-] | | Sounds like you want this feature, and you just got it. Not sure how that's wrong. You don't add in every feature from the start. | | | |
| ▲ | 10 hours ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | ivanjermakov an hour ago | parent | prev | next [-] |
| Worst thing a programming language can do is introduce core semantics changes after 1.0. See Python 2 -> 3 and Zig's *gates. |
| |
|
| ▲ | tux3 10 hours ago | parent | prev | next [-] |
| I don't think anyone admitted any wrong or had any big change in philosophy. It's always a good thing to learn something along the way. But the current message seems to be that this was the plan all along, and it just took some time to design properly. Of course adding generics is not something that every language needs to do. Scripting languages like Ruby don't really need this style of generics. It doesn't fit the design of the language, and it's not even clear what that would look like in Ruby. But static typing with generics does solve a recurring problem, and we've seen some real convergence towards type hints and type systems even in staunchly dynamic scripting languages. Modern Javascript is now mostly Typescript, and they've successfully retrofitted a very advanced type system in the last place I would have expected 20 years ago. |
| |
| ▲ | galangalalgol 10 hours ago | parent [-] | | Type hinting seems like the worst of both. You pay the cost on refactor to go change them all, where dynamic typing or static type inference avoid that. You also don't have any of the benefits of static or dynamic typing. My strong preference is static typing with good inference and an ide that shows the inferred types everywhere when asked. Dynamic typing can make some tasks dramatically easier, I'm just not capable of using them without making hideous mistakes. |
|
|
| ▲ | layer8 10 hours ago | parent | prev [-] |
| It’s still annoying ~20 years after Java did the same mistake of not including generics, which was already clear to many people with C++ experience back then. |
| |
| ▲ | someone_19 7 hours ago | parent [-] | | ...and Java didn't even have basic enums or sum types from the beginning. But it had null. They added enums, they added sealed classes. They're trying to get rid of null (apparently it's really hard). The problem is that in 2012, when go 1.0 was released, this should have been obvious to everyone. Here's a famous discussion from 2009, three years before the 1.0 release (tldr: facepalm) https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY | | |
| ▲ | layer8 6 hours ago | parent [-] | | I remember back in 1995 thinking that it was stupid for Java not to have generics, so instead you had to always cast Vector/Hashtable elements from Object, or implement your own type-specific container classes for every element type (and there wasn’t even a preprocessor to facilitate the latter). Sum types I didn’t really miss, because you can implement a type-safe equivalent using the Visitor pattern, and retain an interface-implementation separation that native sum types typically don’t provide. |
|
|
